Sylvain Wallez wrote:
> This is now fixed, but this problem is very likely to resurface with
> Cocoon blocks : if a block comes with its own jars, Cocoon will have to
> create a classloader for them and set it as the context classloader so
> that block-defined classes can be loaded correctly by A
]]
>>Sent: Tuesday, June 11, 2002 2:03 AM
>>To: [EMAIL PROTECTED]
>>Subject: Re: JNDI in cocoon (related to ClassLoader issues)
>>
>>
>>Hi Geoff,
>>
>>Here's the deal:
>>
>>Jakarta Tomcat, from version 4.0 and on, provides an in-mem
[EMAIL PROTECTED]
> Subject: Re: JNDI in cocoon (related to ClassLoader issues)
>
>
> Hi Geoff,
>
> Here's the deal:
>
> Jakarta Tomcat, from version 4.0 and on, provides an in-memory
> Environment Naming Context (ENC). To enlist an object into this ENC,
>
Sylvain Wallez wrote:
> Nicola Ken Barozzi wrote:
>
>> Peter Royal wrote:
>>
>>
>>> On Monday 10 June 2002 02:38 pm, Sylvain Wallez wrote:
>>>
>>>
>>>
So in short, my proposal is : remove classloading stuff in
CocoonServlet
and move it to ParanoidCocoonServlet. Of course, cl
Nicola Ken Barozzi wrote:
>Peter Royal wrote:
>
>
>>On Monday 10 June 2002 02:38 pm, Sylvain Wallez wrote:
>>
>>
>>
>>>So in short, my proposal is : remove classloading stuff in CocoonServlet
>>>and move it to ParanoidCocoonServlet. Of course, classpath computation
>>>is left unchanged in C
Hi Geoff,
Here's the deal:
Jakarta Tomcat, from version 4.0 and on, provides an in-memory
Environment Naming Context (ENC). To enlist an object into this ENC,
you configure it in server.xml, and then in your web application's
web.xml file. Tomcat keeps a seperate ENC for each web application
c
Peter Royal wrote:
> On Monday 10 June 2002 02:38 pm, Sylvain Wallez wrote:
>
>>So in short, my proposal is : remove classloading stuff in CocoonServlet
>>and move it to ParanoidCocoonServlet. Of course, classpath computation
>>is left unchanged in CocoonServlet.
>
>
> Go for it. Sounds like y
On Mon, 2002-06-10 at 13:38, Sylvain Wallez wrote:
>
> After some investigation in CocoonServlet's classloading stuff (which
> has a lng history), it appears to me that classpath and classloader
> are different issues and that we don't really need the
> RepositoryClassloader there. Discuss
On Monday 10 June 2002 02:38 pm, Sylvain Wallez wrote:
> So in short, my proposal is : remove classloading stuff in CocoonServlet
> and move it to ParanoidCocoonServlet. Of course, classpath computation
> is left unchanged in CocoonServlet.
Go for it. Sounds like you have done your research and a
> From: Sylvain Wallez [mailto:[EMAIL PROTECTED]]
...
> After some investigation in CocoonServlet's classloading stuff (which
> has a lng history), it appears to me that classpath and
classloader
> are different issues and that we don't really need the
> RepositoryClassloader there. Discuss
David Haraburda wrote:
>Hi,
>
>On Sun, 2002-06-09 at 16:28, Nicola Ken Barozzi wrote:
>
>
>>The real reason: Cocoon is not a Servlet.
>>Cocoon conceptually lives in the same space of Tomcat, not on top of it.
>>
>>
>
>I certainly agree that conceptually Cocoon is much more than a simple
>se
Can someone clarify - is JNDI currently broken for cocoon on tomcat or is it
just cut off from tomcat's jndi? I'm beginning work on a component which
will receive jms messages and will hold off if its going to be a battle just
to get the jndi lookup working.
Geoff Howard
---
> From: David Haraburda [mailto:[EMAIL PROTECTED]]
>
> On Sun, 2002-06-09 at 16:28, Nicola Ken Barozzi wrote:
> > The real reason: Cocoon is not a Servlet.
> > Cocoon conceptually lives in the same space of Tomcat, not on top of it.
>
> I certainly agree that conceptually Cocoon is much more than
Hi,
On Sun, 2002-06-09 at 16:28, Nicola Ken Barozzi wrote:
> The real reason: Cocoon is not a Servlet.
> Cocoon conceptually lives in the same space of Tomcat, not on top of it.
I certainly agree that conceptually Cocoon is much more than a simple
servlet -- it is a large and complex system. Ho
From: "David Haraburda" <[EMAIL PROTECTED]>
> Hi all,
>
> This is a second attempt to raise what I feel to be a rather important
> issue, and that is the way CocoonServlet sets up the ContextClassLoader
> for each thread on startup. I think this is bad because (1) It breaks
> JNDI in Tomcat and
Hi all,
This is a second attempt to raise what I feel to be a rather important
issue, and that is the way CocoonServlet sets up the ContextClassLoader
for each thread on startup. I think this is bad because (1) It breaks
JNDI in Tomcat and (2) it conflicts with both the Java API docs and the
J2E
16 matches
Mail list logo
