Hi.
In my poking around trying to figure out where to add deployment of
resource adapter RAR files, I stumbled upon this "J2EE Deployer" of
which you speak. I must say that "rewrite" was the first word that
sprang to mind (well, maybe not the first...).
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
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).
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.
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
