Ben, This sounds like it has some potential. You might also want to think about ways this could aid in the creation of a JBossCashAOP applications / projects. A standard wizard we create for all of our major plugins is a "Project Wizard" which automatically places the necessary JARs etc in the users's project for compiling and using in their application. This removes the need for them to keep track of JARs manually in their classpath.
Other things you might want to think about:
- We have a very good AOP plugin that supports a pretty good subset of AOP's functionality in eclipse. We use visual cues all over the place to deliver useful information to AOP developers. You might want to expand / extend upon some of those visual cues for Cached POJO field or method interception, as an example.
- I'm not sure how effecient or doable it is, but it's also nice in alot of cases to offer code completion wherever possible. Something that comes to mind would be for instance when looking up a POJO from the TreeCache, possibly a popup that shows all the current POJOs in the cache. This might be tough since it's runtime information, but just an idea.
I'm sure there are more things specific to CacheAop that I haven't thought of as I only know the product on the surface =).
At any rate, moving forward with discussion about the new extension, if you do decide that you want this done, do you have any ideas for who will be implementing? ATM we have our hands pretty full with the 4 of us on the IDE team. We can certainly be there to help smooth the transition etc, and give out best practices for developing with eclipse. I recommend you take a look at our developer cookbook guide to get a good feel for eclipse. It has a lot of good step-by-step examples for extending eclipse. Here's the URL:
Make sure to download the "Example Projects" .. it's a zip with lots of helpful source (the cookbook uses it).
How should eclipse hook into the cache ? By running as a node or ?
Is that possibly to do more or less transparently ? Does it require the users classes loaded in the eclipse plugin ?
I would imagine that the plugin would face similar technical hurdles as the Hibernate Tools plugin (loading user classes to inspect their runtime data / make them changeable / etc).
I think his tree cache view will be similar (albeit more complex) to the entity properties view in Hibernate Tools
Thanks for the info. To further the discussion:
1. Yes, I envision the IDE gui will either be run as another cache instance (and thus running as replicated mode) or just subscribe to the remote cache events. Either way, the job of the gui is to display the visual information (like object graphs or updated *dirty* fields). We can also support additonal query (like the pojos, etc.) That is certainly doable.
2. We certainly want to leverage the JBossAop plugin. First of all, troubleshooting will be easier since often times, Aop is the most difficult part. Second, support of additional JbossCacheAop annotation (used for dynamic aop) will be needed as well.
3. I was hoping for some free resource from the IDE team to help out. But if we can't, maybe we should spec it out and then publish on the forum looking for volunteer then.
Couldn't we grab some ideas and maybe even code from the spider plugin of Beck and Gamma? This is kind of an object graph inspection tool for Eclipse. It inspects static object graphs, but I guess there are possible reuses there...
Do you further details for that plugin?
There is a screenshot of this spiderstuff at http://blogs.cocoondev.org/crafterm/archives/2004_08.html#002060, but the referenced website seems out of order.
I found an Eclipse update site containing the spider at http://javaspider.sourceforge.net/updatesite. I just checked it out and it still seems to work for Eclipse 3.x. But there is no sourcecode, so I guess the work has to be redone anyway... Nevertheless, I played with it while I was reading the Gamma/Beck book on Eclipse plug-ins and it was really cool.
I have finished the JBoss Cache IDE eclipse plug-in prototype working. Could we disscuss about the prototype and define requirements for implementing the next version?
My initial thoughts are:
The wizard are too complex - simplify.
Add field validation - currently next/finish buttons are messed up when you click on them without guessing what is needed ;)
Provide a way for users to give you their cache configuration instead of you dictating where it is placed.
btw. the source for javaspider is at http://cvs.sourceforge.net/viewcvs.py/javaspider/
but it probably needs some updating to integrate well with the improvements done in eclipse 3.1 debugging.
It still works though - but feels clunky.
The idea is good though.
-I looked and played with Spider plug-in you are considering. In our plug-in I have already shown the all contents of the cache to the user in the tree view.
-I have already discovered the primitive contents of the cache node in the node content view. The problem is how to show contents of the cache nodes containing real objects(or pojo objects in AOP). Last time we talked with the Ben, we can use toString() method that show all the primitive field of the object. (But this requires overriding toString() of the Object and may be user do not wants to this). Then, we can use the idea Spider plug-in did.
im not much for recommending the spider approach (i just commented on koen saying he couldn't find the source)
In the hibernate tools we just use hibernates meta model to get the list of properties name, type and value. I guess you can do the same just via reflection (i'll probably also add reflection based view for hibernate since we can also get objects that are not hibernate objects)
Maybe it can use the same code.
But it's pretty simple, just look in hibernate console plugin code for HibernatePropertySourceProvider, CollectionPropertySource and EntityPropertySource.
In POJO cache, the pojo instance class is first stored under the cache. We can read out that class name and then do reflection, and basically reverse engineering of what I do in the code to re-assemble the object.
I don't know what Spider approach can do. Maybe Gurkan when we chat next time, you can educate me. But it will be nice if we have a way to displaying the object graph and can drill down to it, etc.
I would like to create some requirements for the next version of the plug-in and to ask some questions...
1- I will do some improvements on the cache creation wizards. The verbose part of the wizard is JChannel configuration. I will remove this part. When the user presses finish button, I will show content of the xml file in the editor with default JChannel values. Then user can correct the values if he/she wants.
In the prototype, I saved this configuration file in the plug-in registry. I think this was good. I will show the file in the "Cache Configuration View" of the plug-in as the part of the cache instance. So when user wants to change configuration, he/she is able to open the file and does change on the file and save it.
I think this solves the wizard problems.
2- I will get necessary jars from the user from wizard. I think to show the content of the objects; that are the user defined objects not regular Java objects ; in the plug-in, users must provide these jars so that I can touch these objects at run-time. Otherwise I am getting java.lang.ClassNotFoundException. Because; when new object is created in another cache instance, the plug-in is registered as listener to nodeCreated events but it can not create objetcs because class of the object not found by using BundleClassLoader in Eclipse.
Max ; Could I put these jars into the bundle classpath at runtime?
3- In addition to the creating cache instance in the plug-in, I will provide new functionality that connects to the cache instance running in the JBoss server. So I will take jndi parameters from the user, and provide remote connection to the MBean registered in the server using jndi name;
4- In TreeCacheAOP I will try to provide object graph view of the cache, and users are able to play with on this graph.