Resolution: Won't Fix or Usage Issue
Affects Version/s: None
Fix Version/s: None
Component/s: Modules: (other)
MULE-1617 integrate mule into geronimo MULE-1022 Improvements to functional / integration tests MULE-210 geronimo-spec-j2ee.jar produces conflict on Tomcat 5.x MULE-6020 Improve support for Spring bean definition profiles MULE-914 Improve support for JMS 1.0.2 MULE-134 Improve Jmx support MULE-773 The Jms API jar should not be shipped with the Mule RA MULE-1458 Improve RMI support on multi-NIC servers MULE-3313 Improve scripting example app. MULE-9097 OSGi: Support for app plugins
Brainstorming from Ross and Aaron Mulder:
> - Mule uses Geronimo JTA/XA transaction manager
[Ross Mason] We've Done this with other AppServers and have support of
WebLogic, Websfear, Jboss and can easily added the same for Geronimo
> - Mule uses Geronimo security realms for authentication / to create a
> Subject for authentication (via JAAS, etc.)
[Ross Mason] This will need investigation, but Mule can delegate
authentication to different providers
> - Mule uses Geronimo factory to create SSL factories so all the
> Keystores, etc. are handled by Geronimo and don't need to be
> configured in multiple places
[Ross Mason] I like this feature, but we don't currently support it. We'd
need to adapt the socket transports to do this but it should be
> - Mule runs in Geronimo and Mule services can be
> hot-deployed/undeployed/redeployed using the Geronimo deployer
> (command-line, web console, Maven plugin, etc.)
[Ross Mason] Does this mean we'd need write a Mule Xbean plug-in?
> - Mule uses Geronimo HTTP server for any HTTP/HTTPS endpoints (easy
> if you just want to control the URL beyond something like
> http://server:port/context/* but hard if you want to specify the port
> and/or context root)
[Ross Mason] Mule can bind to any Servlet container to receive requests
rather than using Mule's Http transport.
> - Mule uses Geronimo thread pool(s)
[Ross Mason] Easily done. You can just add a Geronimo Thread Pool factory
that exposes Geronimo managed pools. I guess the question is how does Mule
look up Geronimo Thread pools?. This sounds like a similar/same mechanism
that Resource Adapters use to share App Server resources. Are we talking
about JCA? Mule has a JCA resource adapter.
> - Expose EJBs deployed in Geronimo as Mule endpoints
[Ross Mason] This is already possible using the EJBContainerContext in Mule.
> - Expose a client API in JNDI for J2EE components so they can send
> messages to the Mule bus
[Ross Mason] Are you talking about JCA here?
> - Figure out a way for Geronimo to pass a Subject created by a secure
> web app to Mule to invoke secure services in Mule
[Ross Mason] Would need to investigate this
> - Expose Mule management, notifications, and statistics through the
> Geronimo JMX/JSR-77 management interfaces
[Ross Mason] We already expose this through JMX, I guess might just need a
clean way to integrate this with Geronimo
> - Add Mule screens to the Geronimo web admin console
> The basic idea is that you should be able to start/stop, manage,
> monitor, deploy to, etc. the combined system as if it was one. And
> that applications should be able to use the features of both – e.g. a
> J2EE web application sending messages to the Mule bus, or a Mule
> service dispatching messages to be handled by a J2EE session bean
> (even when using things like security and transactions on both sides).
> The basic procedure for creating a plugin is to get the services running in
> Geronimo as we want, and then use an admin console tool to export the
> Mule services as one or more plugins. Though if you use Maven to
> build Mule it's possible to eventually build plugins directly as part
> of the Mule build.
[Ross Mason] Many of the points we can already do or just require some
minimal coding. I think one place to start is with a plug-in that allows
Mule to be deployed to Geronimo and weave our Jmx support in as well.