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
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=bbop=viewtopicp=3874114#3874114
Reply to the post :
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
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
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
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
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
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
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
and
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
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
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
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
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
15 matches
Mail list logo
