-
1. Re: JBossIDE / JEE5 features for MC
adrian.brock Feb 13, 2006 1:06 PM (in response to mculpepper)I'd like a sort of javabean editor that lets you "visually" maintain the -beans.xml.
I remember a long time ago there was a javabean editor that let you drag and drop
one bean onto another and it would automagically know which property to set based
on type. It was done by some academic, I haven't been able to find it since.
Basically for integration with AOP, we want the "Minority Report" user interface.
On one side you have bean classes on the other the aspects.
You take a bean class put it in the middle to "instantiate it". You connect it to
other bean instances and drop "aspects" onto the beans.
Voila, running "micro-server".
Of course changing things like port numbers or typing database urls/passwords
is more fiddly...
It doesn't matter if it is just a toy.
It will be good in demos ;-)
and more importantly, teaching people the concepts in trainings. -
2. Re: JBossIDE / JEE5 features for MC
mculpepper Feb 13, 2006 1:33 PM (in response to mculpepper)Spiffy.. this is a good starting point.
Do you guys already have a DTD/Schema for the -beans.xml file? That would certainly aid in the development of a visual / completing editor.
Your "minority report" idea is pretty interesting.. I can get a really good idea for where this could go from a demo stand point -- but would this tooling be very useful outside of simple prototyping? I.e.. would it be practical as a visual interface to the "xx-beans.xml" editor? -
3. Re: JBossIDE / JEE5 features for MC
adrian.brock Feb 13, 2006 1:50 PM (in response to mculpepper)The schema is here:
http://anoncvs.forge.jboss.com/viewrep/JBoss/microkernel/src/resources/schema/bean-deployer_2_0.xsd
NOTE: It is only "indicative" of what is possible. The schema is fairly loose with most
things optional and different options actually validated that they make sense during the
parsing. e.g. a constructor with a factoryMethod needs a factoryClass or a
factory element.
The "minority report" idea is something we discussed a long time ago
as a more visual mechanism to manage service orientated and aspectized systems.
It is what user interfaces designers call a "metaphor".
In this case the metaphor is applying an aspect or "annotation".
i.e. I take a Customer object in one hand and a security aspect in the other.
I bring them together and now I have a SecureCustomer.
In practice, the UI has then got to ask "Who is authorised", etc.
But these details just spoil the fun! -
4. Re: JBossIDE / JEE5 features for MC
adrian.brock Feb 13, 2006 1:52 PM (in response to mculpepper)"adrian@jboss.org" wrote:
The schema is here:
http://anoncvs.forge.jboss.com/viewrep/JBoss/microkernel/src/resources/schema/bean-deployer_2_0.xsd
NOTE: It is only "indicative" of what is possible. The schema is fairly loose with most
things optional and different options actually validated that they make sense during the
parsing. e.g. a constructor with a factoryMethod needs a factoryClass or a
factory element.
In practice there are only a few of these cross validations. Most things make sense
or it least the MC tries to make sense of it. :-) -
5. Re: JBossIDE / JEE5 features for MC
adrian.brock Feb 13, 2006 1:57 PM (in response to mculpepper)"adrian@jboss.org" wrote:
i.e. I take a Customer object in one hand and a security aspect in the other.
I bring them together and now I have a SecureCustomer.
In xml (not the real annotation)<bean class="org.jboss.example.Customer"> <annotation name="org.jboss.security.SecurityDomain"> <attribute>LDAP-Realm</attribute> <!-- DETAILS! :-) --> </annotation> </bean>
-
6. Re: JBossIDE / JEE5 features for MC
mculpepper Feb 13, 2006 2:15 PM (in response to mculpepper)These "implied" validations on the XML file are fine.. We do a lot of these kinds of validations currently in our custom editors for Hibernate configurations/mappings, JBossAOP descriptors, etc.. The schema is just a good starting point.
The next logical question would be -- Is the MC metamodel appropriate for re-use in the IDE? The JBossAOP object model required users classes to be instantiated in Eclipse's classloader, and you can imagine the big hairy mess that introduces for an IDE . We ended up trashing the AOP Report mechanism and re-implemented their JJTree pointcut parser to use Eclipse's JDT source model as it's point of reference, instead of reflection. Note that it is still possible to obtain a sandboxed execution context for the MC in Eclipse, but I'd like it to be isolated from development features if at all possible. -
7. Re: JBossIDE / JEE5 features for MC
adrian.brock Feb 13, 2006 2:23 PM (in response to mculpepper)The org.jboss.beans.metadata model is just that.
It doesn't attempt to do anything with it until you pass it to the controller.
It also supports a visitor pattern, so you can visit the nodes of the model to discover
things like dependencies it will require for each bean.
See the testsuite for more information.
EVERY test is done twice
1) Programmatically using the BeanMetaData api
2) Using the xml equivalent. -
8. Re: JBossIDE / JEE5 features for MC
adrian.brock Feb 13, 2006 2:29 PM (in response to mculpepper)A warning though.
The xml supports wildcards. That is objects instantiated by the xml parsing.
e.g.<bean> <property name="SomeProperty> <javabean xmlns="other:namespace" class="com.acme.POJO"/> etc.
The javabean in the other schema will be unmarshalled into its own object
using its own schema binding rules.
It is then added to the MC's AbstractValueMetaData as a java.lang.Object
I wouldn't worry too much about this feature during the first iteration :-) -
9. Re: JBossIDE / JEE5 features for MC
mculpepper Feb 13, 2006 2:32 PM (in response to mculpepper)Ahh... sounds nice and flexible =)
Ok, so shifting back a little more on point. So far for the MC we have these items:
- Visual xxx-beans.xml editor w/ drag-and-drop bean associations and code completion
- Some sort of view that integrates with our AOP tools to create a prototype MC
I'd like to add a few suggestions. Eclipse's Classpath Container is a great way to pre-package libraries for your users so they don't have to go hunting around for 10 jar files to get their source working. Would you want to also have an Eclipse CP container for MC? Also, we should probably have a Launcher configuration for starting MC instances. Ideas? -
10. Re: JBossIDE / JEE5 features for MC
adrian.brock Feb 13, 2006 2:44 PM (in response to mculpepper)I plan on doing an MC eclipse plugin anyway - just don't have the cycles at the moment.
This would be especially useful when wiring tests together that needs mocks.
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=76657
I've also being "playing" with doing the same thing for other JBoss services
(including Tomcat).
i.e. Being able to bootstrap a mini-JBoss as a "Mock" environment.
This is a part of some prototype work I'm doing on "Embedded JBoss"
or more accurately "Embedded MC with optional JBoss Services".
Making it simple to use in an IDE for tests is only a part of it. -
11. Re: JBossIDE / JEE5 features for MC
mculpepper Feb 13, 2006 2:50 PM (in response to mculpepper)That's some really cool stuff I must admit .. wire up a mini container in a few clicks / through a script to test your ee apps. Lots of possibilities there for sure..
So we are putting a check on all 4 features then?
- beans.xml visual editor
- MC visual setup / integration w/ AOP (possibly backed by a ant-based wiring utility ala hibernate tools)
- MC classpath container
- MC launch configuration