Community
Participate
Working Groups
Related to bug 251722, I will attach here a server type which designates SUPPORT for some facet types. It is not in a list of required default facets, or anything like that, but rather a server type simply designating what facets they "support". It's undertandable that in a list of default facets, a missing facet is an error. Or in a situation of required facets, a missing facet is an error. But in this case, the server type is just designating that it recognizes the existence of a facet type, and that the facet type is supported on the server. Under no circumstances should this throw any error to the error log. To use the test plugin, just unzip it and put it in your workspace and run the runtime-workbench. You don't even need to try to create the server type. The errors should be logged immediately on startup. Again, if my server adapter supports some custom m2eclipse (maven) functionality, but it is not REQUIRED at all and my adapter works 100% just as well in an environment without m2e, then these errors will confuse users.
Created attachment 192292 [details] A zip'd example plugin Simply import the plugin and run and you will see several errors
I am not going to re-open the conversation on the necessity of these messages. This has already been adequately discussed in Bug 251722. If you do not wish to solve this problem by applying better modularity on your end, I will consider a patch to apply the same solution applied in Bug 251722 to the "supports" extension point.
Please explain to me how, precisely, "better modularity on my end" fixes the solution. Perhaps I misunderstand what options are available to me.
> Please explain to me how, precisely, "better modularity on my end" fixes the > solution. Perhaps I misunderstand what options are available to me. Create another bundle to hold the supports declaration that references jboss runtime and m2e facet. Make sure that the bundle specifies in the manifest the dependency on the bundles that have jboss runtime and m2e facet declaration. Add this bundle into your feature as an optional bundle. It will install if m2e is present and will not install if it isn't.
So just to be clear, if I have support for dozens of different facets which may or may not be present, I must create a dozen different bundles so that each may be pulled in optionally when the appropriate environment is found? That seems like a *lot* of overhead, especially if all of these facets are irrelevant to publishing or any server behaviour at all...
Ok. So you argument is that applying modularity to solve this problem is inconvenient. Fine. See my Comment #2 for your other option.
I like the idea of the enhancement from bug 251722, but I would argue in this specific use case the default should be no-logging and the enhancement should be a "required" flag. Why? Well, in the previous example, the facet was added to "default facets". This clearly indicates that, as a default facet, not only is support provided, but this facet is expected to be present, as it is a default. For my use-case (and others who share it), inside the <supported> tag, I would argue that support indicates a non-requirement, and the flag should be used to indicate required environments. However both would be acceptable. After digging through the code, I think it's also a little strange that an "UNSUPPORTED" facet would throw an error, as here your plugin is specifically declaring that it does *NOT* support this facet, so it's absence should not be noteworthy at all. Perhaps that is just an assumption on my part and someone else has a usecase that requires that reported. I'm not sure.
Created attachment 192312 [details] A patch effecting the changes mentioned This is a patch that adds a "required" attribute to the "supported" element in the extension schema. The behaviour sets default to NOT log for "supported" facets, though if the user uses the <supported required="true"> attribute, the logging will occur. The patch also changes the behaviour for UNSUPPORTED facets to not log, as the absence of a facet you explicitly want nothing to do with should not (IMO) be notable. I don't expect you to accept the patch unchanged, but I do hope it helps kick the process forward a bit.
As was already mentioned in Bug 251722, the logging is there to catch bugs in code, where developer makes a typo in facet id or version. The relevance of this doesn't change based on the semantics of a particular extension point.
Comment on attachment 192312 [details] A patch effecting the changes mentioned Patch rejected. I will only consider solutions consistent with opt-out approach used in Bug 251722.
Created attachment 192318 [details] patch version 2 new patch consistant with opt-out approach
Our team is requesting that this make it the 3.3 release. Thanks again.
Comment on attachment 192318 [details] patch version 2 Patch rejected for inconsistency of solution with Bug 251722 (different attribute name and values). Also, I am not going to consider suppression of error messages resulting from malformed extension XML (such as reportMissingAttribute).
See Comment #10 in Bug 251722 for specifics on what I am looking for.
There is no patch attached to bug 251722, which makes it difficult for me to mimic the changes in a manner acceptable to you.
See description in the comment that I referenced, which describes the semantics in detail. Then see the code of the extension point in question.
