February 2009 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Generated Classes not found if they do not match any of

by adrian＠jboss.org

"kabir.khan(a)jboss.com" wrote : "kabir.khan(a)jboss.com" wrote : | | When we want to USE a proxy from a different classloader, we need to be able to load the proxy class. Proxies have unique names (static counter maintained by proxy factory across all loaders). In the example I gave deploymentA's proxy for ArrayList will be AOPProxy$1, and deploymentB's proxy for ArrayList will be AOPProxy$2 (both in the default package) | | | | So I want to be able to look up "AOPProxy$1" from deploymentB, and "AOPProxy$2" from deploymentA. That is what is not working at the moment. Yes that is because the package is not exported, as discussed above. anonymous wrote : | It uses the proxied class's package if the classname does not start with "java" or "sun". For example: | -a proxy for java.util.ArrayList is AOPProxy$1 (currently in default package) | -a proxy for org.jboss.some.Thing is org.jboss.some.AOPProxy$2 | | Only JDK classes should not be in the package of the proxied class, and we need to find another home for these. Deployment classes are causing no problem. | | In short, we always use the classloader of the deployment rather than the classloader of the class we are proxying. This happens whether it is a system class (ArrayList) or something else. There might be interface introductions etc. that need to be able to see classes from the deployment classloader, so that is the easiest way. | My concern was that you had one class for all deployments defined against the "first" classloader, which could later get redeployed and thus cause that classloader to leak. It doesn't sound like you are doing that. The other deployments will only use those classes from other deployments if they are directed to do so, e.g. by passing an object that uses that class. OFF TOPIC: But it does sound like you are generating instrumented classes for things like java.util.ArrayList in every deployment which could be minimized if they were shared in the AOP classloader. I get your point about introductions, but isn't that an edge case? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206626#4206626 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206626

15 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: jboss-ejb3-project

by ALRubinger

"wolfc" wrote : The aim of the game is not to get an unified assembly, but to get a diverse set of components which can form different assemblies. For example EJB 3 + Remoting 3, EJB 3 + QOS Cache, or just EJB 3 lite. Thus satisfying more use cases with less code bases. I agree. Then jboss-ejb3 should not declare dependencies, but rather configure the versions to be used for dependencyManagement. So jboss-ejb3 becomes a POM project decending from jboss-ejb3-build, and as5-int, as6-int, ejb3-embeddable, ejb3-plugin use jboss-ejb3 as a parent. The unified assemblies can come the final projects in the chain. S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206622#4206622 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206622

15 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Generated Classes not found if they do not match any of

by kabir.khan＠jboss.com

"kabir.khan(a)jboss.com" wrote : | When we want to USE a proxy from a different classloader, we need to be able to load the proxy class. Proxies have unique names (static counter maintained by proxy factory across all loaders). In the example I gave deploymentA's proxy for ArrayList will be AOPProxy$1, and deploymentB's proxy for ArrayList will be AOPProxy$2 (both in the default package) | So I want to be able to look up "AOPProxy$1" from deploymentB, and "AOPProxy$2" from deploymentA. That is what is not working at the moment. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206619#4206619 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206619

15 years, 3 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Generated Classes not found if they do not match any of

by kabir.khan＠jboss.com

I think we have crossed wires :-) "adrian(a)jboss.org" wrote : "kabir.khan(a)jboss.com" wrote : "adrian(a)jboss.org" wrote : | | | You haven't answered why it is defined against the user classloader? | | | See my point about classloader leaks. | | | | | | | | | | I guess I'm not understanding what you are doing. But what you described above | | doesn't match what you originally said. | | | | Above you have deploymentB using the proxy class from its classloader | | but earlier you want it to see deploymentA's class? | | | I'm not really sure what you mean here, but I'll try to answer what I think you're asking :-) We don't create a proxy class every time we go to the proxy factory. There is a cache of generated classes which is used behind the scenes. When we want to CREATE a proxy class we ask the factory for it. The first time it generates it using the deployment's classloader and caches it. Subsequent attempts to CREATE the same proxy for the same classloader return the cached copy for that classloader. In another classloader if we want to CREATE a proxy for the same class we end up with a new generated proxy cached for that classloader. When we want to USE a proxy from a different classloader, we need to be able to load the proxy class. Proxies have unique names (static counter maintained by proxy factory across all loaders). In the example I gave deploymentA's proxy for ArrayList will be AOPProxy$1, and deploymentB's proxy for ArrayList will be AOPProxy$2 (both in the default package) "adrian(a)jboss.org" wrote : | | If the proxy uses a deployment class then obviously it should be generated | against that deployments classloader. Other deployments then become dependent | upon that deployment and must be redeployed. | | I don't see why the class can't use the deployment class's package in that case? | It uses the proxied class's package if the classname does not start with "java" or "sun". For example: -a proxy for java.util.ArrayList is AOPProxy$1 (currently in default package) -a proxy for org.jboss.some.Thing is org.jboss.some.AOPProxy$2 "adrian(a)jboss.org" wrote : | But that doesn't sound like your original requirement which was to do "instrumenting | JDK classes" by creating classes in the base package. Only JDK classes should not be in the package of the proxied class, and we need to find another home for these. Deployment classes are causing no problem. In short, we always use the classloader of the deployment rather than the classloader of the class we are proxying. This happens whether it is a system class (ArrayList) or something else. There might be interface introductions etc. that need to be able to see classes from the deployment classloader, so that is the easiest way. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206617#4206617 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206617

15 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Strange classloading behavior -- thread stuck

by bstansberry＠jboss.com

Just an FYI: Bela's likely out for the rest of the day. I'm trying to reproduce w/ TRACE logging now, but so far w/o success. If I can figure out the secret recipe to reproduce, I'll switch the jboss-classloader.jar and see what happens. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206616#4206616 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206616

15 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Strange classloading behavior -- thread stuck

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : "adrian(a)jboss.org" wrote : | | The code is the same as JBoss4.x | | There is one difference between 4.x and 5.x, which is the 4.x code won't loop forever | since it uses a for loop | | | JBoss 4.x | | | | int size = taskList != null ? taskList.size() : 0; | | synchronized( taskList ) | | { | | for(int i = 0; i < size; i ++) | | | | JBoss5.x | | | | synchronized (taskList) | | { | | while (taskList.isEmpty() == false) | | { | | | | But using a for loop would just hide the problem. | | The thread on Trace2 still wouldn't be woken up because the other thread wouldn't | do the notification on its task list (it would still assign the task to the wrong thread). One horrible thought is that JBoss4.x has the same problem but we haven't seen it as clearly before because of the for loop. ;-( View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206605#4206605 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206605

15 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Strange classloading behavior -- thread stuck

by alesj

"adrian(a)jboss.org" wrote : | Has 2.0.2.GA been released? | I see it in repository.jboss.com but JIRA says it is not. | Maven thinks we are on 2.0.3-SNAPSHOT | I've raised https://jira.jboss.org/jira/browse/JBCL-81 as fix for 2.0.3.GA Yes, it's been released, just not properly JIRA-ized due to 5.0.1 catch-up. I'll do it properly once I'm done testing the 5_0, 5_x branches with my latest MC snapshots. If you get the fix in till tomorrow 23:59 CET, I'll do a full MC release on Thursday, including CL and this fix. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206600#4206600 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206600

15 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Strange classloading behavior -- thread stuck

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : But where I do see a problem is in ClassLoadingTask.getThreadTaskCount(). | Bela I've uploaded a 2.0.3-SNAPSHOT with this fixed if you want to try it. You need to replace the jboss-classloader.jar in /lib http://snapshots.jboss.org/maven2/org/jboss/cl/jboss-classloader/2.0.3-SN... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206597#4206597 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206597

15 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Strange classloading behavior -- thread stuck

by adrian＠jboss.org

"alesj" wrote : Thread news jump-in ... | | Whatever you two come up with | make it fast if you wanna see this in 5.0.1. :-) | | As I'll probably do full MC release tomorrow, | now that VFS is in semi decent shape. ;-) Has 2.0.2.GA been released? I see it in repository.jboss.com but JIRA says it is not. Maven thinks we are on 2.0.3-SNAPSHOT I've raised https://jira.jboss.org/jira/browse/JBCL-81 as fix for 2.0.3.GA View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206593#4206593 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206593

15 years, 3 months

1
0
0 / 0

[Design of POJO Server] - Re: Strange classloading behavior -- thread stuck

by adrian＠jboss.org

"bela(a)jboss.com" wrote : Howdy, folks, I concur with Brian's assertion that the offending code seems to be looping. I'll enable TRACE for the org.jboss.classloader package, hopefully today, and post the findings. I'll past 4 (partial) stack traces of the offending Incoming-2 thread, each taken a few seconds apart, below. You can see that the code seems to loop indeed: | Thanks Bela. These stacktraces show the same thing, i.e. double locking on the task list which indicates a thread trying to reschedule tasks to itself. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206587#4206587 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206587

15 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2009