Two separate issues here:
For the first one I would also separate the DConfigBeans from the
-builder modules. As we found before, they are used in totally separate
parts of the JSR88 model (configuration vs. build) and there is no need
to couple them together.
Also, the DConfig stuff needs to run in a disconnnected
DeploymentManager where the permissions defined by the spec do not
support starting a kernel etc. to run the builders. Separating out the
DConfig stuff would allow them to run in this mode.
For the second, one of the reasons we went with two implementations was
to allow each to take advantage of advanced features of each web
container rather than being constrained by the lowest common
denominator. I would suggest the best thing here would be to define a
set of common APIs for interfaces between the listeners, the central
container and the web applications. Then perhaps there could be a common
support infrastructure that supported the LCD but each implementation
would be able to specialize as necessary.
Basically don't force the LCD on everyone.
--
Jeremy
Aaron Mulder wrote:
> All,
> So the JSR-88 DeploymentManager needs to reference the
> DConfigBeans of all the module types. This includes at least:
>
> * Connector Builder
> * Jetty Builder
> * Tomcat Builder
> * OpenEJB Builder
> * shared Builders (naming, security, etc.)
>
> The problem is that right now, the DeploymentManager is in
> deploy-tool, the DConfigBeans are in *-builder modules, and the *-builder
> modules depend on deploy-tool. Which of course means that deploy-tool
> cannot depend on them.
>
> So I think we need to:
>
> - Separate the DeploymentManager implementations from deploy-tool, into a
> mini-module that depends on deploy-tool and *-builder.
>
> - Move toward a unified web builder for both Tomcat and Jetty. I
> personally feel that it's mandatory to make the WAR configuration the
> same regardless of which container you happen to have deployed, and it
> also would save us from having two different JSR-88 DeploymentManager
> configurations that you have to pick from (presumably based on the
> connection URL you provide) depending on which web container you happen
> to want to run on.
>
> Aaron
|