marc fleury wrote:
>
> |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??
Well, these are good questions. The current approach - that of having a
hard-coded list of types of deployers - is a PITA. A possibility is to
configure the J2eeDeployer with a mapping of module type (jar, war, etc)
to deployer, e.g. <attribute
name="deployers">jar=ContainerFactory;war=EmbeddedTomcat;rar=RARDeployer</attribute>.
I think that this is potentially not flexible enough, though.
> 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?
Isn't this taken care of by the context classloader thing? Or are you
referring to something else?
> 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.
Righty - I'll wait until I hear what he has to say before embarking on
any large-scale work.
> |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?
Nope, just a strong stomach :-)
Toby.
>
> 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
