|>I agree that the exact details of how the EAR deployer finds the
|>deployer for JARs or whatever can be worked out easily later.
|
|to me, this issue appears to be a prime candidate for applying
|a suitable design pattern, such as the Chain Of Responsibility or better a
|Tree of Responsibility? Upon startup of the server,
|a dedicated DeployerFactory could configure a suitable sequence of
|deployers
|to divide&conquer the complex deployment process, like
|
|J2EEDeployer(EAR)-->EJBJarDeployer(JAR)
| -->WARDeployer(WAR)
This is what the current deployer does albeit hardcoded.
I like the idea of registering the deployers by deployment type and keeping
a list of them independently of their target container (jboss is a jar
deployer, tomcat is a war deployer) however where/when is that needed?
Where do we need more War deployers and jar deployers? Let's XP this
puppy...
|>What is the purpose of the classloader-related methods? Is this an
|>alternative to using the context classloader? I'm not averse to making
|>the classloader stuff more explicit, but why have both?
|
|This would be indeed the IMHO nicer alternative to setting the context
|classloader ... deploy(URL) would hence no more use the context
|classloader,
|but rather operate like in J2EEDeployer where a completely new classloader
|is constructed.
...
pffff
repackage-itis...
It doesn't bring much. Except that it is explicit in the interface and
"explicit" stuff is somewhat better.
|>I don't see any value in subclassing DeploymentException, but perhaps
|>that's short-sighted.
|
|You never know what will happen in the future ;-) Maybe just an instance of
|generalomania that I�m very susceptible to.
Let's keep it simple please
|>I'm unclear on how we can use ejb-ref for inter-EAR dependencies. I've
|>just read what I think are the relevent bits of the EJB (19.3) and J2EE
|>(5.3) specs and it doesn't seem to say anything about ejb-refs that are
|>resolved to EJBs from a different application. It certainly does say
|>that ejb-link can only refer to EJBs in the same application.
|
|>Are we thinking of embracing/extending this so that ejb-link can refer
|>to EJBs in other EARs in the same logical "JBoss application"? Or, are
|>we going to provide a way to specify this in our application-jboss.xml
|>that we need for the classloader parent thing?
we have a way in jboss.xml to specify out of jar beans through their jndi
name in runtime
|>How about this:
|>1) a request to deploy an EAR is received (regard naked JARs or WARs
|>as having an implicit EAR - is this correct? Or is there a global
|>default EAR kind of like the default package in Java?)
|
|Not sure about this, for naked jars and wars, you could ask the
|EJBJarDeployer or the WARDeployer directly, could�nt you? Asking
|J2EEDeployer could then result in an exception?
....
?
|what about the following (which is quite similar, but more like I would
|implement it):
|
|2) if this EAR is currently deployed, undeploy it first (which results in a
|tree of children applications "chld" teared down recursively).
|
|3a) if the EAR has a parent that�s already deployed, construct a new
|classloader "cl" with the parents one as parent.
Yes this is where the CL service is needed you need to retrieve the
classloader but I don't believe you can only rely on the URL (each URL would
need to know where the other URL's are, what a jar knows is the class
dependency, home and remote, not the URL)
|3b) if the EAR has an undeployed parent, construct a new classloader "cl"
|that has a its parent the resulting classloader of deploying the
|parent EAR.
Please retype the above sentence. Do you mean redeploy the parent and get
the classloader as 3a?
|3c) if the EAR has no parent, construct a new classloader "cl" without
|parent.
Parent can be missleading it is a hierarchical relationship. I don't think
"shared" classes is a hierarchical relationship. It is a flat one. (Class
A and B share class C).
|>An alternative is to put another layer in the model and keep track of
|>what EAR the modules came from explicitly. This information is needed
|>when you decide to redeploy something due to dependencies, so it might
|>be a good idea to track it explicitly. This means we have something like:
|
|>JBoss application 1--* EAR 1--* Module
here at least you keep the URL to classes in there.
Let's get some code gentlemen, I believe we are beating this to death and
without code we can waste more time
marc
