Marc Fleury wrote:
On a separate note. I have been thinking for the past week about this stuff and microcontainer stuff in general. I think it is basically a clean up of EJB stuff. Been thinking about entities and a way to cleanly wrap up hibernate stuff. Finders are important. I have a hard time finding any justification for session beans except remote, cluster/failover, transactions. These are already in AOP so I may just rebuild them but frankly they become a bit useless in memory. Also Bill we may need to revisit the proxy stuff, you may have been right. If the main point is failover, it requires a proxy and then we are back to your original designs. Bottom line we may need proxy/instance AOP for the different use cases.
We do need to play with and implement some applications with the AOP approach.
Some other thoughts:
1) I should eventually merge AOP metadata with XMBean metadata based on Alex's new stuff.
2) Need to figure out the integration with AOP and XMBean. AOP in the AspectJ sense is always based on the Class level where MBeans are more towards a per instance type of thing. XMBean defined interceptors should support pointcut expressions that the AOP framework has and the two should migrate into the same look and feel.
3) I do have the concept of an Abstract Container within the AOP framework, but I have not made it public yet. The idea was to be able to specify pointcuts on an Abstract Container in the same way you could define pointcuts on a class. An Abstract Container could support a specific Class or a set of interfaces. Container's are always needed as they allow references to objects to live beyond the lifetime of the actual object. Also thought of the Abstract Container as a way to group attachment of interceptors rather than the all or nothing approach AspectJ has on a class.
4) The Microkernel needs to be more IoC enabled. I touched on some of these points in the RoadMap, but I'll repost here:
==================
1. The ability to define POJOs as MBeans with no requirements other than a public constructor. Even looser than the *Mbean template for StandardMbeans. This facilitates having MBeans taken from existing static object models. I know we have XMBeans to facilitate a lot of this funtionality, but we need to NOT require metadata and have defaults defined.
2. Need to define semantics for dependencies for non-Service mbeans. If a depends tag or depends optional-attribute mbean has not been started/created/loaded, what do we do? Suggestions include, don’t even register/allocate object until dependencies are resolved (both create/start for service mbeans).
3. Move Service state out of ServiceMBeanSupport so that we do not have to inherit from org.jboss.system.ServiceMBeanSupport to manage current state of MBean. This is so that we can just have MBeans that only have to implement orb.jboss.system.Service to get lifecycle events. This is useful because some Objects may want to have their own inheritance structure.
4. Document how to create a Service AOP Introduction so that non-changeable classes that we want to create as components can have lifecycle.
5. Add Service “controller” attribute to MBean definition. This will allocate a separate defined class that will handle lifecycle events on the MBean. This allows you to define Service lifecycle as a cross-cutting concern without using AOP.
6. For depends optional-attribute add a proxy-type for AOP ClassProxies.
7. For depends optional-attribute have a well defined default for proxy-type: i.e. The MBean interface of the MBean. If no Standard MBean interface, then all interfaces, or even optionally create a AOP ClassProxy.
8. For depends optional-attribute have an instance instead of proxy-type. MBeanServer will place the actual reference to the real object instead of a proxy. On an MBean cycling, replace all references with the old object with the real object.
9. Let Constructors accept <depends optiona-attribute> arguments. Either ObjectName, ArrayList of ObjectNames (for lists), or an actual proxy or list of proxies
Bill
-----Original Message-----
From: Andrew Oliver [mailto:[EMAIL PROTECTED] Sent: Sunday, February 01, 2004 6:01 PM
To: The Core
Subject: EJB Spec
So RMH has posted asking for "What do you hate about EJB" -- We should respond. We should spell it out and basically spell out JBoss AOP + Hibernate without saying so then note as a matter of fact at the end "we'll do this regardless while assuring compatibility with your legacy spec"
Lets decide:
What do you hate about EJB?
ME:
Needless contract methods. I especially hate the various lifecycle methods that are NEVER used but are there to satisfy interfaces... Even worse the ones that are Container->EJB interfaces.
ME:
CMR must be local interfaces. Since most appservers make the locality unimportant, why do I HAVE to use local interfaces if I don't feel like it.
ME:
Home stateless methods on Entities
ME:
Any method prefixed with ejbBLA that has a peer in the interface.
ME:
Can't set CMR in ejbCreate
ME:
Ejb create methods required. Why can't the persistence engine figure out that if I call home.create(X,Y,Z) to set X, Y and Z through meta data or something. Why do I need to put that stupid method declaration in?
ME:
EJB descriptors have unnecessary complexity. IF XDoclet can figure it out, then that should be the default of the descriptor anyhow.
That's just to get you started. Give me hand. What else sucks about EJB?
I'll also post on the dev list asking for some feedback. That should get the lists moving again. While negativity can kill you, so can electric shock. However, electric shock is the surest way to get your heart started again.
-Andy
-- ================ Bill Burke Chief Architect JBoss Group LLC. ================
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ JBoss-Development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
