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

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by flavia.rainone＠jboss.com

"alesj" wrote : We are already able to track when the ClassLoader goes away: | when the Module is discarded --> ClassLoading::removeModule. | | And this is what I already fixed, so that the RegisterModuleCallback is part of this ClassLoading::removeModule call. | It just looks like this doesn't do all the things we need to properly cleanup ClassPools. | I'm not properly cleaning up ClassPools: public synchronized void removeModule(Module module) | { | logger.debug("Removing module " + module); | registeredModules.remove(module); | unregisteredModules.remove(module); | } I need to invoke ClassPoolRepository.getInstance().unregisterClassLoader(ClassLoader). But how do I get the Module's classloader if Module.getClassLoader() is protected? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260761#4260761 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260761

16 years, 5 months

1
0
0 / 0

[JBoss Transactions Development] - Re: Starting with JBoss Transactions

by jhalliday

> Can somebody help me? If you can't figure out how to add jars to the wsgen classpath on your own, you are probably beyond help, or at least in need of a remedial introduction to java software development, since it uses the same fundamental -cp/-classpath mechanism as java and javac. You have done java programming before, right? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260751#4260751 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260751

16 years, 5 months

1
0
0 / 0

[JBoss Transactions Development] - Re: Starting with JBoss Transactions

by ryden13

anonymous wrote : | If you take a look inside the sar file (e.g. jar tvf jbossxts.sar) you will see that is built using a variety of jar and war files. The only one you need to develop an XTS application is the api jar which you will find in xts-install/lib/jbossxts-api.jar. This jar exposes all the publicly visible types your application (and eclipse) needs to know about (see the user guide for a full explanation of how to use the API types). Add this as an external API jar in your eclipse project so that eclipse can resolve references to the XTS API classes. Also ensure that it is in the classpath when you compile your application. That should be all you need. I can use jbossxts-api in my Eclipse projects without error, but when I go to build the web service with wsgen -cp . -d . -verbose -r ../../WebContent/WEB-INF/wsdl -wsdl ejemplo.EjemploServicio I have a problem because it cannot found any com/arjuna/wst classes Can somebody help me? Thanks ! View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260736#4260736 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260736

16 years, 5 months

1
0
0 / 0

[JBoss AS Development Deployment Framework] - Re: Redundant WAR deployer redundancy

by emuckenhuber

"alesj" wrote : "emuckenhuber" wrote : | | AFAIK there was a discussion last year to only keep the WarStructure in the AS codebase and have a mock implementation for the deployers tests only. Adrian then ported the WarStructure to AS. | What was the reason to do so? | | For me it makes more sense to keep the one in Deployers, | as then I don't have to fix/port any new features when I "mock" the .war deployment in Deployers. | And with .wars being mostly the only ones that have a bit diff CL policy, | we do/should use WarStructure a lot. | | Perhaps if the AS WarStructure would in the future use some of the ext metadata classes, | we should just make sure there are properly exposed hooks in Deployer's WarStructure, | and make AS's AdvancedWarStrucutre extends WarStrucutre. There was a bug in the WarStructure and it would have required a deployers release. I think that all War*Deployers should be in the same project, as they belong together - tests should go there as well. As long as it does not affect the core functionality of the deployers. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260734#4260734 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260734

16 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by alesj

"flavia.rainone(a)jboss.com" wrote : | On our side of the story, the ClassLoader is registered on an as-needed basis, by RepositoryClassPoolFactory.getPoolForLoader(ClassLoader). I dunno it would be a good idea to create a translator just for the sake of unregistering classloaders. What would be a better approach? Maybe a LifecycleCallback? Uf, translator idea is horrible. ;-) We are already able to track when the ClassLoader goes away: when the Module is discarded --> ClassLoading::removeModule. And this is what I already fixed, so that the RegisterModuleCallback is part of this ClassLoading::removeModule call. It just looks like this doesn't do all the things we need to properly cleanup ClassPools. Or perhaps we already cleanup - as that null would indicate, it's just that we don't properly re-set things; e.g. in 2nd call to the TypeInfo/ClassPool getClassLoader. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260720#4260720 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260720

16 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development] - Re: Testing Deployers with new Reflect + ClassPool

by flavia.rainone＠jboss.com

It will always be a mistery why the tests passed before (but I swear they did ;) Yes, the classpools are never cleaned up, and this is generating the failures. This is a basic thing that I completely missed when doing the ClassPools. When I tested those against Branch5_x and JBoss AOP, they worked, but the point is that JBoss AOP has the mechanisms to clean the ClassPools. So, this is how JBoss AOP regiesters and unregisters ClassLoaders: 1. The AspectDeployer registers the ClassLoader when an aspect is deployed. 2. The AspectManager translator is is attached to the ClassLoaderSystem, which invokes the unregisterClassLoader everytime a unit is undeployed. On our side of the story, the ClassLoader is registered on an as-needed basis, by RepositoryClassPoolFactory.getPoolForLoader(ClassLoader). I dunno it would be a good idea to create a translator just for the sake of unregistering classloaders. What would be a better approach? Maybe a LifecycleCallback? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260714#4260714 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260714

16 years, 5 months

1
0
0 / 0

[JBoss AS Development Deployment Framework] - Re: Redundant WAR deployer redundancy

by alesj

"emuckenhuber" wrote : | AFAIK there was a discussion last year to only keep the WarStructure in the AS codebase and have a mock implementation for the deployers tests only. Adrian then ported the WarStructure to AS. What was the reason to do so? For me it makes more sense to keep the one in Deployers, as then I don't have to fix/port any new features when I "mock" the .war deployment in Deployers. And with .wars being mostly the only ones that have a bit diff CL policy, we do/should use WarStructure a lot. Perhaps if the AS WarStructure would in the future use some of the ext metadata classes, we should just make sure there are properly exposed hooks in Deployer's WarStructure, and make AS's AdvancedWarStrucutre extends WarStrucutre. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260694#4260694 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260694

16 years, 5 months

1
0
0 / 0

[JBoss AS Development Deployment Framework] - Re: Redundant WAR deployer redundancy

by emuckenhuber

"alesj" wrote : | I guess when I was porting WarStructure from AS to Deployers | I left it in AS for back compatibility. | This should be removed for AS trunk --> only keeping the one in Deployers. AFAIK there was a discussion last year to only keep the WarStructure in the AS codebase and have a mock implementation for the deployers tests only. Adrian then ported the WarStructure to AS. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260688#4260688 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260688

16 years, 5 months

1
0
0 / 0

[JBoss Microcontainer Development POJO Server] - Re: Adding a ClassLoader import exclusion filter

by alesj

You can already do all of these things, most of if just requires proper ClassLoadingMetaData / jboss-classloading.xml configuration. Or you have to override some of the Module, ParentPolicy and ClassLoaderPolicy behavior, providing your own impl via new CL deployer. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260685#4260685 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260685

16 years, 5 months

1
0
0 / 0

[JBoss AS Development Deployment Framework] - Re: Redundant WAR deployer redundancy

by alesj

"david.lloyd(a)jboss.com" wrote : | Where should these classes exist? At the least, WARStructure should be moved to one place or the other. It depends on their dependencies. e.g. EARStructure depends on JBossAppMetaData, which is definitely something I don't wanna pull in for Deployers (--> keeping the project generic) Whereas WarStructure, doesn't have any ext dependency, hence should/could only live in Deployers. I guess when I was porting WarStructure from AS to Deployers I left it in AS for back compatibility. This should be removed for AS trunk --> only keeping the one in Deployers. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4260682#4260682 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4260682

16 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2009