I am using 10/19 IDE dialy build with JDK 5.0, Appserver 8 UR2 on Win XP
In sun-ejb-jar.xml GUI editor, it fail to check for the dup of Message
Destination Jndi Name.
Steps to recreate:
(1) Create any new J2EE project
(2) EJBModule node -> Configuration Files -> open sun-ejb-jar.xml in GUI mode
(3) Click on Message Generation, enter two entries with the same Jndi Name, it
did not detect the duplication of Jndi names.
We can do some checks for duplication here... not sure how far we should go, but
I guess anything within a single module is acceptable as we can easily have a
per-DeploymentConfiguration registry of what JNDI names have been used and apply
this to anything that is manually entered.
I'm loathe to prevent the user from entering duplicate names but rather would
prefer to simply flag names as conflicting in a warning message. Additionally,
while I think the zero-config code should not intentionally create a duplicate,
the JNDI names that it generates are synchronized with the various code
generators in the various J2EE project types. If it doesn't generate the
expected name, then the generated code will be wrong. There is no practical way
to for the code generators to inspect what JNDI name we generated either (they
work independent of what the selected server is).
this would be addressed by the changes for 95131. linking
Defer to after NB6.
See also issue 114366.
Is it time to work on this now? Or should we just close this? (and issue 114366)???
Why close them? They are legitimate requests. If they are closed, noone will ever look at them again and improvements
in this area will certainly never happen.
I suppose you could make one or both enhancement requests. It does not matter to me.
This did not apply to our 6.5 priorities, since v3 did not really support EJB. i think that will be different for 7.0...
I guess this should be a p2 issue.
Please be ready to discuss this issue on 2008/10/22
--> P4, not easy to fix, mostly relevant to J2EE 1.4
not worth worrying about in 7.0 time frame
*** Bug 114366 has been marked as a duplicate of this bug. ***