|It looks to me as though there are a few mbeans that deploy various
|things (J2eeDeployer, ContainerFactory, EmbeddedTomcatService) and they
|all have a similar interface (deploy, undeploy, isDeployed). Why not
yes
|extend ServiceMBean with these methods and call it DeployerMBean? Why
|not create an abstract implementation of this called
|DeployerMBeanSupport that converts the strings to URLs and keeps tracks
|of which URLs have been deployed? Doing this would make life easier for
|people wanting to add deployers for different kinds of modules (such as
|resource adapters).
Ok so a specific "deployment aware" service would register with the
"DeployerMBeanSupport" and upon deployment you call everyone? How do you
know what parts of the ear unit goes where? i.e. how do you know to call the
ejb stuff with jar only and the web stuff with war only and the connector
/ressource with car/rar??
Note that the spec (J2EE) only defines the notion of the "application" unit
at deployment time and that "association" dissapears once it is deployed
(essentially it is a bunch of beans running). That Service you talk about
would keep track of what is deployed, that would be good.
It was one of the original goals of the J2EE deployer but you would add the
capacity to add any "deployment aware" MBean? Again how do you know what
goes where in the runtime once you take it away from the EAR?
Do hook with Sebastien, he sits on JSR88 (the deployment JSR) as a
representative of JBoss on that board... he can give you valuable points on
the "this is a runtime application unit". I sure hope they are defining the
mappings... Sebastien is travelling right now but should be back soon.
|I'm using this DeployerMBean idea for my connector architecture resource
|adapter deployer, so I could convert J2eeDeployer et al to it and clean
|it up a bit if that would be helpful.
clean it clean it, need some acid?
marc
|
|Toby.
|
|marc fleury wrote:
|>
|> if you could rewrite J2EE Deployer at the same time that would be pretty
|> good :)
|>
|> marc
|>
|> |-----Original Message-----
|> |From: Rickard �berg [mailto:[EMAIL PROTECTED]]
|> |Sent: Friday, December 08, 2000 3:42 AM
|> |To: jBoss Developer
|> |Subject: Re: [jBoss-Dev] Proposed refactoring of ContainerFactory-Ch
|> |ainingDeployment services in general
|> |
|> |
|> |"Jung , Dr. Christoph" wrote:
|> |> >Are you saying that you are having multiple EAR
|applications, and where
|> |> >an EAR can optionally specify it's parent EAR?
|> |>
|> |> well, yes. I should have used more J2EE vocabulary in order to make
|> |> it clear. Whenever referring to "ejb-jar", I really meant "EAR
|> |application"
|> |> - maybe confused
|> |> that because we are currently not using JSP,
|> |> but a thick and comfortable VB-GUI.
|> |
|> |Alrighty.
|> |
|> |> >But multiple EAR's would do the trick, right?
|> |> >But what if sales and stock both references masterdata
|*jar*'s through
|> |> >classpath manifest? I.e. they are seemingly redundant but in
|reality use
|> |> >the same jar. Would that be ok?
|> |>
|> |> My argument wrt minimising redundancies would be addressed by this
|> |> technique.
|> |> The only really relevant argument remains ... performance and
|> |optimisation
|> |> argument, yes.
|> |
|> |Good, then we agree on consequences.
|> |
|> |> >If I understand you correctly, all you're saying is that you
|want an EAR
|> |> >to be able to specify a "parent", and then that parents classloader
|> |> >should be used as parent to the EAR's own classloader. Right?
|> |>
|> |> You made a long talk very very short (I bet I�ll get a nick like
|> |> CG"verbose"J on this list). You were an analyst in your previous life,
|> |> were�nt you ?
|> |
|> |Something like that, yes ;-)
|> |
|> |> >Nevertheless, yes this is interesting :-)
|> |>
|> |> puuh, interesting enough to extend the J2EEDeployer
|(undermine, undermine
|> |> ...) ?
|> |
|> |Yes, absolutely. It would an easy fix too (and easy fixes are nice,
|> |regardless of their use 8-) ).
|> |
|> |Basically, we would need an jboss-application.xml file in addition to
|> |the application.xml one, in which one should be able to specify parent
|> |application. On deployment the parent of classloader of the application
|> |would be the CL of the parent application. Also, any beans in child
|> |application should be able to use parent application EJB names in
|> |ejb-link references. Hey, this is getting really really interesting! So,
|> |the only new rule is that EJB-names in child EAR's may not conflict with
|> |EJB-names of beans in the respective parent application.
|> |
|> |Sounds ok?
|> |
|> |It is easy to do this, but not trivial. If you're interested in coding
|> |this I'd be willing to give you a few pointers on how to make it as
|> |clean as possible.
|> |
|> |regards,
|> | Rickard
|> |
|> |--
|> |Rickard �berg
|> |
|> |Email: [EMAIL PROTECTED]
|> |
|> |
|
|--
|Toby Allsopp
|Research
|Peace Software International Ltd
|Ph +64-9-3730400
|
|
