June 2008 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Controlling deployments via a barrier bean

by bstansberry＠jboss.com

Perhaps @HASingleton as the term "Singleton" seems overloaded. | @Target(ElementType.TYPE) | @Retention(RetentionPolicy.RUNTIME) | public @interface HASingleton | { | String partition() default "${jboss.partition.name:DefaultPartition}"; | } | A more general purpose form: | @Target(ElementType.TYPE) | @Retention(RetentionPolicy.RUNTIME) | public @interface HASingleton | { | String partition() default "${jboss.partition.name:DefaultPartition}"; | | Class electionPolicy() default org.jboss.ha.singleton.HASingletonElectionPolicySimple.class; | | Object[] constructorArgs() default new Object[]{ new Integer(0) }; | | Class[] constructorArgTypes() default new Class[]{ Integer.class }; | } | OT: Is there a general automagic facility/utility yet for doing String property replacement when populating metadata? For org.jboss.ejb3.annotation.clustered there's still manual code that does the property replacement. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155751#4155751 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155751

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Controlling deployments via a barrier bean

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : | @Singleton(partition="DefaultDomain" otherParam="xxx") For some reason I keep writing "DefaultDomain" which is from JMX instead of DefaultPartition ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155742#4155742 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155742

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Controlling deployments via a barrier bean

by bstansberry＠jboss.com

"scott.stark(a)jboss.org" wrote : Is the APPLICATION_CLUSTERED phase going to be useful? I'm thinking not. Seems like the concept was serving two functions: 1) Dealing with a profile service bootstrap dependency issue (i.e. can't do intra-cluster communications until the APPLICATION phase clustering services are available). We've eliminated that by deciding that a clustered profile service impl will have a channel as part of its bootstrap. 2) It was a sort of hard-coded marker for a clustered sub-profile. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155741#4155741 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155741

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Controlling deployments via a barrier bean

by adrian＠jboss.org

"bstansberry(a)jboss.com" wrote : | AIUI, though, the detection of an @Singleton annotation It is might be worth supporting @Singleton as well as a special case of @Activatable if it requires less boiler plate. i.e. you can synthesize some of the metadata and make the configuration easier. e.g. @Singleton(partition="DefaultDomain" otherParam="xxx") == @Activatable(policy="SomeSyntheticPolicy") where SomeSyntheticPolicy is a generated bean definition from the @Singleton metadata such as election parameters. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155737#4155737 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155737

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Controlling deployments via a barrier bean

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | If that is the case then you also could say (regardless of clustering) that a hot deployment scanner could be added to any profile service implementation. | | Again this orthogonal. | | It's then a hybrid profile service implementation. Where some sub-profiles | come from a versioned repository and others are unversioned in a directory. | Right, but there is a notion of "modified deployments" in the profile spi, and the hot deployment scanner implementation uses this. If we add a APPLICATION_TRANSIENT notion, whether the profile should detect modifications needs to be defined. Currently the profile implementations only look at the APPLICATION phase deployments. "adrian(a)jboss.org" wrote : | Whichever way you look at it, its still a sub-profile of the profile in operation | and needs some "metadata" to say how/if/when it gets activated. | | Ideally this should be a part of the management console where somebody can say this sub-profile/deployment gets activated according to this policy, | where the policy is a part of the profile itself. | Ok, I'll have to look at how deployment level policies (sub-profiles) could be implemented consistently regardless of the profile service implementation. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155735#4155735 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155735

17 years, 10 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: ending process does not end tasks

by kukeltje

no, not the default of a plain end-state, but only if one uses the end-process-completely attribute. A non-documented feature, that is not in the xsd, nor in the designer, nor in ...... Should not be a problem then... right? otoh, I have a patch that we can use locally, so it works for us now. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155729#4155729 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155729

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Controlling deployments via a barrier bean

by adrian＠jboss.org

"scott.stark(a)jboss.org" wrote : Its not completely true that: | anonymous wrote : | | 1) A scanner that populates the profile is a behavior of the basic profile service, but not of the full repository-based profile service. In the full version it's the DeploymentRepository impl itself that scans the filesystem for content. | | | in that you could still have an hasingleton scanner adding content to a profile regardless of what profile service implementation is in use. There should be a flag indicating that the deployment should not be a permanent part of the profile though. Is the APPLICATION_CLUSTERED phase going to be useful? Maybe this should be APPLICATION_TRANSIENT or some such to indicate a deployment that will not be remembered across restarts. | If that is the case then you also could say (regardless of clustering) that a hot deployment scanner could be added to any profile service implementation. Again this orthogonal. It's then a hybrid profile service implementation. Where some sub-profiles come from a versioned repository and others are unversioned in a directory. Whichever way you look at it, its still a sub-profile of the profile in operation and needs some "metadata" to say how/if/when it gets activated. Ideally this should be a part of the management console where somebody can say this sub-profile/deployment gets activated according to this policy, where the policy is a part of the profile itself. As I was trying to explain above, (but got side-tracked in implementation details :-) for fine-grained it gets harder because the link to the policy might be annotation on a pojo or a piece of metadata in jboss.xml, etc. That's why I suggested a jboss-activation.xml to try to make it easier to manage. The downside is it pushes the responsibility of this new metadata to the subsystems to read it, since only they know what it means to activate their fine-grained component. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155727#4155727 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155727

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Controlling deployments via a barrier bean

by scott.stark＠jboss.org

"adrian(a)jboss.org" wrote : | That's more long term (i.e. a proper implementation ;-). | The more fine-grained stuff involves defining some callbacks that are triggered by some policy. | | e.g. You might have (or it could be annotation based): | | | | public interface Activation | | { | | void activate(); | | void deactivate(); | | } | | | Ok, I see, activation is a runtime behavior driven by metadata that could be talking to the profile service. That makes more sense. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155723#4155723 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155723

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Controlling deployments via a barrier bean

by scott.stark＠jboss.org

"bstansberry(a)jboss.com" wrote : | There would probably need to be some API change related to this, in order to allow mgmt tools to activate/inactivate sub-profiles. If we didn't want to allow external clients to do that, it could just be done via an spi that an activation policy would use. | | AIUI, though, the detection of an @Singleton annotation or some other form of deployment-specific metadata is always done by a deployer; i.e. is not part of the profile service itself. (Waiting to be told I'm wrong ;) ) So you end up with a chicken and egg problem; you need to start deploying to find out a deployment is in an inactive sub-profile. That's fundamentally what drove me to the idea of using dependencies. I'd much prefer an approach where the deployers aren't even aware of content that isn't "activated". The profile service does not look at deployment metadata, and there is no profile metadata corresponding to a jboss-activation.xml descriptor currently. I don't see how we would go from a bean/component level annotation to a subprofile membership. It seems we are driving at having an additional ActivationPolicyMetaData component for each deployment (maybe even component), but this still leaves a gap between specifying an annotation on a bean and identifying that the bean's deployment has a singleton component. The profile service does not currently deal with makeup of a profile down to the component level. So what do we need for 1)? Its not completely true that: anonymous wrote : | 1) A scanner that populates the profile is a behavior of the basic profile service, but not of the full repository-based profile service. In the full version it's the DeploymentRepository impl itself that scans the filesystem for content. | in that you could still have an hasingleton scanner adding content to a profile regardless of what profile service implementation is in use. There should be a flag indicating that the deployment should not be a permanent part of the profile though. Is the APPLICATION_CLUSTERED phase going to be useful? Maybe this should be APPLICATION_TRANSIENT or some such to indicate a deployment that will not be remembered across restarts. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155721#4155721 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155721

17 years, 10 months

1
0
0 / 0

[Design of POJO Server] - Re: Controlling deployments via a barrier bean

by adrian＠jboss.org

"bstansberry(a)jboss.com" wrote : | AIUI, though, the detection of an @Singleton annotation or some other form of deployment-specific metadata is always done by a deployer; i.e. is not part of the profile service itself. (Waiting to be told I'm wrong ;) ) So you end up with a chicken and egg problem; you need to start deploying to find out a deployment is in an inactive sub-profile. That's fundamentally what drove me to the idea of using dependencies. I'd much prefer an approach where the deployers aren't even aware of content that isn't "activated". That's more long term (i.e. a proper implementation ;-). The more fine-grained stuff involves defining some callbacks that are triggered by some policy. e.g. You might have (or it could be annotation based): | public interface Activation | { | void activate(); | void deactivate(); | } | But it will depend upon what you are doing on how the object gets registred with the policy. The simplest case might be something like; | @Activatable(policy="SomeNameInTheMC") | public MyPOJO | { | @Activate | public void method1(); | | @Deactivate | public void method2(); | } | | The registration can then be handled using something similar to the @JMX | handling. i.e. you write a lifecycle-install handler | that looks for the annotation/interface and does the relevant registrations. | (This requires another interface, i.e. ActivationPolicy or Activator) | | More complicated would be an MDB that you want to start/stop delivery on some | kind of schedule. | That would involve registering the MDB container (or some activatable extension) | with the activation policy at deployment and wait for the callbacks. | Of course if the MDB container is just a POJO then it is the same as above. | | The activation of the sub-profile also be the same thing. | The de/activation methods just to talk to the profile service. | | | | @Activatable(policy="HASingletonDefaultDomain") | | public class ProfileActivator | | { | | private String subProfileName; | | @Inject | | private ProfileService profileService; | | | | @Activate | | public void activate() | | { | | profileService.deployProfile(subProfileName); | | } | | // etc. | | | We could also get more complicated and with activation requiring multiple policies | and logic to decide whether something is active. | This probably ties in with what Ales was doing with the JBoss Rules integration in | the MC, but that's obviously in the 5% of use cases. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155719#4155719 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4155719

17 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2008