[JBoss AOP Development] New message: "Re: ClassPool Refactoring"
by Flavia Rainone
JBoss development,
A new message was posted in the thread "ClassPool Refactoring":
http://community.jboss.org/message/527915#527915
Author : Flavia Rainone
Profile : http://community.jboss.org/people/flavia.rainone@jboss.com
Message:
--------------------------------------------------------------
> alesj wrote:
> It depends how and were things are cached.
This cache I'm talking about is one that is ScopedClassPool. It contains only the ctClasses created by that particular CP.
> alesj wrote:
>
> Since, of course you should be able to re-deploy things, while Classpool still reflect proper/actual state.Undeploy should evict related things from cache as well.
>
> Re-deploy is the only scenario I see as valid, that would change the structure/state.
If something is undeployed, isn't the ClassLoader simply "thrown away"? The same will happen to the CP.
Plus, if something is redeployed, isn't a new ClassLoader created for the new deployment? Since every CP is associated with a CL, we would hence have a new CP for that new CL, and the old cache would be automatically discarded.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527915#527915
14 years, 10 months
[JBoss Web Services Development] New message: "Reviewing jbossws installation"
by Alessio Soldano
JBoss development,
A new message was posted in the thread "Reviewing jbossws installation":
http://community.jboss.org/message/527900#527900
Author : Alessio Soldano
Profile : http://community.jboss.org/people/alessio.soldano@jboss.com
Message:
--------------------------------------------------------------
As you might have noticed, some things are changing recently in the way JBossWS is installed in the AS.
* The jbossws-common, jbossws-framework and jbossws-spi have been moved out of the deployer dir to common/lib, see .
* The services / factories impl declaration have been moved to descriptor only jars in the native stack, see https://jira.jboss.org/jira/browse/JBWS-2921.
* We have a jira (https://jira.jboss.org/jira/browse/JBWS-2923) for moving all the remaining libs of jbossws to common/lib
* Richard correctly pointed out we might also want to move the jbossws-console to common/deploy.
Generally speaking, given the direction we've been moving recently, I think we might want to re-think the idea of jbossws install process to a given server profile / configuration (default, all, standard, etc.) only. Considering the issues we've had in the past with users not correctly deploying to the profile they want, the requirements I had when working on the EAP 5 CXF TP, the current solution with multiple *-deploy.conf files (which is not that good), the fact client and common/lib dirs are shared, etc.. there's probably no reason any more for installing to a given profile only. At least that's more error prone than before. So we might want to always deploy to every profile meant for including webservices functionalities.
Do you have any comment on this? Otherwise I'm creating a jira for this.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527900#527900
14 years, 10 months
[JBoss Microcontainer Development] New message: "Re: CallbackItem.changeCallback() very expensive due to context tracking"
by Kabir Khan
JBoss development,
A new message was posted in the thread "CallbackItem.changeCallback() very expensive due to context tracking":
http://community.jboss.org/message/527859#527859
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
> alesj wrote:
> Yeah, I think it you're right.
> Since, if the context/scopeInfo's scope key doesn't include certain scope level,
> looking additioanlly with C doesn't really help -- same result as with B.
> e.g. B's MetaData is just a collection of Cs
I tried in AS and it does not go through to the expensive bit after the first few beans of the bootstrap (probably the ones installed before the context tracker). I've removed that code anyway and committed against https://jira.jboss.org/jira/browse/JBKERNEL-102
> alesj wrote:
>
> For ContextTracker retrieval, this should only be called once, as we should get the CT on the first call.
> (CT is setup in AS -- see kernel.xml, but not by default for MC tests)
>
It looks like the initial call is expensive, but necessary, so my benchmarks are not realistic in this case. I put in some log statements and we do get some multiple calls to scopeInfo.getMetaData() instances but the overhead is low, total of 6ms on AS startup so there is no point in caching.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527859#527859
14 years, 10 months
[EJB 3.0 Development] New message: "Re: EJBTHREE-2007: VFS Abstraction"
by John Bailey
JBoss development,
A new message was posted in the thread "EJBTHREE-2007: VFS Abstraction":
http://community.jboss.org/message/527781#527781
Author : John Bailey
Profile : http://community.jboss.org/people/johnbailey
Message:
--------------------------------------------------------------
I missed one reference to VirtualFileAdapter that will not allow a simplistic approach to work.
The class org.jboss.injection.ServiceRefInjector creates a VirtualFileAdapter from the InjectionContainer:getRootFile. In the case of VFS3 this will actually by the VirtualFileWrapper instance, which will not be compatible at runtime.
So we are going to have to account for this in some way. What else uses InjectionContainer:getRootFile? I am only seeing it used by the ServiceRefInjector, but I may be missing some references. If this is the only use, we could have the InjectionContainer actually create the instance to the VirtualFileAdapter and keep it outside EJB3 core..
Thoughts?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/527781#527781
14 years, 10 months