Richard Kennard asks:
I'm interested in the hot deployment conversation that was raised during the JBoss Community Asylum podcast recorded at JUDCon. In particular, the conversation about how different frameworks will need to be able to support hot deployment.
At the moment Metawidget uses a very simple cache of...
Map<Class<?>, Map<String, Property>>
...to cache metadata against Classes. Hopefully this would 'just work' if the reloaded Class<?> doesn't .equal the old one? Class.equals uses == internally, so will that work with what you're planning?
To which I replied:
MetaWidget is a great candidate as a framework that fakereplace could support for hot deployment. Particularly because the UI is the one area that people expect the most complete hot deployment.
The class is still equal to the old version, however a cache like that is trivial to clear if I wrote an integration module for it.
I then gave an attempt to point Richard in the right direction:
I'll attempt to point Richard at the integration module API and example impls. I'm sure he would be happy to make a patch attempt
JSF 2 integration:
Seam 2 integration:
The only question I have is how does a framework know when it's time to drop its cache? Meaning, what's the best trigger point? (Obviously some frameworks are more complex than others, so consider the simpler cases of single caches).
Fleshing out this integration on the forums would be a great way to encourage other framework developers to latch onto the project and contribute integrations
Looking at the links Dan sent, it appears FakeReplace does its magic via a FakeReplace plugin, so I would just need to expose some kind of Metawidget API for clearing my cache that you can call?
It looks, Dan, like it's FakeReplace's job to know when to drop the cache, not the framework's?
The fakereplace integrations are built as separate modules then merged into a uber jar. There are plans to add the ability to have frameworks integrate without a dependency on fakereplace, however it is not a priority at the moment.
Richard, if you send me the details of the MetaWidget classes that need to have their cache cleared I should be able to create an integration module quite quickly.
I think this would be an excellent candidate for a Fakereplace screencast, showing off adding a field to a class and having the field show up in the UI automatically would be pretty cool.
I would love to see that!
The main candidates would be classes extending BasePropertyStyle and classes extending BaseActionStyle. Internally they have a mPropertiesCache and an mActionCache respectively. There are a couple stumbling blocks:
- The caches are private
- The caches do not live in a static world. Rather, Metawidget keeps a single immutable instance of most things, so there is a single immutable instance of BasePropertyStyle and therefore a single cache. But I imagine you will need some way to track down the instance?
I would be happy to help with both of these!
- The caches are private
Metawidget support is now in svn, should be released this week. I tested it out on the booking example and when I added a field to Hotel it showed up in the UI automatically.
I have also removed the need for setting -Dorg.fakereplace.packages, so all exploded deployments should be replacable automatically.
I will try and do a screencast after the next release, probably some time this week.
In case anyone is interested the integration code is at:
There is not very much to it, all it does is clear the meta widget caches.
This is fantastic. It's fantastic because of the simplicity and quick turn around. Granted, the complexity of this framework integration is likely much less than something like Weld, but it's a proof of what's possible.
Great job, both of you. Richard, I think this would certainly be a value add to the MetaWidget screencast as well.
I've just put out Metawidget v0.99, which includes public clearCache methods on both BaseActionStyle and BasePropertyStyle. So if you get chance you may want to update your Metawidget plugin to use them rather than reflecting against the private member variables.
Also, with respect to that screencast: are you still intending to put something together?
I am still intending to do the screencast, but I have not worked on fakereplace for the last few weeks because all my spare programming time (which is not that much at the moment) has been going to seam.
I am not going to get time to do this for the next few weeks, but if you want to do it instead feel free. If you do you should use the lastest svn version of fakereplace, and please report any bugs you find.
I'm also probably going to move fakereplace to githib when I start working on it again, so the home page may move.