You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Marcos Sanz/Denic <sa...@denic.de> on 2002/03/20 15:02:11 UTC
Cascading PolicyClassLoaders, a bug?
Hi all,
I have researched the problem that I mentioned yesterday and it seems to me
to be a systematic flaw:
Embeddor calls Deployer.
Deploying first application: ClassLoaderManager creates first application's
ClassLoader, setting as a parent the current thread's context ClassLoader
(still the right parent). Deployer calls Kernel and Kernel calls
Application.start(). Key point now:
ThreadContext.setThreadContext(m_context.getThreadContext()) changes
current thread's context ClassLoader to be the first applications's
ClassLoader ("for calling visitors", it's ok).
But now Deployer deploys the next application, and ClassLoaderManager
creates second application's ClassLoader, setting as a parent the current
thread's context ClassLoader, which is the wrong parent, since it is first
application's ClassLoader.
Third application would set as a parent the second application's
ClassLoader and so on...
Peter, Leo: is this a bug? Have I overseen something?
Best regards,
Marcos Sanz
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Cascading PolicyClassLoaders, a bug?
Posted by Peter Donald <pe...@apache.org>.
Hi,
Redirecting this to the phoenix list...
I just made some changes tonight to fix this I think. Funnily enough it had a
TODO right above it indicating that it should be fixed ;)
I haven't fully tested it and wont have a chance till Monday but all prelim
tests seem to work. Could you try your application and see if it fixes your
problems?
On Thu, 21 Mar 2002 01:02, Marcos Sanz/Denic wrote:
> Hi all,
>
> I have researched the problem that I mentioned yesterday and it seems to me
> to be a systematic flaw:
>
> Embeddor calls Deployer.
>
> Deploying first application: ClassLoaderManager creates first application's
> ClassLoader, setting as a parent the current thread's context ClassLoader
> (still the right parent). Deployer calls Kernel and Kernel calls
> Application.start(). Key point now:
>
> ThreadContext.setThreadContext(m_context.getThreadContext()) changes
> current thread's context ClassLoader to be the first applications's
> ClassLoader ("for calling visitors", it's ok).
>
> But now Deployer deploys the next application, and ClassLoaderManager
> creates second application's ClassLoader, setting as a parent the current
> thread's context ClassLoader, which is the wrong parent, since it is first
> application's ClassLoader.
>
> Third application would set as a parent the second application's
> ClassLoader and so on...
>
> Peter, Leo: is this a bug? Have I overseen something?
>
> Best regards,
> Marcos Sanz
--
Cheers,
Pete
-------------------------------------------------------
"I would like to take you seriously but to do so would
affront your intelligence" -William F. Buckley, JR
-------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Cascading PolicyClassLoaders, a bug?
Posted by Peter Donald <pe...@apache.org>.
Hi,
On Thu, 21 Mar 2002 01:02, Marcos Sanz/Denic wrote:
> Hi all,
>
> I have researched the problem that I mentioned yesterday and it seems to me
> to be a systematic flaw:
>
> Embeddor calls Deployer.
>
> Deploying first application: ClassLoaderManager creates first application's
> ClassLoader, setting as a parent the current thread's context ClassLoader
> (still the right parent). Deployer calls Kernel and Kernel calls
> Application.start(). Key point now:
>
> ThreadContext.setThreadContext(m_context.getThreadContext()) changes
> current thread's context ClassLoader to be the first applications's
> ClassLoader ("for calling visitors", it's ok).
>
> But now Deployer deploys the next application, and ClassLoaderManager
> creates second application's ClassLoader, setting as a parent the current
> thread's context ClassLoader, which is the wrong parent, since it is first
> application's ClassLoader.
>
> Third application would set as a parent the second application's
> ClassLoader and so on...
>
> Peter, Leo: is this a bug? Have I overseen something?
Naah you are correct. I will see about doing something about it today.
--
Cheers,
Pete
*--------------------------------*
| Every rule has an exception, |
| except the rule of exceptions. |
*--------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Cascading PolicyClassLoaders, a bug?
Posted by Peter Donald <pe...@apache.org>.
Hi,
Redirecting this to the phoenix list...
I just made some changes tonight to fix this I think. Funnily enough it had a
TODO right above it indicating that it should be fixed ;)
I haven't fully tested it and wont have a chance till Monday but all prelim
tests seem to work. Could you try your application and see if it fixes your
problems?
On Thu, 21 Mar 2002 01:02, Marcos Sanz/Denic wrote:
> Hi all,
>
> I have researched the problem that I mentioned yesterday and it seems to me
> to be a systematic flaw:
>
> Embeddor calls Deployer.
>
> Deploying first application: ClassLoaderManager creates first application's
> ClassLoader, setting as a parent the current thread's context ClassLoader
> (still the right parent). Deployer calls Kernel and Kernel calls
> Application.start(). Key point now:
>
> ThreadContext.setThreadContext(m_context.getThreadContext()) changes
> current thread's context ClassLoader to be the first applications's
> ClassLoader ("for calling visitors", it's ok).
>
> But now Deployer deploys the next application, and ClassLoaderManager
> creates second application's ClassLoader, setting as a parent the current
> thread's context ClassLoader, which is the wrong parent, since it is first
> application's ClassLoader.
>
> Third application would set as a parent the second application's
> ClassLoader and so on...
>
> Peter, Leo: is this a bug? Have I overseen something?
>
> Best regards,
> Marcos Sanz
--
Cheers,
Pete
-------------------------------------------------------
"I would like to take you seriously but to do so would
affront your intelligence" -William F. Buckley, JR
-------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Cascading PolicyClassLoaders, a bug?
Posted by Leo Simons <le...@apache.org>.
definately a bug. You volunteering? ;)
- Leo
PS: suppose you're forced to use windows by the sysadmins.
Suppose you're on a deadline. Suppose the backup runs
windows, too. Suppose your private backup is corrupt.
Okay, so it costs us a few thousand $. But hey, I get to
install linux on my laptop now.... =)
> -----Oorspronkelijk bericht-----
> Van: Stephen McConnell [mailto:mcconnell@apache.org]
> Verzonden: Wednesday, March 20, 2002 3:11 PM
> Aan: Phoenix-Dev
> CC: Avalon Developers List
> Onderwerp: RE: Cascading PolicyClassLoaders, a bug?
>
>
>
> Moving this to the Phoenix list.
>
> Marcos Sanz/Denic wrote:
> >
> > I have researched the problem that I mentioned yesterday and it
> > seems to me to be a systematic flaw:
> >
> > Embeddor calls Deployer.
> >
> > Deploying first application: ClassLoaderManager creates first
> > application's
> > ClassLoader, setting as a parent the current thread's context
> ClassLoader
> > (still the right parent). Deployer calls Kernel and Kernel calls
> > Application.start(). Key point now:
> >
> > ThreadContext.setThreadContext(m_context.getThreadContext()) changes
> > current thread's context ClassLoader to be the first applications's
> > ClassLoader ("for calling visitors", it's ok).
> >
> > But now Deployer deploys the next application, and ClassLoaderManager
> > creates second application's ClassLoader, setting as a parent
> the current
> > thread's context ClassLoader, which is the wrong parent, since
> it is first
> > application's ClassLoader.
> >
> > Third application would set as a parent the second application's
> > ClassLoader and so on...
> >
> > Peter, Leo: is this a bug? Have I overseen something?
>
> Looks like a bug to me.
>
> Cheers, Steve.
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Cascading PolicyClassLoaders, a bug?
Posted by Stephen McConnell <mc...@apache.org>.
Moving this to the Phoenix list.
Marcos Sanz/Denic wrote:
>
> I have researched the problem that I mentioned yesterday and it
> seems to me to be a systematic flaw:
>
> Embeddor calls Deployer.
>
> Deploying first application: ClassLoaderManager creates first
> application's
> ClassLoader, setting as a parent the current thread's context ClassLoader
> (still the right parent). Deployer calls Kernel and Kernel calls
> Application.start(). Key point now:
>
> ThreadContext.setThreadContext(m_context.getThreadContext()) changes
> current thread's context ClassLoader to be the first applications's
> ClassLoader ("for calling visitors", it's ok).
>
> But now Deployer deploys the next application, and ClassLoaderManager
> creates second application's ClassLoader, setting as a parent the current
> thread's context ClassLoader, which is the wrong parent, since it is first
> application's ClassLoader.
>
> Third application would set as a parent the second application's
> ClassLoader and so on...
>
> Peter, Leo: is this a bug? Have I overseen something?
Looks like a bug to me.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Cascading PolicyClassLoaders, a bug?
Posted by Stephen McConnell <mc...@apache.org>.
Moving this to the Phoenix list.
Marcos Sanz/Denic wrote:
>
> I have researched the problem that I mentioned yesterday and it
> seems to me to be a systematic flaw:
>
> Embeddor calls Deployer.
>
> Deploying first application: ClassLoaderManager creates first
> application's
> ClassLoader, setting as a parent the current thread's context ClassLoader
> (still the right parent). Deployer calls Kernel and Kernel calls
> Application.start(). Key point now:
>
> ThreadContext.setThreadContext(m_context.getThreadContext()) changes
> current thread's context ClassLoader to be the first applications's
> ClassLoader ("for calling visitors", it's ok).
>
> But now Deployer deploys the next application, and ClassLoaderManager
> creates second application's ClassLoader, setting as a parent the current
> thread's context ClassLoader, which is the wrong parent, since it is first
> application's ClassLoader.
>
> Third application would set as a parent the second application's
> ClassLoader and so on...
>
> Peter, Leo: is this a bug? Have I overseen something?
Looks like a bug to me.
Cheers, Steve.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>