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.
This issue is related to the issue #206526. JSR311 is in the server classpath in the GF case . But other Jersey jars are not available without extending project classpath. Currently latest GF has a number of such jars: jersey-core.jar jackson-core-asl.jar jackson-jaxrs.jar jackson-mapper-asl.jar jersey-gf-server.jar jettison.jar jersey-multipart.jar mimepull.jar jersey-client.jar jersey-core.jar jersey-json.jar asm-all-repackaged.jar The latter jar files are not part of JEE6 spec and not required in the server classpath. But they still can be used by user in his application. The resulting application could be non-portable ( just WL specific ) but still can be useful. Probably they should be also included into the server classpath. Otherwise some different method could be considered for their enabling. Please note that putting them into the project (not server) classpath is not a good approach: server is bootstrapped with these jars and they are available in the runtime. So no need to include them into the deployment unit of jee project. Extending project classpath with these implementation specific libaries should be avoided ( issue #206527 and #204816 ). As an option : we can skip Jersey implementation specific jars at all. User will be able to add them manually in its classpath. So this is not a real bug but just a question to draw attention .
Cc'ing also David and Jakub. I just saw that David's sample application described at http://jupiter.cz.oracle.com/wiki/view/Netbeans/JavaScriptCRUD uses the @org.codehaus.jackson.annotate.JsonIgnore annotation (see e.g. aaa.Customer class in the SampleDBrest project). David, how important is to have Jackson on the server classpath for this application? Is that an argument for including the additional Jersey jars on the server classpath? Note that David's project currently adds Jersey to the project classpath, which is incorrect per Denis's comment above.
I'm not sure what's the best approach. Traditionally servers were supposed to expose only EE stack APIs and everything else user would have to add to project classpath explicitly. If a jar is part of server runtime but not exposed through server classpath user can always add the jar to project classpath to compile the project and exclude the jar from packaging it and deploying it to server. Having said that it would be good if JSON was supported out of the box considering its popularity and usefulness. I'm guessing that sooner or later it will be likely part of EE spec. Or perhaps in JSON case we could add a Java hint which would check for occurrences of '@Consumes({"application/json"})' or '@Produces({"application/json"})' and suggested to add JSON specific jars to project classpath if they are not there already. Btw. looking at issue 205394 - will a project compile correctly? I would think that "org.codehaus.jackson.annotate.JsonIgnore" will not be on classpath by default.
(In reply to comment #2) > I'm not sure what's the best approach. > > Traditionally servers were supposed to expose only EE stack APIs and everything > else user would have to add to project classpath explicitly. If a jar is part > of server runtime but not exposed through server classpath user can always add > the jar to project classpath to compile the project and exclude the jar from > packaging it and deploying it to server. > > Having said that it would be good if JSON was supported out of the box > considering its popularity and usefulness. I'm guessing that sooner or later it > will be likely part of EE spec. > > Or perhaps in JSON case we could add a Java hint which would check for > occurrences of '@Consumes({"application/json"})' or > '@Produces({"application/json"})' and suggested to add JSON specific jars to > project classpath if they are not there already. That's the option. But it just for JSON with JsonIgnore annotation. On the other hand the problem is more generic and I also don't have a strict preference. >Btw. looking at issue 205394 - > will a project compile correctly? I would think that > "org.codehaus.jackson.annotate.JsonIgnore" will not be on classpath by default. JsonIgnore is added automatically by codegeneration along with XmlTransient annotation. It will be added only if this class is inside projects classpath ( this behavior true for both annotations ). So the answer is yes, the project will compile in any case. If there is no such annotation in the classpath it will not be added at codegen stage.
> Or perhaps in JSON case we could add a Java hint which would ... suggested to add JSON specific jars to > project classpath ... But didn't we say that this should be on server classpath, not project classpath? If we add it to (web) project classpath and the file is already available on the server, then we should at least set it as "do not package in war". Also, I assume we want to add just the extra jars, not API jars, so only a part of the Jersey library should be added. It this a good practice? Or should the Jersey library be split into the 'standard' part and the 'optional' part? Also, I tried how this behaves in Maven, and it's also not optimal, see bug 207682.
(In reply to comment #4) > > Or perhaps in JSON case we could add a Java hint which would ... suggested to add JSON specific jars to > > project classpath ... > > But didn't we say that this should be on server classpath, not project > classpath? If we add it to (web) project classpath and the file is already > available on the server, then we should at least set it as "do not package in > war". That's exactly why I've created this bug. It is not a problem when jar is present for project classpath and in the server classpath at the same time. But this is not optimal. > > Also, I assume we want to add just the extra jars, not API jars, so only a part > of the Jersey library should be added. It this a good practice? Or should the > Jersey library be split into the 'standard' part and the 'optional' part? > > Also, I tried how this behaves in Maven, and it's also not optimal, see bug > 207682.
Here is the proposition copied from the issue #207682 : server classpath could be divided onto two type classpathes. One part is the "static" classpath ( with the same behavior as now , f.e. only JEE6 related classes). The other part is "dynamic" classpath. The second part is related to the project. It shouldn't be included into the resulting deployment unit. So it behaves as server classpath. On the other hand it should contain additional jars bundled with the server. There should be an API that allows to modify this classpath. Such solution will allows to us to solve this issue in a general way.
Cc'ing Petr H as the owner of the server integration API. Just a few clarifying questions: - Would the dynamic classpath be retrieved from the server plugin through some new API in j2eeserver? - What do you mean by the "API that allows to modify this classpath"? Would this be some API on the side of the server plugin, or on the side of the project? What exactly would happen when you modify the dynamic classpath using this API? - Can you please describe what exactly will happen in each user-level scenario? Thanks.
(In reply to comment #7) > Cc'ing Petr H as the owner of the server integration API. Just a few clarifying > questions: > > - Would the dynamic classpath be retrieved from the server plugin through some > new API in j2eeserver? That's is one of option in the server oriented approach. > - What do you mean by the "API that allows to modify this classpath"? Would > this be some API on the side of the server plugin, or on the side of the > project? What exactly would happen when you modify the dynamic classpath using > this API? I don't know actually what is the appropriate place for such API. It is related to the both : server and project. It could be a special JARs in the project classpth. Such JARs should have some "attribute" that define those jars as out of lib ( they should not be copied into the resulting build artifacts ). The current behavior as I understand is to copy all jars that are not under server library into the build directory. They will be used in the deployment unit. On the other hand such JARs could be part of server classpath. In the latter case they will not be copied into the build directory ( the current behavior ). But there is no currently the possibility to modify server classpath. On the server side such API should allows to add server bundled jars ( it seems this API should also give the list of available jars ) into the "extended" server classpath. > - Can you please describe what exactly will happen in each user-level scenario? Actually this is done above. Let's use the nodes to describe: Project -- | Compile classpath | | | -- external.jar Server classpath | -- .... -- JEE6 API jars - ..... Consider Jersey libraries. They are implementation specific . So they are not at the JEE6 API jars. Currently user are able to add them into the Compile classpath. As result they will be added into the lib folder inside deployment unit. But such jars exist already at server runtime. So they are actually unnecessarily. F.e. currently WL server classpath contains most of Jersey JARs and user is able to use them without compilation errors in its project. GF users should add them explicitly. What do I suggest : REST wizard could use "extended" server classpath and and Jersey classpath into the "project related server classpath". As result those jars will not be copied in the lib folder of deployment unit but there will not be compilation errors. Project -- | Compile classpath | | | -- external.jar Server classpath | - "static JEE5 jars" | | | -- .... | -- JEE6 API jars | - ..... - "extended project related classpath" | - Jersey JARs - ..... Different approach could be applied as well: Project classpath cold be divided onto two types (in the same way as for server classpath ): JARs that will be copied into the lib of deployment unit and JARs that are present in the classpath only for possibility to compile. I'm not an expert of Maven but it seems it has similar concept : JARs that should be used ONLY for compilation ( they will not be used to packaged unit ) and JARs that are used also in the resulting package. Such approach allows to use more generic approach: any type of JAR ( not just server bundled ) could be used in this way. I'm adding Jesse as a Maven expert. > > Thanks.
I thought that since we have javaee.specs.support module it should not matter much what's on server classpath. If REST support needs to know what's in runtime classpath of application server or not it should introduce an SPI into javaee.specs.support and let servers implement it - different versions of the same server can answer such SPI differently. And based on the answers REST support can do whatever it is needed, for example in GlassFish case it can add JSON support jars to project compilation classpath only. As a fallback you could always add JSON jars to project compilation and runtime classpath - the fact that jars might be already included in server runtime is sort of not that important.
That's a good point David. javaee.specs.support sounds like a suitable place. Regarding Denis's comment: > The current behavior as I understand is to copy all jars that > are not under server library into the build directory. No, not exactly. Ant-based web project has a "Package" checkbox in the Libraries section of the project properties, which controls whether this library is copied to build, or whether it's compile-only.
...and in Maven project a similar thing is achievable using org.netbeans.modules.maven.classpath.CPExtender.CLASSPATH_COMPILE_ONLY. (See org.netbeans.modules.j2ee.ejbcore.api.codegeneration.SessionGenerator.createRemoteInterfacePackage under j2ee.ejbcore for a usage of this.)
(In reply to comment #9) > I thought that since we have javaee.specs.support module it should not matter > much what's on server classpath. If REST support needs to know what's in > runtime classpath of application server or not it should introduce an SPI into > javaee.specs.support and let servers implement it - different versions of the > same server can answer such SPI differently. And based on the answers REST > support can do whatever it is needed, for example in GlassFish case it can add > JSON support jars to project compilation classpath only. It is exactly the current situation. The question is not REST functionality itself but the plugin behavior. Currently the server plugin add all Jersey JARs in the project classpath in case JEE5 profile and don't add anything in case JEE6 profile. So there is no problem on JAX-RS side . This is a question for serverplugin side. That's why this bug is not in the REST component. > > As a fallback you could always add JSON jars to project compilation and runtime > classpath - the fact that jars might be already included in server runtime is > sort of not that important.
(In reply to comment #10) > That's a good point David. javaee.specs.support sounds like a suitable place. > > Regarding Denis's comment: > > > The current behavior as I understand is to copy all jars that > > are not under server library into the build directory. > > No, not exactly. Ant-based web project has a "Package" checkbox in the > Libraries section of the project properties, which controls whether this > library is copied to build, or whether it's compile-only. I didn't know that. But I don't see API for ANT based project to achieve this . Could someone please point it to me ? >...and in Maven project a similar thing is achievable using >org.netbeans.modules.maven.classpath.CPExtender.CLASSPATH_COMPILE_ONLY. (See >org.netbeans.modules.j2ee.ejbcore.api.codegeneration.SessionGenerator.createRemoteInterfacePackage >under j2ee.ejbcore for a usage of this.) Right. I see the API for Maven project only. That's a half problem solution. Something like this I need for Ant based project and all problems will be solved.
(In reply to comment #13) > (In reply to comment #10) > > That's a good point David. javaee.specs.support sounds like a suitable place. > > > > Regarding Denis's comment: > > > > > The current behavior as I understand is to copy all jars that > > > are not under server library into the build directory. > > > > No, not exactly. Ant-based web project has a "Package" checkbox in the > > Libraries section of the project properties, which controls whether this > > library is copied to build, or whether it's compile-only. > > I didn't know that. > But I don't see API for ANT based project to achieve this . > Could someone please point it to me ? > >...and in Maven project a similar thing is achievable using > >org.netbeans.modules.maven.classpath.CPExtender.CLASSPATH_COMPILE_ONLY. (See > >org.netbeans.modules.j2ee.ejbcore.api.codegeneration.SessionGenerator.createRemoteInterfacePackage > >under j2ee.ejbcore for a usage of this.) > Right. I see the API for Maven project only. That's a half problem solution. > Something like this I need for Ant based project and all problems will be > solved. I see there is ClassPath.EXECUTE . I've never used it. Probably this is exactly what is needed ?
I think original suggestion is too serverplugin centric. The "dynamic classpath" looks really complicated. I would recommend adding those jars on project classpath (specs.support may provide them) while excluding them from packaging (may require change in web.project or generic CP infrastructure).
(In reply to comment #15) > I would recommend adding those jars on project classpath (specs.support may > provide them) while excluding them from packaging (may require change in > web.project or generic CP infrastructure). Agreed. It seems this is already exists. At least for Maven. So this is more generic approach.
For Ant, you can use org.netbeans.modules.j2ee.common.project.CompilationOnlyClassPathModifier from j2ee.common friend API, or its subclass org.netbeans.modules.web.project.api.WebProjectLibrariesModifier in web.project (see also usages of this in websvc.manager and websvc.wsitconf). Which I think is a fine solution, but a more systemic and robust solution would be to support this use case directly in the ClassPath API - that way there could be a common interface that would work across Ant and Maven projects. I filed issue #207717 for this. One other question about this - if you have the ability to add non-standard Jersey jars to the compile-only classpath, wouldn't you still need some API from the plugin that would tell you whether these jars are present on the server classpath? Based on this, the jars would be either added to the compile-only classpath or to the compile(+runtime) classpath.
(In reply to comment #17) > For Ant, you can use > org.netbeans.modules.j2ee.common.project.CompilationOnlyClassPathModifier from > j2ee.common friend API, or its subclass > org.netbeans.modules.web.project.api.WebProjectLibrariesModifier in web.project > (see also usages of this in websvc.manager and websvc.wsitconf). Which I think > is a fine solution, but a more systemic and robust solution would be to support > this use case directly in the ClassPath API - that way there could be a common > interface that would work across Ant and Maven projects. I filed issue #207717 > for this. OK , thanks. I agree that there should be a common way for both Ant based and Maven projects. > > One other question about this - if you have the ability to add non-standard > Jersey jars to the compile-only classpath, wouldn't you still need some API > from the plugin that would tell you whether these jars are present on the > server classpath? Based on this, the jars would be either added to the > compile-only classpath or to the compile(+runtime) classpath. Once again: this is a serverplugin bug. It is not a REST bug. Project is extended with Jersey libraries AT THE SERVER PLUGIN SIDE. javaee.specs.support module IS ALREADY USED for this purpose. Server plugin has all knowledge about its libraries and decides what exactly jars and how should be added. There is just one special method. It allows do not include method like "get available Jersey related librries" into the API. This method is just "extendsJerseyProjectClasspath". The project is a parameter for this this method. So it's a responsibility of the server plugin change project classpath in the desired way (based in JEE profile also). The problem here is that JaxRsStackSupport implementation on the serverplugin side is written by me not module owner.
> Project is extended with Jersey libraries AT THE SERVER PLUGIN SIDE. Ok, now I understand, thanks for the explanation.
So as I understand from the issue #207717 there are already requested functionality : EXECUTE and COMPILE type of classpath. But it seems Web project f.e. uses COMPILE classpath in the same way as EXECUTE. Jars from COMPILE type classpath should not be added in the resulting lib folder of build directory. They should be available at the project for its compilation. At the other hand EXECUTE classpath should be used only for packaging.
(In reply to comment #20) > But it seems Web project f.e. uses COMPILE classpath in the same way as > EXECUTE. > Jars from COMPILE type classpath should not be added in the resulting lib > folder > of build directory. They should be available at the project for its > compilation. > At the other hand EXECUTE classpath should be used only for packaging. This make sense but historically somebody implemented it differently and I'm not sure it is worth to change it now. Also read what Tomas said in issue 207717 in comment #7.
(In reply to comment #21) > (In reply to comment #20) > > But it seems Web project f.e. uses COMPILE classpath in the same way as > > EXECUTE. > > Jars from COMPILE type classpath should not be added in the resulting lib > > folder > > of build directory. They should be available at the project for its > > compilation. > > At the other hand EXECUTE classpath should be used only for packaging. > > This make sense but historically somebody implemented it differently and I'm > not sure it is worth to change it now. Also read what Tomas said in issue > 207717 in comment #7. Yes, I agree. Change this behavior now could introduce many problem.
(In reply to comment #20) > EXECUTE classpath should be used only for packaging. If we are talking about ClassPath constants, the meaning is that COMPILE is what would be passed to javac -classpath, whereas EXECUTE represents what is expected to be available at runtime via e.g. Class.forName (excluding BOOT). ClassPath is not concerned with where a JAR comes from or how it might or might not be distributed. By contrast, ProjectClassPathModifier may interpret constants which deal with these concerns.
Note wrt. issue 209573, which is somewhat related: when addressing this issue, we need to make sure that correct repository+artifact id is used in the Maven case. I.e. need to point to a real Maven repository, not to a local repository using an "unknown.binary" artifact id.
Bug #209602 could help for that.
*** Bug 207682 has been marked as a duplicate of this bug. ***
A question related to this issue: Denis has recently implemented issue 209713, which simplifies the REST configuration UI. Now there is just one configuration checkbox called "Use Jersey specific features". I assume that we will add the extra jar files (Jackson etc.) only if the user checked this checkbox, correct?
(In reply to comment #27) > A question related to this issue: Denis has recently implemented issue 209713, > which simplifies the REST configuration UI. Now there is just one configuration > checkbox called "Use Jersey specific features". I assume that we will add the > extra jar files (Jackson etc.) only if the user checked this checkbox, correct? That's the way I've considered it to work.
What is the bug in the serverplugin? I have tried to read through this issue but haven't been able to find a clear explanation of the change you expect in the server plugin. Are there steps that I could follow to replicate the issue? Do you have a pointer to the code that you think is incorrect? Is there an API that needs to get a GF implementation that hasn't gotten one yet? (In reply to comment #18) > (In reply to comment #17) > > For Ant, you can use > > org.netbeans.modules.j2ee.common.project.CompilationOnlyClassPathModifier from > > j2ee.common friend API, or its subclass > > org.netbeans.modules.web.project.api.WebProjectLibrariesModifier in web.project > > (see also usages of this in websvc.manager and websvc.wsitconf). Which I think > > is a fine solution, but a more systemic and robust solution would be to support > > this use case directly in the ClassPath API - that way there could be a common > > interface that would work across Ant and Maven projects. I filed issue #207717 > > for this. > OK , thanks. > I agree that there should be a common way for both Ant based and Maven > projects. > > > > One other question about this - if you have the ability to add non-standard > > Jersey jars to the compile-only classpath, wouldn't you still need some API > > from the plugin that would tell you whether these jars are present on the > > server classpath? Based on this, the jars would be either added to the > > compile-only classpath or to the compile(+runtime) classpath. > Once again: this is a serverplugin bug. > It is not a REST bug. > Project is extended with Jersey libraries AT THE SERVER PLUGIN SIDE. > javaee.specs.support module IS ALREADY USED for this purpose. > Server plugin has all knowledge about its libraries and decides what exactly > jars and how should be added. There is just one special method. > It allows do not include method like "get available Jersey related librries" > into the API. > This method is just "extendsJerseyProjectClasspath". The project is a parameter > for this this method. So it's a responsibility of the server plugin change > project classpath in the desired way (based in JEE profile also). > > The problem here is that JaxRsStackSupport implementation on the serverplugin > side is written by me not module owner.
(In reply to comment #29) > What is the bug in the serverplugin? I have tried to read through this issue > but haven't been able to find a clear explanation of the change you expect in > the server plugin. > > Are there steps that I could follow to replicate the issue? > > Do you have a pointer to the code that you think is incorrect? > > Is there an API that needs to get a GF implementation that hasn't gotten one > yet? > There is no incorrect code. The issue is just a proposition that should help to have various types of classpath for the project with JEE target server. Currently there is the issue #207717 which is exactly about required API support on the project side. So this issue currently is just a reminder to implement the feature with different project's classpath types for Jersey ( Jersey is a part of the REST WS stack which is implemented on the server plugin side ).
Created attachment 119604 [details] Screenshot of the approximate desired state In other words, right now when you: 1. Create a Java EE web project with GlassFish 3 target 2. Create a REST service using one of the wizards, and while doing this, check the "Use Jersey specific features" checkbox then the project classpath will only contain the server platform jars. The suggestion is that it should also contain the extra Jersey jar files that provide additional features beyond the spec, for compilation only - they should not be packaged in the war, because they are already available on the runtime classpath when the app runs in GlassFish. I am attaching the screenshot of the approximate desired state, i.e. a few more jars on the classpath with "Package" checkbox unchecked. (Or better, GlassFish would create a library "Jersey Extras from GlassFish" - analogous to "EclipseLink from GlassFish" - and add this library to the project classpath with "Package" unckecked.)
There are other things that we have to consider: ------------------------------------------------ 1) GlassFish already contains more Jersey jars than the small set that is exposed as part of JavaEE in server classpaqth. 2) Adding those non-JavaEE Jersey jars into project classpath may cause conflicts with jars that are already bundled with Glassfish. Unfortunately isolation between System/Application level class loaders is not working with Jersey. It's known GlassFish issue with Jersey 1.X but there is not working solution now. Good solution for Jersey is to allow more than pure JavaEE to be provided in server classpaqth. Use-case scenarios for this: ---------------------------- Add Server: * NB offers additional checkbox to decide if pure JavaEE or all GlassFish jars will be available as server classpath. * User makes his selection using this checkbox * When 'all jars available' selection is effective, NB offers to select individual classes outside 'pure JavaEE' set to be available as server classpath * User tags classes that he wants in server classpath Server Properties (Services/Server): * The same scenario like in 'Add Server' We will have to extend GUI to allow this selection and modify the way how server classpath is built. Actually it just reads content of lib/javaee.jar. New version should be able to read all modules and their dependencies.
I have to add one more note to Jersey. -------------------------------------- Not all Jersey jars are available as GlassFish modules so user may still want to add some jars into his project. But in this case only those missing in modules may be provided from project classpath ant they should be the same version as Jersey in GlassFish modules. Another problem is build classpath vs. runtime classpath (user still should write and build his application with any set of JavaEE/Jersey/etc. libraries that are not packaged in deployed bundle). -------------------------------------------------------------------------------- At this point GlassFish module supports just pure JavaEE and nothing more. We may try to implement some extension to work with modules as I proposed in comment 32.
(In reply to comment #32) > Good solution for Jersey is to allow more than pure JavaEE to be provided in > server classpaqth. > [...] > We will have to extend GUI to allow this selection and modify the way how > server classpath is built. I do not think GlassFish server classpath should be configurable per GlassFish registration in IDE. If you look at it from the team point of view then your proposal would require that each team member has to configure their GlassFish instance in IDE the same way otherwise all sorts of compilation issues will arise. And unfortunately such server classpath configuration would not be shareable via VCS. I'm loosing track of what this issue is about. What Petr says in comment #31 makes sense to me. What else do we need? If there are some combinations of Jersey jars which users may find useful we should turn them into GlassFish server libraries and let user decides what they want, eg. "Jersey Extras from GlassFish for ABC", "Jersey Extras from GlassFish for XYZ". These libraries should cover common scenarios. Allowing users to select Jersey jars on jar level is too fine grained and requires too much Jersey specific knowledge and is I think too error prone. Having said that IDE does not prevent users from going that way - they can modify project compilation classpath any way they want. IDE just will not help them much.
I'm just trying to work with the fact that GlassFish modules contains much more than JavaEE nowadays. And NetBeans is simply ignoring it. Also using project supplied jars bundled with application may cause errors. This issue is exactly about what I'm proposing. See bug description. But you are true with team point of view. But there is still way to resolve it. we may move this server classpath jars selection to project level: We have 'Project' and 'Server' entities and there is also relation 'Run project on server' which is configured in project properties (and create application wizard). We can attach things that I proposed to this relation and move JavaEE/All + modules jar selection here - maybe just one more tab in Libraries category. This will let us to save it with project settings and share it on team level.
Tomas and I discussed this in person, I think we now have a common understanding of the proposed solution (for post-7.2).
Requested functionality is implemented via issue #207717. Feel free to close it ( Jersey and some other non JEE6 stuff could be added automatically to the project's classpath. It is up to you to do it ).
(In reply to comment #37) > Requested functionality is implemented via issue #207717. > Feel free to close it ( Jersey and some other non JEE6 stuff could be > added automatically to the project's classpath. It is up to you to do it ). To clarify what I meant : 1) The issue could be closed because the requested functionality is provided by other way via fix in the #207717. It is possible now to extend project's COMPILE_ONLY classpath with Jersey libraries . I will do all required changes on the server side plugin and in the client code which requires Jersey libs. 2) Feel free to close it if there are no other plans to improve JEE server library node as "Libraries" subnode. That's out of the scope of requested functionality. So this is up to assignee.
We already did changes to pass jersey libraries from server modules but I did not make this available on GF module. We use it in Glassfish cloud module in LibraryImplementation. This is being solved in bug# 216383. I'm closing this bug as bug# 207717 duplicate now. *** This bug has been marked as a duplicate of bug 207717 ***