JBossDeveloper

Stop changing the topic, Francisco. We were talking about incremental deployment at the class level. You're the only one who wants to talk about hot deployment at the library level. That is not enough to get the scripting language style of development, and would not solve Arbi's problem.

It sounds to me like you're trying anything to not admit you were wrong.

What about a simple .jar?

In answer to your question, a plain jar is not a module in the Java EE module architecture. It is considered a shared library. Hot deployment in Java EE is going to work at the module level.

I some of my applications I have all my JPA entities inside a .jar that is then copied in to WEB-INF\lib, would you be so kind as to explain me how reload only that .jar? It can not be done?

Without restarting the war? AFAIK, this is not possible with OSGi either. That's a JVM limitation, right? You can't change the schema of a class definition without throwing away all the classes that depend upon it. Classloaders don't help you there. Not unless you have some kind of proxy in the client like you have with an EJB.

Mmmm, maybe with OSGi...?

Not as far as I know. Am I wrong?

Francisco Peredo wrote on Nov 17, 2009 19:15:

Gavin King wrote on Nov 17, 2009 19:06:


Oh, and Francisco, the JBoss 5 microcontainer can do everything that OSGi does and much, much, much more. You miss out on quite a lot because of your choice to use Tomcat.

Really? Does it have a solution for Classpath hell? That is the only feature that could make me leave tomcat, and so far, I have only seen it in Geronimo...

You're still changeing the subject to talk about what you want to talk about, not what the rest of us were actually talking about. Since neither I nor anyone else here has any idea what you would consider a solution to Classpath hell, I can't answer your question. However, if the solution can in principle be implemented using OSGi, then it can in principle be implemented using the microcontainer.

If there's a solution you like that you've only seen in Geronimo, it sounds like the solution is not really in OSGi itself, but is actually a feature of Geronimo AS.

Ok i agree that you are right Osgi does not offer individual class reloading but afaik it does allow to reload .jars and that is a feature that would make the development experience more confortable.

I agree that classpathhell was not on topic but please do not argue that you do not know what it is, specially when the word in the post is a link that explains it

Francisco Peredo wrote on Nov 17, 2009 20:18:


Ok i agree that you are right Osgi does not offer individual class reloading but afaik it does allow to reload .jars and that is a feature that would make the development experience more confortable.

Again, I don't think this is true, at least not in the way you seem to think. As far as I know, there is still no way, at the JVM level, to change the schema of a class that other classes depend on.

So, if module A depends on module B, and you want to change the definition of the classes in B, then you have to also reload A.

Now, it's possible I'm wrong on this, and there is now some solution to the problem that I have not heard about. I'm not an expert in this area. But unless you can find me a link to something describing that this is now possible, I'm going to go on believing that it's still not possible, and I think you should stop making assumptions about what kinds of problems OSGi is able to solve. It is already an overhyped technology.

I agree that classpathhell was not on topic but please do not argue that you do not know what it is, specially when the word in the post is a link that explains it

I did not say I do not know what it is, I said I don't know what you consider an acceptable solution to it. Different people have different opinions on this topic.

Gavin King wrote on Nov 17, 2009 20:25:

Francisco Peredo wrote on Nov 17, 2009 20:18:


Ok i agree that you are right Osgi does not offer individual class reloading but afaik it does allow to reload .jars and that is a feature that would make the development experience more confortable.

Again, I don't think this is true, at least not in the way you seem to think.

Maybe I am wrong about Osgi but..

As far as I know, there is still no way, at the JVM level, to change the schema of a class that other classes depend on.

Well, the JRebel guys do it, so is a fact that it can be done (or at least it is a fact that something with the same net effect can be done). Of course, I might be wrong and OSGi may to be able to do it.

So, if module A depends on module B, and you want to change the definition of the classes in B, then you have to also reload A.

Now, it's possible I'm wrong on this, and there is now some solution to the problem that I have not heard about. I'm not an expert in this area. But unless you can find me a link to something describing that this is now possible, I'm going to go on believing that it's still not possible.

JRebel existence is a proof that it can be done.. I am surprised you have never heard of them.

, and I think you should stop making assumptions about what kinds of problems OSGi is able to solve. It is already an overhyped technology.

Ok. I'll shut-up unless I find irrefutable proof. and btw I apologize for misreading and believing you were saying that you did not know what classpathell was.

JRebel fakes it.

The JVM provides the ability to change the body of methods using the java instrumentation API, but that is all, you cannot add or remove methods/fields etc.

The way to fake it to add new methods to a class is to register a ClassFileTransformer that does a couple of things:

- Replace all calls to the reflection API with calls to a new, hot redeploy aware reflection API.

- Add a generic method that can take any number of any type of arguments, any new methods are going to have their code jiggled sligtly and placed into a big if statement in this new method.

Existing classes can only reference this new method via reflection, which will get taken care of by the new reflection API, new classes get transformed as the are loaded to reference our generic method instead of the actual new one.

In reality it is 100x more complicated than this (e.g. you have in implement some kind of manual vlookup because the jvm no longer takes care of it for you), but I think this is a workable way of doing it.

I read the JVM spec cover to cover trying to figure out a way of doing this and I think this is the only way that is possible at the moment. I have been meaning to work on a proof of concept of this, but havent had time lately.

Well, the JRebel guys do it, so is a fact that it can be done (or at least it is a fact that something with the same net effect can be done). Of course, I might be wrong and OSGi may to be able to do it.

The JRebel guys say that OSGi requires that dependent modules be updated, which confirms my understanding. Let it go.

JRebel existence is a proof that it can be done.. I am surprised you have never heard of them.

I've heard of them. Some folks at JBoss looked at their technology closely at some stage (as a possible acquisition) and decided it was a complete hack that only partially solved the problems. I personally have not paid much attention.

The problem is bigger than class reloading. You also have to arrange for frameworks to be able to rebuild their metamodels, which the JRebel have had to try and solve in a very patchwork way.

Question: have you ever actually used JRebel, Francisco. Do you actually know it truly works in practice with stuff like EJB and JPA?

Thanks, Stuart, appreciated, I think I understand the implementation you've outlined.

Gavin King wrote on Nov 17, 2009 22:36:


Well, the JRebel guys do it, so is a fact that it can be done (or at least it is a fact that something with the same net effect can be done). Of course, I might be wrong and OSGi may to be able to do it.

The JRebel guys say that OSGi requires that dependent modules be updated, which confirms my understanding. Let it go.

Ok, I was wrong, but happy I learned something today ;-). Sorry if I made you angry in the process...

JRebel existence is a proof that it can be done.. I am surprised you have never heard of them.

I've heard of them. Some folks at JBoss looked at their technology closely at some stage (as a possible acquisition) and decided it was a complete hack that only partially solved the problems. I personally have not paid much attention.

The problem is bigger than class reloading. You also have to arrange for frameworks to be able to rebuild their metamodels, which the JRebel have had to try and solve in a very patchwork way.

That is, IMO, precisely because it is not a JSR, if it became a JSR then it would become a standard, and all that patchwork would become code to oficially support JSR XXX in framework ZZZZ. That is why I dream of the day when Oracle buys it. :-P

Question: have you ever actually used JRebel, Francisco. Do you actually know it truly works in practice with stuff like EJB and JPA?

Question: have you been reading this forums, Gavin? ;-) Because Arbi posted recently, in this very forum thread saying EJB interface changes will be hot deployable with upcoming version of JRebel, so it is obviously not supported right now, but they say it will be.

Sorry if I made you angry in the process...

I'm not angry, just a bit sick of the OSGi hype. These problems are really quite difficult to solve completely, and even though we (JBoss) could be doing a better job in this area than we are today, we're not really doing any worse than anyone else. (JRebel excepted, perhaps.)

You can view it here. It makes for quite heavy reading however.

Any kind of hot deployment solution needs the support of the framework vendor to work effectively, if jboss EJB3 do not provide an interface to allow a ejbs proxy to be regenerated, then it is almost impossible to support hot redeployment (barring fragile reflection based hacks into the code).

Well, it would be nice to have as a language feature (gotta love VBA where you can modify the code and drag the execution pointer back a few rows, now that is hot-deployment ;-)) but for now it would be nice to have as a feature

Hot deployment in appservers is the holy grail of coder productivity. The problem is hard to solve but the AS that can pull it off will have herds of devs flocking at their gates, babies named after them etc.