This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
build 041013 when deploying empty EjbModule there is ambigous error message. It isn't clear where is the problem: Deployment failed on target localhost:4848_server : Deployment Error -- Error loading deployment descriptors for Module1Ejb Line 8 Column 21 -- cvc-complex-type.2.4.b: The content of element 'enterprise-beans' is not complete. One of '{"http://java.sun.com/xml/ns/j2ee":session, "http://java.sun.com/xml/ns/j2ee":entity, "http://java.sun.com/xml/ns/j2ee":message-driven}' is expected.
This is the error message from the xml validating parser, as returned by the deployent backend.
RESOLVED/LATER is not a valid resolution, reopening. This still sounds like a valid bug, needs to be evaluated. If this can not be fixed now, just set target milestone accordingly.
TM 5.0 -> TBD
Pavel: most and more people see this bug, so this is real user feedback. I think 1/ empty ejb module should mark a red flag icon on the ejb-jar.xml if there (j2ee.14 and sometimes ee 5). 2/ furthermore, part of the inline verification or packaging steps, NetBeans should allow verification, but disallow the deploy, run or debug actions as we know an ejbmodel cannot be empty. This applies also to EAR that contains incomplete ejbmodules... Should we raise this to P2 or make sure it is fixed in 5.5 timeframe? Marking as 5.5. This is independant of server targets, and more a spec check at the project level
Should we make XML validation part of build? That would make the build fail before the deployment in a "validate" target so it would be easier to understand what is wrong. I have not measured but I guess the time would not be too significant to be noticed by the user it the validation passes.
Comment from a mailing list: Netbeans seems to package invalid ejb jar fairly often: there is no ejb-jar.xml or EJB component annotations (@Stateful, @Stateless, @MessageDriven) inside the packaged ejb jar. This invalid packaging is causing the inconsistent module state error when users redeploys such application on glassfish/appserver9. https://glassfish.dev.java.net/issues/show_bug.cgi?id=546 http://forums.java.net/jive/thread.jspa?threadID=14134&tstart=0 There is something we could do from the appserver side to reject such invalid ejb jar so user doesn't see this scary error message. But because it was too close to the 9.0 FCS build, it was decided to defer this check in to 9.1. So it's very important that NetBeans fix this packaging problem so users who use netbeans with appserver9/glassfish won't keep running into this problem.
Raise it to P2 since lots of people ran into problems when they redeploy the invalid ejb jar packaged by netbeans on glassfish/appserver9. So we have to fix the packaging in netbeans. And note: 1. For any ejb jar before EJB30 time, a valid ejb-jar.xml is required (with at least one session/entity/message driven bean defined). 2. For EJB30 ejb jar, it needs to either contain a valid ejb-jar.xml (with at least one session/entity/message driven bean defined) or ejb component annotations (@Stateless, @Stateful, @MessageDriven).
I suggested a partial solution for EJB 2.1 (validation). Any suggestions how to solve this for EJB 3.0? Compare this with web module or jsf where we also do not catch all errors before deployment. I think this complex check is a task for the verifier. It is too bad that app server has a bad error message but I do not see an easy fix for all cases, specifically for EJB 3.0. I am not sure I have resources to implement an ant task that would process EJB annotations, merge them with the metadata from a potential DD and decide if the module is valid. We have code that processes annotations and ejb-jar.xml in netbeans but not in a form that could be called from ant. If there was such an ant task I would be happy to call it. No problem with this being P2 if it is confusing many people. But Ludo, do not set target to 5.5 for bugs assigned to me unless you can suggest a fix. Thanks.
I agree we should leverage the existing logic in appserver instead of duplicating the effort. I have sent Ludo the relevant code to tell whether a jar is a ejb jar or not. Please work with Ludo see if that code can be used in this case. And we have filed a bug in verifier (not in 9.0, will be fixed in 9.1): https://glassfish.dev.java.net/issues/show_bug.cgi?id=516 Can the packaging problem I reported be solved separately from this validation logic? For example, do not package a persistence unit as ejb jar. https://glassfish.dev.java.net/issues/show_bug.cgi?id=546 The wrong packaging is the part I worry the most.
Yes, we will fix that in 9.1 or for that matter in 9.0UR1. I just want to say that, even in the current state of things, verifier will report a FAILURE when any component tries to access any of the persistence units defined in that persistence.xml file.
I am still struggling ot refactor this code: too many deps... ? Unless Hong can extract this little piece calculating for only the 3 types of ejb? on a pure Nb side, a nb projects *has* to know at any time how many ejbs (3.0 or 2.1) just for Jsr 88 to work, no? For ex: the call ejb action has to list them. So maybe what is missing is to cache this syntetic info (has ejb or nor) in an ant propertie of the project, for further processing?
Ludo, you are asking something I already said. So again, yes, we have code that processes annotations and ejb-jar.xml in netbeans and knows what EJBs there are but not in a form that could be called from ant. We still do not have the validity check. We could probably check the number of EJBs if that is all that is needed (?). But only when you deploy from netbeans, not from head less mode. This would be a work around. A real solution would be the ant task that would work from headless build too.
I know we have some work to do for the deployment validation and I will try to help out in that aspect. But could we please fix the packaging first? That seems to me has the higest priority. If user uses netbeans to package application, the resulted ejb jar should be a valid ejb jar.
Agree with packaging, in the sense that the check if there are any EJBs should be done the same way for all server and it should be during the build (before deployment).
Ludo/Hong, should I wait for you to come up with some solution or should I try to hack around using the information that is available in IDE? If there is a chance that this can be resolved by the code you have and that is independent on Netbeans/MDR I would wait since the hack will not be pretty (calling from Ant back into IDE to check the validity of EJB module).
An interesting observation - while this is a high priority P2 issue for NetBeans, the corresponding GlassFish issue (546) is a P4.
My comments w.r.t why the glassfish issue is a P4: 1. The bug in the netbeans is the packaged application containing invalid ejb jar. The bug in the appserver is we need to handle this negative case gracefully. IMO, wrong packaging is more serious than improving error handling. 2. However, the bug in the appserver should probably be a P3. I did try to convince the person who is in charge of 9.0 FCS release we should fix this. But the timing of this bug was not very good, it came up just before we were ready to build the final 9.0 FCS build. It was just too risky to fix it at that time. I will fix it in 9.1. Lots of users will try to use netbeans with appserver9.0 and if they keep hitting this problem, it will have big negative impact on both. So I really hope the invalid packaging can be fixed in netbeans soon. BTW: I am not sure about the status of Ludo's refactoring. Ludo, please let me know if you have any specific questions that I could help with.
Ok, I've heard enough of "really hope it will be fixed" and that it confuses "a lot of people". We had the same problem in 4.1 and 5.0 and the issue was actually filed by our QA engineer, not by any external users and it was closed by Ludo as Resolved/Later. There are no duplicates filed by users, AFAIK. In web apps which are used far more then EJB we do not make any check during packaging and I have never seen any user to complain about this (since netbeans 3.6, at least). The confused users complain about the error message in GF which is P4, it is you who are complaining about the packaging. I have yet to see the contribution. Reassigning to Ludo as he has the ball now. Please do not comment until you figure out if you can make the code from Hong work. We are all wasting time with this fruitless discussion.
The security policy generation has been changed in the appserver 9.0. That change combined with this invalid ejb jar packaging caused new problems. Also the persistence unit is a new feature in appsever 9.0. Though the invalid packaging was not reported before, it might be reported more often now. This issue, for example, is filed by an external user. https://glassfish.dev.java.net/issues/show_bug.cgi?id=546
*** Issue 76784 has been marked as a duplicate of this issue. ***
I sent Pavel the code.
*** Issue 77760 has been marked as a duplicate of this issue. ***
My understanding of the current situation is: 1/ For Java EE 5 EJB modules, the error message was improved in Appserver 9 UR1, so this is no longer an issue there. 2/ For J2EE 1.4, the message is still cryptic (even in the latest AS 9 UR1 - see this issue: https://glassfish.dev.java.net/issues/show_bug.cgi?id=819), but this is the same behavior as in AS 8.x, and we lived with it so far without major user complaints. Is this correct? If so, is this still a P2 bug, or is the priority now lower?
Yes, I still think it is a P2. The root cause of the problem is the invalid packaging of ejb jar. The change in the Sun Appserver only warns the user there is something wrong in their jar and prevent them from proceeding further. It doesn't fix the invalid packaging. And this invalid packaging applies to all JavaEE compatible servers and not just Sun Appserver. So we still need a fix in the netbeans code.
Although GlassFish has been fixed to report a nice message for incorrect packaging of EJB 3.0 apps, it should be fixed in NetBeans as well. Although one may argue that NetBeans may not be able to catch all kinds of packaging mistakes and I agree to that, this issue is an exception. It is a fairly important one to be caught by NetBeans. Secondly, if there is any particular usecase in NetBeans that leads to such packaging, then that should probably be investigated as well. I am saying this because I have seen too many users facing this issue. Sahoo
I would just want to clarify this: it seems that the biggest problem is with EJB 2.1 module that is not covered by the code that I got from Ludo. It only seems to work with annotations. I want an algorithm that solves the whole problem before I invest into creating a new ant task, etc.
For EJB 2.1, it should be very straightforward: it must contain a ejb-jar.xml which declares at least one bean (this is enforced by the schema/dtd syntax). For EJB3.0, things are more complicated, you could have an optional ejb-jar.xml when you use component level annotations. Lduo is on vacation till the week of July 24th.
I'm changing priority to P3 because the message for EJB 3.0 is already sufficient and for EJB 2.1 this should be resolved by fixing corresponding issue on glassfish https://glassfish.dev.java.net/issues/show_bug.cgi?id=819
I want to re-iterate this problem is not specific to Sun Appserver. And even when user uses Sun Appserver to deploy. When they get the error message from the appserver, they still need to figure out how to re-package the application. So we should not mis-package the application in the first place. I've seen quite a few cases of this type of mispackaging already though appserver9/netbeans5.5 beta just came out.
The team responsible for this issue has agreed on P3 priority. We acknowledge that this is a valid defect, but we reserve the final say in determining the priority. Do not change back again, please.
*** Issue 80189 has been marked as a duplicate of this issue. ***
See also glassfish bug <https://glassfish.dev.java.net/issues/show_bug.cgi?id=1049>
Evaluating for 6.0 again. It is P5 in my mind, because the use-case of trying to deploy project without EJBs doesn't make any sense. Is it done by somebody testing actions in popup menu or invoking them randomly or what? I would close it as WONTFIX and spend time on real bugs.
Martin.. I would almost agree with you, except for one thing... The Java EE 5 spec makes this problem worse... not better. I have seen a number of e-mails from users that have created an ejb jar project and then put entity classes into it and tried to deploy it. Since an entity class isn't an entity bean, people get very confused... because they think they have created "things" that are EJBs... but they aren't.
It's true that we can not stop user from packaging such invalid ejb jars manually. But is there something we can do in the Netbeans to ensure at least the ejb jar packaged by Netbeans is valid? Via a post-packaging validation sort of thing?
Perhaps we could mark the project as invalid through a badge on the project top level node? That would give the user a hint that something is wrong. The only problem with that would be that EJB projects would be marked as invalid right after creation, which does not look good. Ideas welcome.
Though it will not look pretty after the project is marked as invalid, the module itself is invalid. I think it's better to tell users earlier so they can fix it rather than they find it later themselves and complain "but Netbeans created this module!". ;-) Can we also show some warning messages to users as to why the module is invalid so they know how to fix it? Thanks.
Will look into it again in 7.0
correct the TM.
Not planned for 6.8
I agree with Martin Adamek that this issue should be marked as wontfix: The resolution was to mark project as broken if it doesn't contain any EJB bean. It's easily doable for new projects (to scan every newly created project), but it could cause performance troubles since there would be needed to listen on all files and have to be refreshed for any file change. So it should require expensive meta model support which would be applied just for this issue. I think that this issue shouldn't affect real users - create EJB without EJB bean is quite strange use case. And the priority decreased with JavaEE6 where big part of all EJB apps will be developed as a web project. So from my point of view it would bring more troubles than advantages and I'm suggesting to close with WONTFIX resolution.
According to the last comment. It would bring more cons than pros. Also nobody mentioned additional comment so I'm closing this issue as WONTFIX. I also took a look more on that and there is even built the model over sources but there isn't still when to call refresh for this broken support.