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.

Bug 87042 - EjbJar project exposes annotated components from libraries it depends on.
Summary: EjbJar project exposes annotated components from libraries it depends on.
Status: RESOLVED FIXED
Alias: None
Product: javaee
Classification: Unclassified
Component: EJB Project (show other bugs)
Version: 5.x
Hardware: All All
: P1 blocker (vote)
Assignee: Martin Adamek
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-10-12 23:12 UTC by _ pcw
Modified: 2006-10-15 13:30 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Example project. (22.21 KB, application/octet-stream)
2006-10-13 01:55 UTC, _ pcw 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description _ pcw 2006-10-12 23:12:15 UTC 
Steps to reproduce:

1. Create "LibraryEjbModule" as a JavaEE5 ejb-jar project containing a single
session bean (e.g. "LibraryBean"), targeting Glassfish.
2. Create "MainEjbModule" as a JavaEE5 ejb-jar project, also containing a single
session bean (e.g. "MainBean"), targeting Glassfish.
3. In MainBean, invoke "Call EJB" and select LibraryStateless from the first ejb
module.  (Restart IDE if there are no beans in the list)
4. Now use New | Enterprise | Sun Deployment Descriptor to create
sun-ejb-jar.xml for the "MainEjbModule" project, if it doesn't exist already
(look under Configuration Files).
5. Open sun-ejb-jar.xml in the configuration editor and open the SunEjbJar node
to view the listed session beans.

You should see both MainBean and LibraryBean listed there.  It is Vince's and my
opinion that LibraryBean being listed here is wrong.

Further notes:

* Add a web service to LibraryEjbModule.  The web service will also be shown in
the configuration editor for MainEjbModule.  Ditto for a message driven bean and
probably others.

* After step 5, invoke Call Ejb again and examine the list of ejb's displayed
for MainEjbModule, it will also include LibaryEjb.  This is wrong and shows that
the plugin is not at fault for this misinterpretation.

* You may need to restart the IDE after some of the above steps to continue. 
During some tests, I found that adding annotations, even via the wizards or menu
shortcuts did _not_ cause the resulting annotation to be recognized by the IDE
as such.  For example, if the IDE does not recognize your session beans, the
Call Ejb dialog will be empty.  If you save and restart, it should resync and be
ok.  This is an unrelated bug.
Comment 1 _ pcw 2006-10-13 01:55:25 UTC 
Created attachment 35171 [details]
Example project.
Comment 2 _ pcw 2006-10-13 08:52:54 UTC 
See also issue 87049, whose severity is impacted by whether this issue is fixed
or not.
Comment 4 Martin Adamek 2006-10-13 10:57:45 UTC 
Adding Andrei for review.
Comment 6 Jan Horvath 2006-10-13 12:06:55 UTC 
verified in release55_dev
Comment 7 Martin Adamek 2006-10-13 12:39:36 UTC 
Description of the fix:
Classpath used in annotation listener was stripped to contain only sources and
J2EE platform classpath. This was done for classpath of EJB and WS listeners in
EJB project and for classpath of WS in Web project. It means that all all
Session/MessageDriven beans and WebServices defined in libraries of EJB project
will be ignored. Same applies for all WebServices defined in libraries of Web
project.
Comment 8 Martin Adamek 2006-10-13 12:40:35 UTC 
If Peter and Vince will agree with proposed fix, I will integrate it into
release55 branch on Sunday evening Prague time.
Comment 9 Andrei Badea 2006-10-13 12:49:44 UTC 
The way the fix removes the compilation classpath (apart from the classpath of
the J2EE platform) from the classpath used for finding annotations seems
correct. I can't tell for sure that removing the compilation classpath won't
cause any regressions, but it seems it won't and that it is the right thing to do.
Comment 10 Vince Kraemer 2006-10-13 14:39:14 UTC 
Why is the J2eePlatformClassPath in the MetaDataClassPath for the project? It
seems like this would make this bug less likely to encounter, but still possible?
Comment 11 Vince Kraemer 2006-10-13 15:00:42 UTC 
It looks like this issue was caused by changes for
http://www.netbeans.org/issues/show_bug.cgi?id=82450.  There is a note about JPA
and Web in that issue.  I see that you found stuff in web that needed to get
changed.  Is there a similar issue in JPA?
Comment 12 Martin Adamek 2006-10-13 19:07:53 UTC 
> Why is the J2eePlatformClassPath in the MetaDataClassPath for the project?
It is not classpath for the project. It is classpath provided by project ONLY
for annotation processing. J2EE platform is needed for resolving types of
annotations.

> It seems like this would make this bug less likely to encounter, but still
possible?
I don't know currently about any scenario available in IDE where it could be
possible.

> It looks like this issue was caused by changes for
http://www.netbeans.org/issues/show_bug.cgi?id=82450.
I don't think so. Mentioned changes were all intentional.
  
> There is a note about JPA and Web in that issue.  I see that you found stuff
in web that needed to get changed.  Is there a similar issue in JPA?
JPA has completely independent classpath infrastructure and in JPA it is
required to see Entity classes from class libraries in depending projects (which
is opposite what we need in Web/EJB projects with WSs and EJBs)
Comment 13 _ pcw 2006-10-14 00:03:32 UTC 
The diffs seem fine to me, though not sure I'm qualified for reviewing classpath
impl's (I did notice that the cache mechanism in ClassPathProviderImpl is not
threadsafe, but that's beyond the scope of this issue).  I've been running with
these changes all day and they seem to have fixed the issue I reported and I
have no ill effects to report either.

Looks good by me.
Comment 14 Vince Kraemer 2006-10-14 00:20:39 UTC 
If the user puts an EJB or web service into their J2eePlatform classpath, this
issue may re-occur.  Since the sun plugin doesn't allow the user to alter the
J2EE_PLATFORM_CLASSPATH, there won't be an issue for SJSAS/GF users.  If other
plugins allow the user to alter this property, the user may encounter this issue
again, but they would have to work really hard to get into this state...
Probably by doing questionable things in the ServerManager/Server properties
dialog...

I think this is okay to integrate into release55.
Comment 15 _ pcw 2006-10-14 00:39:02 UTC 
I tried forcing Vince's idea by modifying the j2ee_platform_classpath in
private.properties and it's looks like it's really hard to get into this state
that way (the path is rewritten on every startup, and once read and cached, is
not reread, so the only alternative I see is hacking the appserver jars -- not
likely)

Interesting if other plugins do allow modification of this path and certainly
worth reconsidering for later versions - Is there a way to use a "this project
only" classpath for finding annotations, with the j2ee_platform_classpath only
used for annotation definitions, but nothing else?

I think the current plan is perfectly acceptable for 5.5 though.