cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: classDirURL = jndi protocol?!
Date Wed, 31 Oct 2001 15:28:16 GMT
Yes, this should work.

Could you please take care of this - as I will leave
the office just right now until monday morning...

Thanks,
Carsten

> -----Original Message-----
> From: Morrison, John [mailto:John.Morrison@uk.experian.com]
> Sent: Wednesday, October 31, 2001 4:26 PM
> To: 'cocoon-dev@xml.apache.org'
> Subject: RE: classDirURL = jndi protocol?!
> 
> 
> OK.
> 
> if (servletContextPath != null) {
> 	// use old behaviour
> } else {
> 	// use current new behaviour
> }
> 
> yes?
> 
> > -----Original Message-----
> > From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> > Sent: Wednesday, 31 October 2001 2:55 pm
> > To: cocoon-dev@xml.apache.org
> > Subject: RE: classDirURL = jndi protocol?!
> > 
> > 
> > 
> > Morrison, John wrote:
> > > 
> > > Sorry, my mistake about the branch - I must have update'd 
> > with a A by
> > > accident (mussel memory ya know :)
> > > 
> > Yes, I suffer from that sometimes, too.
> > 
> > > How can we test to see if getRealPath works?  Check for not null?
> > Yes, the CocoonServlet has now an instance variable servletContextPath
> > which can be tested against null for this.
> > 
> > Carsten
> > > 
> > > Any ideas why I'm getting the jndi protocol? (what does it stand for
> > > anyway?)
> > > 
> > > > -----Original Message-----
> > > > From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
> > > > Sent: Wednesday, 31 October 2001 2:44 pm
> > > > To: cocoon-dev@xml.apache.org
> > > > Subject: RE: classDirURL = jndi protocol?!
> > > > 
> > > > 
> > > > Hi John,
> > > > 
> > > > first, you are not using the cocoon_20_branch. I changed only
> > > > the HEAD of the cvs.
> > > > 
> > > > Now, the changes are required to get rid of the 
> > getRealPath() calls
> > > > which will not work if you are using a war Cocoon as a 
> > war file and
> > > > the servlet engine does not unpack it.
> > > > 
> > > > As we can't use getRealPath(), we have problems with building the
> > > > classpath anyway, as we can't scan the WEB-INF directory anymore.
> > > > I currently see only two choices:
> > > > 1) use getRealPath() and we won't run as a war file.
> > > > 2) don't use getRealPath() and we can't use our own classloader.
> > > >    And so Cocoon does not run in many servlet engines due to
> > > >    class conflicts.
> > > > 
> > > > I hope there is a third solution. We could of course do a 
> > combination:
> > > > a) Test if getRealPath() can be used and then create our own 
> > > > classloader
> > > > b) if getRealPath() is not working we hope that the servlet engine
> > > >    does not cause any class conflicts.
> > > > 
> > > > So any suggestions are welcome.
> > > > 
> > > > Carsten
> > > > 
> > > > Morrison, John wrote:
> > > > >
> > > > > Hi folks!
> > > > >
> > > > > I updated my source this morning and discovered that I couldn't
> > > > > get anything
> > > > > to work!  The sitemap was failing to compile (it couldn't 
> > > > find an Avalon
> > > > > component).  Curious.  I opened the log to view the 
> > > > classpath cocoon was
> > > > > working on and found:
> > > > >
> > > > > Classpath =
> > > > > 
> > jndi:/localhost/cocoon/WEB-INF/classes;..\bin\bootstrap.jar;d:\wrk
> > > > > file2\java
> > > > > \jdk1.3\lib\tools.jar;
> > > > >
> > > > > This was caused by the change in CocoonServlet.java on 
> > Tuesday by
> > > > > cziegeler:
> > > > >
> > > > >   +        try {
> > > > >   +            classDirURL =
> > > > > this.servletContext.getResource("/WEB-INF/classes");
> > > > >   +        } catch (java.net.MalformedURLException me) {
> > > > >   +            this.log.warn("Unable to add 
> > WEB-INF/classes to the
> > > > > classpath", me);
> > > > >   +        }
> > > > >   +        try {
> > > > >   +            libDirURL =
> > > > > this.servletContext.getResource("/WEB-INF/lib");
> > > > >   +        } catch (java.net.MalformedURLException me) {
> > > > >   +            this.log.warn("Unable to add WEB-INF/lib to 
> > > > the classpath",
> > > > > me);
> > > > >   +        if (libDirURL != null &&
> > > > > libDirURL.toExternalForm().startsWith("file:")) {
> > > > >   +            root = new 
> > > > File(libDirURL.toExternalForm().substring(5));
> > > > >   +        }
> > > > > <snip/>
> > > > >   +        if(classDirURL != null) {
> > > > >   +            
> > buildClassPath.append(classDirURL.toExternalForm());
> > > > >
> > > > >                if (this.addClassDirs) {
> > > > >                    try {
> > > > >   +                    classLoader.addURL(classDirURL);
> > > > >                    } catch (Exception e) {
> > > > >   +                    log.debug("Could not add directory " 
> > > > + classDirURL,
> > > > > e);
> > > > >                    }
> > > > >                }
> > > > >            }
> > > > >
> > > > >   +        if (root != null && root.isDirectory()) {
> > > > >                File[] libraries = root.listFiles();
> > > > > <snip/>
> > > > >
> > > > > my URL's are returned as:
> > > > >
> > > > > libDirURL: jndi:/localhost/cocoon/WEB-INF/lib
> > > > > classDirURL: jndi:/localhost/cocoon/WEB-INF/classes
> > > > >
> > > > > These obviously arn't files, what can I do to get this jndi
> > > > > protocol to work
> > > > > and add the jar's to the classpath?
> > > > >
> > > > > Help...?! :)
> > > > >
> > > > > Oh, using JSDK 1.3.0, W2K, TC 4.0.1, latest cvs up of 20_branch.
> > > > >
> > > > > J.
> > > > >
> > > > >
> > > > > 
> > > > ==============================================================
> > > > =========
> > > > > Information in this email and any attachments are 
> > > > confidential, and may
> > > > > not be copied or used by anyone other than the addressee, 
> > > > nor disclosed
> > > > > to any third party without our permission.  There is no 
> > intention to
> > > > > create any legally binding contract or other commitment 
> > > > through the use
> > > > > of this email.
> > > > >
> > > > > Experian Limited (registration number 653331).
> > > > > Registered office: Talbot House, Talbot Street, 
> > Nottingham NG1 5HF
> > > > >
> > > > > 
> > > > 
> > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > > > >
> > > > 
> > > > 
> > > > 
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > > > 
> > > 
> > > 
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> > 
> 
> 
> =======================================================================
> Information in this email and any attachments are confidential, and may
> not be copied or used by anyone other than the addressee, nor disclosed
> to any third party without our permission.  There is no intention to
> create any legally binding contract or other commitment through the use
> of this email.
> 
> Experian Limited (registration number 653331).  
> Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

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


Mime
View raw message