I need to do the dynamic loading of features for my JBoss web-app without recompiling or redeploying application. The features is a classes with executeLogic() methods which extends Basic Classes of my web-app. The idea is to allow other developer to add features to my server using small features.jar lib for that(which contains basic classes). The features.lib is in WEB-INF\lib of web-app. What I've done is create 'features' dir in jboss deploy dir and put all these feature classes there. When request arrives I look up at this dir, get jar-files URLS and put them in URLClassLoader. The problem is that the feature classes is loaded with my classloader (which extends URLClassLoader) and basic classes (super classes for feature classes) loaded with org.jboss.mx.loading.UnifiedClassLoader3. That is why I can not cast FeatureClass to BasicFeatureClass. What can I do?
Instead of puttin it in the WEB-INF/lib directory which I believe is why it is in a JBoss ClassLoader, and put it directly off the root dir of the war file in say some dir called featurejar. Then set your File object to that dir and load from there. So you load your feature app classes and then it can also search your "features" dir in JBoss and both sets of jars are within the same ClassLoader hierarchy.
ok, when the request comes I use custom loader to load specific request class. If that class needs another libs they are loaded with JBoss's loader. If I place them in other place JBoss will not find them. How will I know that the class that I loaded needs another class? How can I load that another class with the same custom loader?
OK, I am confused, I jsut stated that by putting your jar in the WEB-INF dir, you are saying to JBoss, hey I want you to load up these classes in the ajr for me. If you do not want that, then do not put it into the WEB-INF dir of the war file, you need to put it somewhere JBoss will not load those classes for you so you can create your own Custom ClassLoader.
Yes is not a problem. We can put libs in some other dir so JBoss will not find them and we can use custom loader. The system works with the following way - when request comes to the server I can read request type from that. Then I analyze jar file manifest in some defined dir and get information about what class implements request processing algorithm for that type of request. Then I can just load this class with class.forName() of URLClassLoader. But what if that request processing class which was loaded by (myClassLoader extends URLClassLoader)needs another jars? How can I know that? How can I know what classes to load from that jars?
I still don't understand what you mean. I have some jars in my war, I load them with a ClassLoader, a request comes in with some information which determines which class that you loaded in the ClassLoader to use for a method call. Now how can any request coming in request that you need other jars that weren't even in the original war. It doesn't make sense, there has to be some architecture inaccuracy somewhere.
[CODE] war /myApp /ToBeLoadedInMyClassLoader /somejar /anotherjar [CODE]
so now you are saying a request can come in and it needs say somejarnoideawhereitcomesfrom.jar file. The request can't include that new jar, so where it is even coming from in the first place. If you think that they can add another jar in some other location, then you probably won't be able to do that, just because I see so many security risks that it just isn't smart to do.