Community
Participate
Working Groups
Build Identifier: 20100529234347 1. Create an empty EJB project via New EJB Project Wizard. 2. There is "An EJB module must contain one or more enterprise beans" error message in Problems view. 3. Set the severity level for "No enterprise bean in the EJB project" problem in Preferences->Validation->EJB 3.x Validator->Settings to WARNING. 4. Re-build the project. 5. The severity is still ERROR for the problem in Problems view. BTW, why it is an ERROR by default? IMO it should be a WARNING. You can have an EJB 3.x jar without any ejb beans inside if you want. It won't be very useful but it will be deployed and work. For example you can use plain Seam components there. I think it's not good to have a project marked right after creation unless the project is REALLY broken. It causes a problem for JBoss Seam Tools which creates an EJB project with a plain Seam component and doesn't have any EJB bean unless user adds it. Such a project works fine but EJB validator marks it as broken. Reproducible: Always
This is really a severe usability issue and makes no sense; you don't get 'A java project must contain at least one java class' Errors nor warnings when you haven't added a class yet since it might all be provided by other means.
I agree this "should" be a warning... but this error comes from the schema validator - and if some servers deploy with validation on, it will fail. Now your question about the preference.... This seems to be an issue with the settings not being used... Kaloyan?
This should not come from the schema validator (in EJB 3.x), because XML is not mandatory. It depends on the appserver, if the deploy will fail. Perhaps, JBoss' appserver permits EJB modules without EJBs... (Max?) I think it will be easy to change the severity to Warning.
Created attachment 171292 [details] patch Simply changes the severity level.
I would like to mark this as a hotbug. 1. Affiliation JBoss Tools and JBoss Developer Studio relies or will rely on JEE 6 features. 2. Be clear on which release you want this bug to be fixed in, or "last workable" date, if requesting a patch. . The first Helios release which claims to be supporting JEE 6 3. Justify why this is a hotbug. Note that "our users don't like the bug" is not the type of reason that gets much attention. The motivation we are looking for to justify a P1-like priority is, basically, "this bug blocks our adoption of WTP" (explaining why, of course). This bug makes users think they *must* have ejb beans in their ejb module which is *not* true for many applications based on CDI or Seam or Spring. But ejb modules are still used because of how things are packaged in Eclipse. We find that introducing such hard wrong ful Errors will hurt Eclipse WTP adoption for users and releasing without the possibility to disable it as end user or adopter is definitely a major usability issue.
I take it back :) Since EJB 3.0 The schema has a cardinality 0..1 on beans... Should it even be a warning?
(In reply to comment #6) > I take it back :) Since EJB 3.0 The schema has a cardinality 0..1 on > beans... > > Should it even be a warning? Exactly - it makes no sense ;) btw. cardinality of the schema is 0 because its possible to only use annotations to declare this - but again, that is not a requirement for a valid deployment afaik since you can still have normal java classes in here that is available just fine.
I did some more research on the topic. The original bug that introduces this validation is bug 119311. The EJB 3.0/3.1 specifications says the following of the number of enterprise beans in an ejb-jar (Chapter 20.1 - Packaging > Overview): "An ejb-jar file produced by the Bean Provider contains **one or more** enterprise beans... " So, according to the EJB 3.0/3.1 the cardinality is still 1..*. The difference with the 0..* cardinality in the ejb-jar.xml schema comes from the fact that the ejb-jar.xml is not the only source of metadata. If the there is no bean in the xml then at least one is expected as an annotated Java class. I tested the behavior of some runtimes. I created a simple example EAR + Web module + EJB module with no beans, based on Java EE 5 or Java EE 6 depending on the runtime. - GlassFish 2.1 (EE 5) and GlassFish 3 (EE 6). This is the RI of the Java EE spec. - If the EJB module contains an ejb-jar.xml and/or the sun-ejb-jar.xml (vendor's descriptor), then the deployment fails. - If the EJB module has no xml descriptor, then the deployment is successful. This is because the server does not recognize the exported jar as ejb-jar. - SAP NW server. The EJB module deploys successfully with and without deployment descriptor. Here the runtime tolerates 0..* cardinality. I think every server runtime has a different answer to this question. But we cannot ignore the behavior of GlassFish since it is the reference implementation of the Java EE spec. And since the assumption is that users create EJB project to place some enterprise beans, we should keep this validation to hint them that there next step is to create an EJB.
Now, how this validation can be overcome by vendor specific scenarios, like the one of JBoss. I see several options: 1) Switch off the EJB 3.x Validator in the vendor's product. 2) Change the Severity of this validation message to WARNING or IGNORE in the vendors product. See step 3 of the initial description of this bug. There is bug at the moment, but I will soon attach patch fixing it. This setting can be applied to specific project. So, when new EJB Seam project is created this validation can be set to IGNORE. 3) Add exclusion rule. Exclusion rules can be based on natures and facets. I suggest that in the JBoss' case the EJB project is created together with some facet or nature that introduces Seam capabilities. If proper exclusion rules are added the validation can ignore EJB Seam project. Such rule can be added by the users in the EJB 3.x Validator settings (see again that step 3). I guess such exclusion rule can be also contributed with some extension point in an appropriate vendors plugin. Max, does the above sounds meaningful for you? At the end we have to find a solution that satisfies all use cases.
Created attachment 171384 [details] better patch This patch makes the severity of the validation marker depend on the settings of the EJB 3.x Validator, i.e. fixes the bug described in step 3 of the initial bug description. The default severity is back to ERROR. This default setting is still open for discussion.
We can override that default for our full product, but can't do that for our plugins which are intended to be installed/used on top of Eclipse plus I don't really think this is specific to JBoss as the SAP example showed :) IMO the correct default should be Warning and not error. btw. I didn't really follow the #3 option about exclusion rules?
IMHO, from a quick read, this seems suitable to put in our quick maintenance release, instead of rush into post RC4 builds. Any bugs for that should be blocking, prevent function or tools from being used. I think I gleaned where this was a bad usability bug? Let me know if my quick read wasn't enough ... but otherwise please re-target to 3.2.1. Thanks,
I target this bug back to 3.2.1 since there are plenty of option to workaround the validation. In 3.2.1 the patch will: 1) make the severity of the validation configurable 2) change the default severity to Warning. It's true that there are many vendors (including SAP) that does not stick rigidly to the Java EE specification, but in WTP we are supposed to develop vendor neutral tools and we should closely look at the specifications and the reference implementations. And, of course, we should provide adopters with option to override any behavior if they don't like it. And in this case, there are really plenty of options to override this validation. The more I look at the validation framework, the more I see its flexibility. Perhaps, the easiest for JBoss will be just to remove the EJB 3.x Validator by contributing to the "org.eclipse.wst.validation.removeV2Validator" in any of the plugins delivered by JBoss. I see other options too, but I'd suggest to ask in the wtp-dev list since I am not an expert in the validation framework.
Created attachment 171520 [details] patch v3 This patch changes the default severity to Warning. It keeps the change from previous patch to make the severity dependent on the preference settings.
Ok. I tried to use an exclusion rule to disable EJB3 validator for Seam/CDI projects. It works. But it's ok since the validator only checks if a project has EJBs. But when this validator contains some other useful checks then it won't be a good solution anymore. So the possibility to set the severity to a WARNING for this particular validation rule is important anyway.
Alexey, I am happy to see this works for you. As I mentioned in 3.2.1 the severity of this validation will default to Warning. Any new validation rules will be added in the Indigo (next year) release at earliest.
"It's true that there are many vendors (including SAP) that does not stick rigidly to the Java EE specification, but in WTP we are supposed to develop vendor neutral tools and we should closely look at the specifications and the reference implementations. " Because a spec says things *must* contain a certain thing does not mean validations should be errors. If that were followed in all IDE's you would have so many errors which would disturb you while working since you would be seeing errors that aren't really errors in most development environments either because you development time setup doesn't have all things configured before at runtime or because your runtime allows some flexibility. It is really a shame to see WTP keep adding more and more of these rigid validations in. Same goes for locations of files and libraries - WTP will rather follow runtime deployment specs but ignores how developers actually have them stored differently at dev time, but that is a topic of another discussion. Again, this would not be so bad if the user actually were able to configure it and for the 3.2.0 if the patch doesnt get applied they will have no choice. Of course they can use the exclusion rules, but try explain that to users. We can workaround this hack but honestly I find it very weird that you accept 3.2.0 will have different defaults than 3.2.1 concering what level errors/warnings are on by default when it can easily be fixed before the release. I'll leave it up to you, I tried outlining why I think its the wrong defaults to bring out in the GA release.
Committed to HEAD for 3.2.1 and 3.3
