DO NOT REPLY [Bug 16580] New: - XSP ClassLoader not integrated with Cocoon's classloader.

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16580

XSP ClassLoader not integrated with Cocoon's classloader.

           Summary: XSP ClassLoader not integrated with Cocoon's
                    classloader.
           Product: Cocoon 2
           Version: 2.0.4
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: Critical
          Priority: Other
         Component: core
        AssignedTo: cocoon-dev@xml.apache.org
        ReportedBy: derisor@arcor.de


When deploying a XSP page, the current cocoon requires that all jars be 
deployed in the WAR file that contains the XSP in order to compile the XSP or 
run the XSP. This is a major problem in situations where Cocoon is deployed 
into an application server. In this instance there are many problems because 
the application server could be using hundreds of different libraries on large 
scale projects. When wrting XSP pages to the EJBs in that application server I 
would need to copy every single jar into my Coccon WAR file. This is 
untennable. 

The situation arises where a EJB is deployed in another JAR file into an 
application server. The authored XSP needs to connect to that EJB so it 
acquires the Home interface of that EJB and then uses it to request a remote 
interface. Once it has that, it requests services of the EJB. However the XSP 
wont even compile unless the EJB's classes are in the classes directory or lib 
directory of cocoon. If you are deploying an XSP that integrates 50 or more 
EJBs into a view, this would be .... bad. 

Interestingly, if the user writes a generator in Java, extending cocoon with a 
class, instead of XSP and deploys it into cocoon, everythign will work fine. 
When cocoon runs that generator, it uses the application server's classloader 
and loads everythign fine despite the classes not being present in the cocoon 
war. The problems seem to only have to do with XSP compilation and execution. 

The resolution should be that the compiler should use the classloader of the 
application server, or merely just the same classloader that cocoon uses at 
runtime.

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org