This content has been marked as final.
Show 7 replies
-
1. Re: Context ClassLoader - POJO
starksm64 Jan 22, 2008 7:00 PM (in response to adrian.brock)Who is going to have to configure the aspect, the bean deployment, or would this be setup by the deployer in the absence an override config? (not sure you can detect that other than a flag saying not to install the aspect).
-
-
3. Re: Context ClassLoader - POJO
adrian.brock Jan 24, 2008 7:16 PM (in response to adrian.brock)"scott.stark@jboss.org" wrote:
Who is going to have to configure the aspect, the bean deployment, or would this be setup by the deployer in the absence an override config? (not sure you can detect that other than a flag saying not to install the aspect).
There is no aspect. The classloader will set automatically from the configured classloader.
For beans created from the deployment layer, it will be the classloader of the deployment
unless there is a specific one in the xml. -
4. Re: Context ClassLoader - POJO
adrian.brock Jan 24, 2008 7:25 PM (in response to adrian.brock)"adrian@jboss.org" wrote:
JIRA issue: http://jira.jboss.com/jira/browse/JBMICROCONT-230
I've done this. There are two issues remaining.
I wasn't really sure how the Callbacks hang together so I've done the setting
of the context classloader in a very fine grained way. i.e. setting the classloader
before doing any callbacks rather than on a per callback basis.
The other issue is that there are somethings not tested (and may not work :-)
e.g. the KernelContextAware callbacks and I'm not entirely sure what
class attribute callbacks are, so I don't know how to test them :-)
Ales, can you see what other callbacks onto the bean that you've added
might also need this processing and add tests? -
5. Re: Context ClassLoader - POJO
adrian.brock Jan 24, 2008 7:45 PM (in response to adrian.brock)"adrian@jboss.org" wrote:
"scott.stark@jboss.org" wrote:
Who is going to have to configure the aspect, the bean deployment, or would this be setup by the deployer in the absence an override config? (not sure you can detect that other than a flag saying not to install the aspect).
There is no aspect. The classloader will set automatically from the configured classloader.
For beans created from the deployment layer, it will be the classloader of the deployment
unless there is a specific one in the xml.
We should probably raise a feature request for such an aspect for runtime invocations?
i.e. write an aspect that introduces a KernelControllerContextAware onto the POJO and
steals the classloader from it during deployment.
Then it sets the context classloader to that classloader during invocations on the object. -
6. Re: Context ClassLoader - POJO
alesj Jan 25, 2008 10:10 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
Ales, can you see what other callbacks onto the bean that you've added
might also need this processing and add tests?
OK, I'll have a look.
btw: the installs have different CL usage as callbacks
Installs have it per install instance, where callbacks are grouped in a single set.
Why the difference? -
7. Re: Context ClassLoader - POJO
adrian.brock Jan 25, 2008 10:45 AM (in response to adrian.brock)"alesj" wrote:
btw: the installs have different CL usage as callbacks
Installs have it per install instance, where callbacks are grouped in a single set.
Why the difference?
I thought I explained it above? Let me reword it :-)
* The classloader usage is the same from the user's point of view.
e.g. The addDeployer() invocation on the MainDeployer will have the context classloader
of the Deployer being added regardless of which mechanism is used.
It's different from our point of view because install and incallback are implemented
in different ways.
* I didn't understand how the callbacks hang together so I just wrapped all the
processing inside the classloader change. If it causes problems then
we (most likely you :-) will have to workout how to do it more fine-grained.
I also assumed this would take care of the callbacks like the class attribute
that I didn't know existed, let alone understand.