EJBTHREE-1167 -- Resolve API leak for @Clustered

[brian.stansberry]

To clarify the problem description from http://jira.jboss.com/jira/browse/EJBTHREE-1167

@Clustered (in the ha-client project) has a reference to org.jboss.ha.client.loadbalance.LoadBalancePolicy (also in the ha-client project). There are no references back to the cluster module in JBoss AS.

As long as @Clustered itself is in ha-client, ClusteredImpl depends on ha-client. So I don't see the benefit of replacing the class with a string.

I suppose if you changed it to a string *and* took the annotation itself back into ejb3, then you get a benefit.

Before going down this road though, we should determine how to handle the aspects module, which also depends on the ha-client project. See http://www.jboss.com/index.html?module=bb&op=viewtopic&t=124773, particularly the last post.

[alrubinger]

You beat me to this before I could ping you on it :)

[e-mail] wrote:
As long as @Clustered itself is in ha-client, ClusteredImpl depends on ha-client. So I don't see the benefit of replacing the class with a string.

And if ClusteredImpl (to be moved to ejb3-impl) depends on ha-client, ejb3-impl will depend on ha-client. I'd like to avoid this.

[e-mail] wrote:
I suppose if you changed it to a string *and* took the annotation itself back into ejb3, then you get a benefit.

Yep. Though a couple months back we determined that @Clustered was not specific to EJB3, so we put it into HA. I'd originally put ClusteredImpl in there as well, but took it back when you'd asked.

So I see a couple solutions:

1) Move @Clustered to ejb3-ext-api, ClusteredImpl to ejb3-impl, and make Strings out of the load balance configuration. This makes @Clustered EJB3-specific.

2) Put ClusteredImpl back into HA somewhere, with dependency on ha-client to fulfill the reference to LoadBalancePolicy. EJB3 is the only project using this class, but then there'd be no API leak.

[e-mail] wrote:
Before going down this road though, we should determine how to handle the aspects module, which also depends on the ha-client project.

That necessary, or your preference? :)

Thx.

S,
ALR

[brian.stansberry]

You beat me to this before I could ping you on it :)

By luck the JIRA message was prominent in my morning e-mail pile, so you got a response before the deluge buried me. :-)

Yep. Though a couple months back we determined that @Clustered was not specific to EJB3, so we put it into HA. I'd originally put ClusteredImpl in there as well, but took it back when you'd asked.

Yeah, but then Adrian kindly discovered EJBTHREE-1109. ;-) Which led to EJBTHREE-1110 (add a home load balance policy attribute), and with that the annotation is pretty EJB3 specific.

So, I don't mind the annotation moving into ejb3-ext-api.

[e-mail] wrote:
Before going down this road though, we should determine how to handle the aspects module, which also depends on the ha-client project.

That necessary, or your preference? :)

Hadn't drunk enough coffee; wasn't thinking clearly. If the goal is just to have no dependency from ejb3-ext-api and ejb3-impl to ha-client, it's not necessary. The aspects module classes have a dependency on ha-client, and that would "leak" back into ejb3-core. But ejb3-core is probably going to have the ha-client dependency anyway, via the clustered proxies.

BTW, the above statement is based on my very vague understanding of the purpose of ejb3-impl vs. ejb3-core. If what I said makes no sense, please tell me.

[alrubinger]

So, I don't mind the annotation moving into ejb3-ext-api.

Sweet. I'll do that, then, and resolve the dependencies on LoadBalancePolicy via a String-based configuration.

If the goal is just to have no dependency from ejb3-ext-api and ejb3-impl to ha-client, it's not necessary.

BTW, the above statement is based on my very vague understanding of the purpose of ejb3-impl vs. ejb3-core. If what I said makes no sense, please tell me.

Nope, that's all in line. The purpose of these projects is also being defined by us as we go... :)

ejb3-ext-api: EJB3 Bean Provider API of JBoss-specific extensions
ejb3-impl: Implementations (internals) conforming to ext-api
ejb3-core: Currently under restructuring; the projectized view of the current AS EJB3 Module. Internals without an API; glue that ties together the other components (cache, pool, etc).

Only pending issue: If I steal out @Clustered from ha-client now and commit, that'll go to the next snapshot and not affect the release you'd made for Beta3, right?

S,
ALR

[brian.stansberry]

Right; will not be a problem. The ha-client 1.0.0.BETA1 release has its own tag. If you changed ha-client trunk and did a maven deploy, it would create a 1.0.0.BETA2-SNAPSHOT.

[alrubinger]

Pleasure doing business with you, please come again.

S,
ALR