On Jun 12, 2006, at 10:44 AM, Jeff Genender wrote:
Dain Sundstrom wrote:
I think the problem here is the GBean framework is not flexible
enough
to support this. The integrations of Tomcat, Spring, ServiceMix, and
ActiveMQ have been extremely painful and have resulted in (no
offense)
very limited integrations.
No offense taken. Painful is an understatement ;-) But, what's
limited
about them? From the Tomcat perspective, I believe we support nearly
all Tomcat objects as well as have enhanced features, such as the
ability to run 2+ full Tomcat containers at the same time under one
house.
My knowledge of the Tomcat integration is limited, but from what I
understand the integration is limited to what we put in out GBean
wrappers. From you statements, it sounds like we have full Tomcat
support, but every time they add a new feature we have to update the
wrappers. In the case of AMQ, the integration is very limited. AMQ
supports configuration from the very simple (what G supports) to very
very complex. The complexity scale is sliding based on how much
detail you put in your spring.xml file. It is also very easy to
extend their broker using standard spring concepts.
Do you have suggestions on what can be done to make the
integrations better?
Yep. It is mostly the list of stuff Hiram has been asking for for 2
years.
- No proxy
- No GBeanInfo
- No Serialization
and a few I have been thinking about
o Factory bean support
o Infinitely complex configurations (a.k.a nested GBeans or spring-like)
o Module contract which allows for multiple module types (not just
Geronimo's current Configuration class)
- Pluggable class loader creation
- Pluggable life cycle
- Pluggable construction
- Pluggable management
With that said...it has been difficult having the GBean wrappers
up-to-date with changes in the Tomcat APIs. I would have much rather
plugged in the container and leveraged Tomcat as much as
possible...but
I digress...
Nope, that is my point. GBeans are simply too inflexible and we need
to plot a path out of here :)
The approach Aaron has laid out is in my mind the best given the
current
technology, but I'd rather not see us go down the path of adding more
deployers. The deployers are the major thing holding back
integration
of XBean (this is why I rearchitected OpenEJB deployment in
dead-1.2).
Then again, if I were you, I don't think I would believe that a XBean
integration is ever coming.
Again, as long as his Job GBeans do not prevent one from using the
generic Quartz API to create jobs, then I am fine with it.
I want out framework to be able to support Services like the Quartz
Job. You should be able to expose the Job to the kernel so it can
participate in livecycle, management, and references, but that should
not come at the cost of giving up construction, or managing your own
lifecycle.
Anyway, with the current technology, I don't think the Job service
should be a GBean.
-dain
