[adrian.brock]

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.

[brian.stansberry]

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.

[adrian.brock]

@Singleton(partition="DefaultDomain" otherParam="xxx")

For some reason I keep writing "DefaultDomain" which is from JMX
instead of DefaultPartition ;-)

[brian.stansberry]

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.

[brian.stansberry]

Something ate part of my first version. Should have been:

@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface HASingleton
{
 String partition() default "${jboss.partition.name:DefaultPartition}";

 /**
 * Position in the current view that defines the singleton master.
 * 0 means the oldest node, 1 means 2nd oldest, ...
 * -1 means the youngest node, -2 means 2nd youngest, ...
 */
 int position() default 0;
}

[adrian.brock]

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.

You'll have to explain what you mean on a different thread.

If I understand correctly ...
I don't think its possible in general since in most cases
MetaData.getAnnotation() will just be returning Class.getAnnotation()
which is immutable, its a jdk object and
we don't "intercept" the fine grained Clustered.partition() invocation.

[adrian.brock]

You'll have to explain what you mean on a different thread.

I started a thread here:
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4155761#4155761

[brian.stansberry]

Re: the property replacement, yeah, my question wasn't clear. I'll open another thread.

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.

Essentially we're talking about another step in the lifecycle -- create/start/activate/deactivate/stop/destroy that all containers would have to support.

Thinking a bit about whether that maps to the "valve" concept where (AIUI) a component is brought all the way to DeploymentStage.REAL and in a final change to DeploymentStage.INSTALLED external things like JNDI refs, request pipelines etc are switched.

Interesting thing to me about this is for JEE components it allows a fast activation following ha singleton failover, since the service is 90+% ready to go when the node becomes master.

[adrian.brock]

Essentially we're talking about another step in the lifecycle -- create/start/activate/deactivate/stop/destroy that all containers would have to support.

I don't really see it as a true lifecycle step since you're NOT waiting to resolve a
dependency. The context is in a valid final state, its just inactive.

I suppose you could see it as an alternative to the "Installed" state, e..g
InstalledInactive and InstalledActive could be alternate states
with some processing going on when it switches between the states.

But the transistion is decided by some arbitrary notiifcation, not a dependency
(unless you count the dependency on oneself being installed :-)

Thinking a bit about whether that maps to the "valve" concept where (AIUI) a component is brought all the way to DeploymentStage.REAL and in a final change to DeploymentStage.INSTALLED external things like JNDI refs, request pipelines etc are switched.

It certainly relates to the valve, but the valve mainly involves tracking and waiting
for requests to complete.
Again this could be considered a different state
where you allow old requests but hold/deny new ones.
A sort of "InstalledDeactivating" state. ;-)

Whether we would actually implement it that way, is a different issue.

[adrian.brock]

Interesting thing to me about this is for JEE components it allows a fast activation following ha singleton failover, since the service is 90+% ready to go when the node becomes master.

As long the components are written to respond to the activate() callback
and not the start() callback.
i.e. the container is created but its frontend isn't bound into jndi
or linked as a valid web context etc.

That's certainly a better semantic for the valve/redeploy processing since it almost
becomes an atomic swap/failover instead of waiting for the full undeploy/deploy
cycle. But there's many other issues to resolve before we can get there,
e.g. not using the default "big ball of mud" classloading configuration :-)

[starksm64]

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.

Right. So I am going to change APPLICATION_CLUSTERED to APPLICATION_TRANSIENT and you can use that for the hasingleton scanner.