-
1. Re: For those interested in hot deployment
alin.heyoulin.qq.com Feb 25, 2010 6:02 AM (in response to swd847)Excellent work!
-
2. Re: For those interested in hot deployment
luxspes Feb 25, 2010 7:14 PM (in response to swd847)Interesting, I have added some comments to your project page
-
3. Re: For those interested in hot deployment
asookazian Feb 27, 2010 6:31 AM (in response to swd847)I'm still wondering what your solution has over the JRebel 3 solution which currently supports Seam/EJB3 projects in 3.0-M2. They use javaagent as well.
Perhaps yours is open-source and zeroturnaround's is not, but they do have open-source APIs to develop plugins.
Do you have any marker configuration like the rebel.xml which tells the processor which directories to scan for reloads?
-
4. Re: For those interested in hot deployment
nickarls Feb 27, 2010 11:58 AM (in response to swd847)He just started on it, I'm sure it doesn't have that much
over JRebel 3
. Either he will produce something useful which can be shared with others or if not, learn a lot from the try. The hot replacement scene is not that crowded... -
5. Re: For those interested in hot deployment
swd847 Feb 27, 2010 1:15 PM (in response to swd847)
Arbi Sookazian wrote on Feb 27, 2010 06:31:
I'm still wondering what your solution has over the JRebel 3 solution which currently supports Seam/EJB3 projects in 3.0-M2. They use javaagent as well.
Perhaps yours is open-source and zeroturnaround's is not, but they do have open-source APIs to develop plugins.
Do you have any marker configuration like the rebel.xml which tells the processor which directories to scan for reloads?I have never used JRebel, I can't really say one way or another.
The fact that it is open source matters a lot more that you might think, it will open up the possibility of out of the box integration for any open source appserver/framework/whatever, an open source API is not nearly the same thing. Also it means other people can look at it and get ideas and improve it further.
The marker configuration is largely irrelevant. The hard part is replacing the classes, scanning files and updating the ones that have been changed is pretty much a non issue, at the moment all I have is a seam filter that scans an exploded deployment on every request, I will do a more generic timer based one after I am happy with the core class replacement functionality.
-
6. Re: For those interested in hot deployment
asookazian Feb 28, 2010 1:16 AM (in response to swd847)You both have valid points. In any event, good luck with fakereplace but be sure to read the JRebel docs, it would be in your best interest...
-
7. Re: For those interested in hot deployment
asookazian Mar 1, 2010 6:17 AM (in response to swd847)And I thought I read somewhere about the modular design of JDK 7 that would solve this hot class reloading problem...
Class path is deadReinhold said. --http://www.infoworld.com/d/developer-world/java-get-more-modular-jdk-7-upgrade-919
apparently Sun/Oracle has a patent on the dynamic class reloading: http://www.patentstorm.us/patents/6915511/description.html
has anyone seen this before?
-
8. Re: For those interested in hot deployment
swd847 Mar 1, 2010 6:57 AM (in response to swd847)The patent is for a different method (discarding classloaders).
That article did not seem to have anything to do with hot redeployment, although the new invokedynamic instruction could simplify the implementation of fakereplace somewhat.
Incidentally I think the name is terrible, but I couldn't think of a better one. I wanted to call it cheetah or jcheetah but they are already taken.
-
9. Re: For those interested in hot deployment
nickarls Mar 1, 2010 7:50 AM (in response to swd847)jPlacebo? jBaitNSwitch? ;-)
-
10. Re: For those interested in hot deployment
asookazian Mar 1, 2010 5:16 PM (in response to swd847)I would replace 'fakereplace' with something like 'JReplace' or 'JReload' or 'QuickSync' or 'ReClassify', etc...
-
11. Re: For those interested in hot deployment
luxspes Mar 2, 2010 6:14 PM (in response to swd847)Maybe the project name should be DynamicInvocationHandler? The idea of the
catch all
__REDEFINED_STATIC_METHOD_(int methodNo, Object[] parameters) method seems very similar to java.lang.reflect.InvocationHandler.invoke method -
12. Re: For those interested in hot deployment
luxspes Mar 2, 2010 6:19 PM (in response to swd847)Mmmm, I wonder if the code Groovy.invokeMethod could be somehow reused/repurposed/used-as-guidance to implement the
I control all method calls in a single place
behavior needed by the fakereplace -
13. Re: For those interested in hot deployment
swd847 Mar 3, 2010 12:37 AM (in response to swd847)One of the main design goals is to be as unobtrusive as possible, and to use a dynamic language approach would be to invasive, and carry a large performance penalty. The idea is that if you do not replace any classes the only difference between what you wrote and what is being run is that reflection calls are handled by a different class (this alone is problematic enough due to permission issues).
Even simply adding a method can have an impact on running code, as it can change an objects automatically generated serialVersionUid and break serialization.
There are other approaches to adding methods that the one I have taken. It is possible to take an instance method and change it to a static method on a new class, however you then run into permission problems accessing private members on the original class. These can be fixed by modifying everything as it is loaded into the JVM to remove the private marker, however then you have to emulate it again in the instrumented reflection API.
The actual recompiling of the bytecode is the easy bit, the hard part is making sure that what you end up with exactly matches the behavior of a system running without fakereplace.
Stuart
-
14. Re: For those interested in hot deployment
asookazian Mar 3, 2010 5:06 PM (in response to swd847)new article on 5 JRebel features you couldn't do in the JVM: http://www.theserverside.com/news/thread.tss?thread_id=59573