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.
There is a clash in the area of glassfish logging (repackaged Apache commons-logging) between NetBeans JSP parser and Creator built-in JSF 1.2 implementation. This needs to be resolved.
The solution is to create a library wrapper module for com.sun.org.apache.commons.** classes and all modules refer to that library wrapper modules and it's now done on my disk. So if you agree I will commit it tomorrow. I created new module org-netbeans-libs-glassfish-logging, which is the wrapper for classes com.sun.org.apache.commons.logging.** . The classes are taken from glassfish build 48. The package com.sun.org.apache.commons.logging is expose as a friend api. For now just jspparser is the only friend. If nobody has a comment, I'm going to commit this.
I need to know more about his clash and these dependencies between the jsp parser and JSF... We might need to notice the ARC team about these dependancies, so please describe more the issue. Also, include someone from GF team (Jerome Dochez?) to review these dependancies so that we can track them . Finally, I am not sure about the lib name mentioning GlassFish. Please ask legal about the name usage...For example, the plugin for AS 9 does not mention GF, and use a different naming (o.n.m.sun.***)
n the logging library there is a specific check, whether the class loaders of the Log interface and the Log implementation is the same. If the classloaders are different, then the getLogConstructor() throws new LogConfigurationException ("Invalid class loader hierarchy. " .... So the jspparser has special classloader, which is constructed from classloader of jsp parser module and some special jars like glassfish-jspparser.jar, which contains logging library. Problem is when an other module use logging as well, then the jsp parser stops to work due to wrong inicialization of logging. There is not any dependencies between jsp parser and JSF. The problem is that both use the same logging libraries, which causes the described problem. From the duplication libraries in NetBeans is better also separate the logging library from jsp parser and create a module wrapper, which can be used by other modules as well. Regarding the name, we already have jarfile, which is called glassfish-jspparser.jar. If you have any suggestion, give me know.
The changes are now in the cvs 55 branch.
So can this be marked as fixed?
Not yet. There is regression connecting with compilation single file. I will close the isseu, when I will be sure, that the regression is fixed.
Now it looks like all problems are solved. Closing this task.
I would like to go with this through the fast track review, because we need to add as friend module from Creator, which introduce cross-cluster dependency. As result of this issue there is module wrapper for com.sun.org.apache.commons.loggin.** library. This module expose the loggin package as friend api and Creator modules need to access this classes as well. We would like to add these modules as new friends: com.sun.rave.libs.jsf.ri12 com.sun.rave.libs.apache.commons
I forgot to assign to the apireview. See the last my comment.
There is the complete list of Creator modules, which will be friends: com.sun.rave.libs.apache.commons com.sun.rave.libs.jsf.ri12 com.sun.rave.j2ee14classloaderprovider
I'm going to commit tomorrow the friend modules.
The new friends are committed in the cvs.
v.