[Design the new POJO MicroContainer] - Re: Naming, @JNDI and OnDemand
by alesj
"adrian(a)jboss.org" wrote :
| We'll maybe I'm dreaming and didn't actually implement it properly (yet ;-)
|
I guess we need something like this:
| Index: dependency/src/main/java/org/jboss/dependency/plugins/AbstractController.java
| ===================================================================
| --- dependency/src/main/java/org/jboss/dependency/plugins/AbstractController.java (revision 88788)
| +++ dependency/src/main/java/org/jboss/dependency/plugins/AbstractController.java (working copy)
| @@ -726,8 +726,9 @@
| }
| }
|
| - if (ControllerMode.AUTOMATIC.equals(context.getMode()))
| - context.setRequiredState(ControllerState.INSTALLED);
| + // set the required state
| + ControllerMode mode = context.getMode();
| + context.setRequiredState(mode.getRequiredState());
|
| if (trace)
| log.trace("Installing " + context.toShortString());
| Index: dependency/src/main/java/org/jboss/dependency/spi/ControllerMode.java
| ===================================================================
| --- dependency/src/main/java/org/jboss/dependency/spi/ControllerMode.java (revision 88788)
| +++ dependency/src/main/java/org/jboss/dependency/spi/ControllerMode.java (working copy)
|
| public enum ControllerMode
| {
| - AUTOMATIC("Automatic"),
| - @XmlEnumValue("On Demand") ON_DEMAND("On Demand"),
| + AUTOMATIC("Automatic", ControllerState.INSTALLED),
| + @XmlEnumValue("On Demand") ON_DEMAND("On Demand", ControllerState.DESCRIBED),
| MANUAL("Manual"),
| DISABLED("Disabled"),
| ASYNCHRONOUS("Asynchronous");
| @@ -46,6 +47,9 @@
| /** The mode string */
| private final String modeString;
|
| + /** The required state */
| + private ControllerState requiredState;
| +
| /**
| * Create a new mode
| *
| @@ -53,9 +57,18 @@
| */
| private ControllerMode(String modeString)
| {
| + this(modeString, null);
| + }
| +
| + private ControllerMode(String modeString, ControllerState requiredState)
| + {
| if (modeString == null)
| throw new IllegalArgumentException("Null mode string");
| + if (requiredState == null)
| + requiredState = ControllerState.NOT_INSTALLED;
| +
| this.modeString = modeString;
| + this.requiredState = requiredState;
| }
|
| /**
| @@ -87,6 +100,16 @@
| return modeString;
| }
|
| + /**
| + * The required state.
| + *
| + * @return the required state
| + */
| + public ControllerState getRequiredState()
| + {
| + return requiredState;
| + }
| +
|
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230819#4230819
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230819
16 years, 11 months
[Design of JBoss ESB] - AS5 changes
by beve
I've been working on getting ESB4.x working on AS5 and this requires some changes to the codebase apart from the addition of deployers for AS5.
We have a number of mbeans defined in jbossesb.sar/META-INF/jboss-service.xml. Some of them lookup an mbean named ServerConfig only find out the server data directory or the server tmp directory. This causes problems with AS 5 as the ServerConfig class has changed.
For AS 5 I've added a property to the mbeans that can be set in the configuration:
| <mbean code="org.jboss.soa.esb.listeners.config.JBoss4ESBDeployer" name="jboss.esb:service=ESBDeployer">
| <attribute name="ServerTempDir">${jboss.server.temp.dir}</attribute>
| <depends>jboss.esb:service=ESBRegistry</depends>
| <depends>jboss.esb:service=JuddiRMI</depends>
| </mbean>
|
So adding the ServerTmpDir property we can by pass the lookup:
| if (serverTmpDir != null)
| {
| tmpDir = new File(serverTmpDir);
| }
| else
| {
| final ServerConfig config = (ServerConfig) MBeanProxyExt.create(ServerConfig.class, ServerConfigImplMBean.OBJECT_NAME);
| tmpDir = config.getServerTempDeployDir();
| }
|
This is quite ugly (but can be cleaned up) and it would be cleaner to always use the properties instead. This might cause problems though if users upgrade only jbossesb-rosetta.jar and don't update their configuration files. Leaving this as is will cover both.
Should we support only properties or both options do you think?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230807#4230807
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230807
16 years, 11 months
[Design the new POJO MicroContainer] - Re: DESCRIBE phase - Dependency builders for MC Beans
by kabir.khan＠jboss.com
"alesj" wrote : What exactly do you mean by "current filters are classname based"?
| You cannot do globing (org.acme.foobar.*) like Adrian suggests?
You can do filtering on classnames, but what if you want to use aop for some instances and not for others?
Also, the current filters are there to turn off loadtime weaving for particular classes, they are not used by the proxies. This was a requirement from about 2 years ago since all "org.jboss." classes are excluded and people had to add their classes to the AspectManager.include attribute to get proxies created for them. There is a forum thread for that, and I'll post it here if I find it.
"alesj" wrote :
| Kabir, what's the current search/matching mechanism?
| Can it be made plugable?
| Or how much would it take to improve that?
|
It is javacc based. Pointcut expressions are broken apart into their class + method/field names and signatures. For every candidate class for weaving /creating a proxy each field/method/constructor is compared against every pointcut (from the bindings). If annotations are used in the pointcut expressions it looks for those in the bytecode for the field/method/constructor and then hits the advisor annotation overrides + metadata.
Changing it would be a big job, but it could be made pluggable. Flavia did some stuff for her masters which we had planned to add to AOP later, which I think should speed this up. I'll let Flavia provide more info on that.
I don't know how easy these will be to do, but here are a few other initial ideas:
-The @DisableAop stuff can be made more fine-grained. It can still disable everything as it does, but since there will be less aop lifecycle bindings than normal bindings and aop lifecycle does not require a proxy and an advisor something like @DisableAop(lifecycle=true) could still check for dependencies for the aop lifecycle stuff and invoke those while avoiding the "real" aop bindings.
-If, for example, the messaging bindings should only be applicable to the messaging classes and not everything else. This would mean including something in the messaging jboss-aop.xml to indicate that these aspects should go into a child aop domain rather than the main aspectmanager, and some way to make sure that the classes would use that child domain. Apart from the bindings between classes and child aop domain, this would be similar to how the aop by scoped classloader stuff works.
-Some annotations could be made always checkable, e.g.
"jason" wrote :
| I do agree that supporting various service annotations is useful
|
| @JBossService
| @interface SomeAnnotation{}
|
and bindings containing pointcut expressions with these annotations are always checked.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230773#4230773
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230773
16 years, 11 months
[Design of JBoss jBPM] - Re: Task assignment privileges
by tom.baeyens＠jboss.com
i think that can depend on a lot of factors.
some determine this by static authorization role. e.g. if you are an 'manager' then you can do that.
in other scenarios it might depend on the identity component group membership. e.g. reassignment is only allowed within your team
i don't see a single way on how we'll be able to tell who is allowed to assign/reassign a task. so our strategy then is typically to make it pluggable.
pluggable authorization is already a part of the command based service methods. the idea is that an authorization interceptor would delegate to some custom configured AuthenticationSession like this:
public class AuthorizationInterceptor extends Interceptor {
|
| public <T> T execute(Command<T> command) {
| Environment environment = Environment.getCurrent();
| if (environment==null) {
| throw new JbpmException("no environment for verifying authorization");
| }
| AuthorizationSession authorizationSession = environment.get(AuthorizationSession.class);
| if (authorizationSession==null) {
| throw new JbpmException("no AuthorizationSession in environment for verifying authorization");
| }
| authorizationSession.checkPermission(command, environment);
| // if the authorization check succeeded, proceed
| return next.execute(command);
| }
|
| }
|
but i don't think we have a binding or documentation for this yet. don't think that is a priority.
does that answer your question ?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4230748#4230748
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4230748
16 years, 11 months