Correct, and this is certainly the future deployment process architecture as a
deployment is just a packaging with instructions on how to configuration the
various aspects.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3874114#3874114
Reply to the post :
ht
setHarURL was needed simply to allow the deployer to inject this value into the
mbean. Use of this at runtime or through the console is highly discouraged ;)
Another thought is that in the scheme y'all are proposing (provided multiple
interceptors can process the deployer init stuff) we could s
Yes, after looking at what the HARDeployer is doing this looks correct. If
there was a general behavior of exposing a SarURL attribute from the
ServiceMBeanSupport level the Hibernate service could simply use that and drop
the HarUrl. There is a notion in the Hibernate service that allows the Ha
It seems to me the whole hibernate deployer could be replaced by an xmbean
interceptor to the SARDeployer that checks in the init step if any of the
specified MBeans is of type org.jboss.hibernate.jmx.Hibernate, in order to do
the extra "HarUrl" call to it to complete the setup.
However, that
This is why the JBossXB framework needs to be adopted. Alexey already has the
basis for this as one of the JBossXB testcases. The processing of the mbean
deployment info could then be extracted out and even put into a xmbean
interceptor that placed the deployment metadata into the DeploymentInfo
I think Adrian is correct in that a HARDeployer and a SARDeployer are
conceptually very different "things". There is certainly a lot of overlap in
functionality (the worst part being the xml parsing).
After further thought on this, it seems a much better approach here is the
simply better enca
I think the experiment overall worked (although Scott had some reservations
about it so it's in HEAD but not 4.x).
It was about providing the EJBDeployer (in fact, it should work with all other
deployers) the ability to instantiate and tear-down security domains, in the
presence of a META-INF/l
anonymous wrote :
| I don't disagree. But basic software maintence philosphy tells me to not
write a class that is 340 lines of code where approximately 300 is duplicated
somewhere else ;)
|
Agreed, but also 300 lines across 4 or five classes isn't that big an issue
when they hardly ever c
On my proposal. I am saying:
1) SubDeployerSupport is too generic (deliberatly) since it allows things like
Tomcat deployments to be processed through it.
2) Ideally, deployments should be:
archive/file -< MBeans/JavaBeans
-< means many-to-one
3) I wrote SimpleSubDeployerSupport that does
archi
anonymous wrote :
| I am saying don't extend SARDeployer. Just basic OO principles tells me
| that the HAR deployer is NOT a SAR deployer.
|
| public class X extends Y
| means "X isA Y" in OO speak.
|
I don't disagree. But basic software maintence philosphy tells me to not write
I'm speaking in the abstract because I don't fully understand what you
are trying to achieve.
I am saying don't extend SARDeployer. Just basic OO principles tells me
that the HAR deployer is NOT a SAR deployer.
public class X extends Y
means "X isA Y" in OO speak.
I don't see why you need to tou
I don't understand what you mean by
anonymous wrote :
| specialises the multiple deployment version with just one MBean deployed
|
By "one MBean deployed" are you refering to the deployer MBean? Or the MBean
deployed by the deployer? ;) I assume you mean that we create a SARDeployment
an
Can't you just extend SimpleSubDeployerSupport to have multiple mbeans deployed?
i.e. create a MultipleSubDeployerSupport or whatever you want to call it.
Alternatively (and probably better), you could do it the other way around and
make a
SingleSubDeployerSupport that specialises the multiple de
Just to complete my thought ;)
Given the limitation I mentioned regarding the potential of multiple
heterogeneous-typed mbeans, would your suggestion be to extract the pertinent
lifecycle logic out of SARDeployer into a new deployer support class (say,
HeterogeneousSubDeployerSupport) which pro
So you and I did a bunch of the same stuff ;)
So really I was extending SARDeployer for
1) its XML parsing; since it is the same logic needed for the HAR;
2) its deployment lifecycle logic; since, aside from the two deviations
mentioned previously, it is exactly the same needed for the HAR
One s
Common code should be in SubDeployerSupport.
I even created a SimpleSubDeployerSupport, that models more how deployment
should be done, rather than exposing all the details of SubDeployerSupport.
1) Define your extension - getExtension()
2) Define where your metadata xml exists relative the main
16 matches
Mail list logo