The validate works. So I switched trunk to use HASingletonProfileManager instead of HASingletonDeploymentScanner.
One concern with the validate is you can get unsatisfied dependencies. Say you have a war in deploy-hasingleton. And say during the 'all' profile deploy the cluster/deploy-hasingleton-jboss-beans.xml file is deployed before jboss-web.sar. That will trigger activation of the deploy-hasingleton profile, and the war will not complete deployment pending dependency on jboss-web.sar. Not a problem, since at the end of the whole thing the dependency will be satisfied and the war will deploy. Except, the validate call during the deploy-hasingleton activation will throw an exception.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204865#4204865
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204865
"stale.pedersen(a)jboss.org" wrote :
| mostly because then we are sure that we will get a CtClass instance within the parameter. there is also a String parameter if you would prefer to use that. it makes little sense to have a ClassInfo param since then we would just do the same work internally as with the String param.
|
I still don't see why it has to be a MutableCI.
"stale.pedersen(a)jboss.org" wrote :
| its another signature, this is something similar to CtBehaviour.getSignature(). imo it belongs in MMI.
|
Why do you need it?
How it should look like?
Why isn't the one in MDR good enough?
Afaik AOP already uses MDR.
btw: there is a Javassist kind of Signature:
- http://anonsvn.jboss.org/repos/jbossas/projects/jboss-mdr/trunk/src/main/...
I already use it in annotation scanning.
"stale.pedersen(a)jboss.org" wrote :
| is it ok if i start commit to jboss-reflect? i can exclude the new files in the pom if needed.
|
I don't wanna sound pita, but let's finish this discussion first.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204835#4204835
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204835
Jeff's new tests:
| Standard Output
|
| using network settings:
| lo: 0:0:0:0:0:0:0:1%1
| eth0: fe80:0:0:0:214:22ff:fe1d:1c29%2
|
| acceptor=0:0:0:0:0:0:0:1%1, connector=0:0:0:0:0:0:0:1%1, mustConnect=true
| acceptor=fe80:0:0:0:214:22ff:fe1d:1c29%2, connector=fe80:0:0:0:214:22ff:fe1d:1c29%2, mustConnect=true
| acceptor=0.0.0.0, connector=0:0:0:0:0:0:0:1%1, mustConnect=true
| acceptor=0.0.0.0, connector=fe80:0:0:0:214:22ff:fe1d:1c29%2, mustConnect=true
|
| Standard Error
|
| There must be at least 3 network interfaces: test will not be executed
| There must be at least 3 network interfaces: test will not be executed
| There must be at least 3 network interfaces: test will not be executed
|
|
I don't think you can assume there are 3 network interfaces.
Commenting out test for now...
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204804#4204804
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204804
"adrian(a)jboss.org" wrote :
| START OF IMPLEMENTATION DISCUSSION
|
| Anyway, there's a number of ways to do it.
|
I'm sure Ales would want to do something more complicated
but more dynamic and pluggable such as defining a
| public interface GlobalCapabilitiesProvider
| {
| Capabilities getCapabilities()
| }
|
The ClassLoading would then have an in/uncallback for GlobalCapabilitiesProvider
and one your aop beans would implement it or use a helper bean exposed by
the classloading module.
That way the configuration of your "always exported packages" is in the aop.xml
and only gets applied if aop.xml is deployed.
But others can also use this mechanism if it is required without having to
worry about mixing the configuration together in classloader.xml. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204782#4204782
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204782