JBossDeveloper

The scopes/annotations still need to be defined.
I have no idea what they should look like without delving deeper into use cases.

For our tests you could just create the simple ones so you can do something like:

<!-- Deploy shared metadata -->
<policy>
 <scope>@org.jboss.metadata.spi.annotations.JVMScope</scope>
 <binding>...</binding>
</policy>

<!-- Deploy bean level metadata -->
<policy>
 <scope>@org.jboss.metadata.spi.annotations.InstanceScope("BeanName")</scope>
 <binding>...</binding>
</policy>

To make this work for generic scopes, the annotation will need to be meta-annotated
so we know what it means:

public interface ScopeFactory<T extends Annotation>
{
 ScopeKey create(T annotation);
}

public class InstanceScopeFactory<InstanceScope annotation>
{
 public ScopeKey create(InstanceScope annotation)
 {
 return new ScopeKey(CommonLevels.INSTANCE, annotation.value());
 }
}

@ScopeFactory(class=InstanceScopeFactory.class)
public @interface InstanceScope
{
 /** The bean name */
 String value();
}

You can also provide something that doesn't use annotations for common
simple cases,
e.g.

 <scope level="Instance" qualifier="BeanName"/>

In general, your are going to have something more qualified like:

 <scope level="Application" qualifier="MyDeployment.ear"/>
 <scope level="Deployment" qualifier="MyWeb.war"/>
 <scope level="Instance" qualifier="MyServlet"/>

This is all very speculative until we have gone through the use cases
for how this will be used in real life.

 

"alesj" wrote:

What about in the case when Scope annotation doesn't have a factory determining annotation? Ok, since we are the ones that will be providing these scope annotations, we can throw an exception or should presume some default ScopeKey?

You can certainly avoid the factory for known types from the CommonLevel
once the annotation format is agreed.

If the annotation is not meta-annotated you could assume

level=annotation.getClass().getSimpleName();
qualifier=annotation.value();

But this would need to use reflection (yuck! :-).

 

"alesj" wrote:

You probably meant this code:

ScopeKey scope = from the <scope/>;

You need to combine all the scopes.

In fact, the stuff we talked about before is probably better as a Scope rather than a ScopeKey.

You would then create the ScopeKey from all the scopes

 /**
 * Create a new ScopeKey.
 *
 * @param scopes the scopes
 */
 public ScopeKey(Collection<Scope> scopes)
 {

 

"alesj" wrote:

So this means that Bindings should be deployed against new (Scoped)Kernel, not against the underlying.

The bindings are done against the MutableMetaData which is a shared
repository. It already has a notion of scope.

The scoped kernel is a different feature.
That is where you would do something like:

<deployment>
 <annotation>@org.jboss.metadata.plugins.scope.DeploymentScope</annotation>
</deployment>

This would:

Stages (1) and (2) are optional if they already exist

1) Create a MutableMetaData for this scope
2) Create a kernel (or maybe just a kernel controller) for this scope and add it to
the MutableMetaData, the kernel's parent would come from any kernel in the
parent's scope or the default kernel if there is no such thing
3) Deploy the bean(s) into that scoped kernel

You should also support things like:

<deployment>
 <bean>
 <annotation>@org.jboss.metadata.plugins.scope.SubsystemScope("jca")</annotation>
 </bean>
</deployment>

In both cases, you pick out all the "scope" annotations.

Iincluding those that are on the bean class if they are not overridden.
The MetaData (read only context) already has the processing to do this
since each instance scope has a parent scope of the class.

For ease of use (less boiler plate) I've also previously suggested or would suggest:

1) The qualifier for @org.jboss.metadata.plugins.scope.DeploymentScope
should come from KernelDeployment.getName() if the user doesn't specify it.
2) Support simple scoping definitions directly in the xml, e.g.

<deployment scoped="true">

The latter being the same as just adding the DeploymentScope annotation
to the deployment.

NOTE: We don't have any processing at the moment that lets you add
annotations at the deployment level. This is obviously a useful feature
where you want all beans to have the same annotations, like the scope.

 

"alesj" wrote:

"adrian@jboss.org" wrote:

The bindings are done against the MutableMetaData which is a shared
repository. It already has a notion of scope.

What's the usage of the bindings if we have the underlying architecture - with whole deployment already being deployed in scope.

I don't understand this question.

"adrian@jboss.org" wrote:

In both cases, you pick out all the "scope" annotations.

How do I tell them apart - via @ScopeFactoryLookup?

A meta-annotation is a way to do this since annotations don't support
inheritance. You can also hardwire the common/known annotations.

 

"alesj" wrote:

"adrian@jboss.org" wrote:

Stages (1) and (2) are optional if they already exist

1) Create a MutableMetaData for this scope
2) Create a kernel (or maybe just a kernel controller) for this scope and add it to
the MutableMetaData, the kernel's parent would come from any kernel in the
parent's scope or the default kernel if there is no such thing
3) Deploy the bean(s) into that scoped kernel

Where to plug-in these stages?
Since I need to know bean annotations before I deploy bean into the controller (BeanMetaDataDeployer, AbstractKernelDeployer), but currently they are realized in DescribeAction.
Or should I do my own scope-annotation lookup just before I do the deployment into controller?

I think that what we should really do is have a notion of ScopeKey in the
BeanMetaData[Factory] and the ControllerContext.
I've avoided adding it so far until we've sorted out the usecases for the
metadata, but it is definitely something that should be there.
If it is not specified, you would just use the deault rules from the
annotations or failing that

ScopeKey.DEFAULT_SCOPE

I think we really need to discuss the use cases for how the metadata works.

I don't have a problem with you prototyping something so we have
something to "play with'. But the only way we are really going to workout
what the api should look like is by going through examples on
how we expect this feature to be used.

I'll start a seperate thread on one example I was thinking about over the weekend.

 

"adrian@jboss.org" wrote:

I think that what we should really do is have a notion of ScopeKey in the
BeanMetaData[Factory] and the ControllerContext.

Essentially what I'm saying is what is done now in the DescribeAction
(mostly delegating to the MetaDataRepository to determine default rules)
should be done at (pre-)installation time.

We would essentially implement the default rules in the AbstractBeanMetaData
(so they can be overridden).

The difficulty comes in the notion of the scoped kernel.

Before we can do the install, we need to create the scoped kernel
and for that we need metadata scope to exist so we remember the scope.
(There's also potentially a race condition here with two threads trying
to create the same scope - but that's another story).

I think the solution is for the BeanMetaData to fully describe itself
and then have the install/uninstall into the root kernel do the work
from the description (again mostly delegating the KernelMetaDataRepository).

The difference being that the install/uninstall just "does it" based
on what the BeanMetaData tells it, it doesn't make any policy decisions.

 

"adrian@jboss.org" wrote:

The difference being that the install/uninstall just "does it" based
on what the BeanMetaData tells it, it doesn't make any policy decisions.

Since the parent kernels are going to have to know about the child kernels
anyway, see
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=101320
I don't see a problem with them creating the child kernel when they see
that one is necessary.

This also has the advantage that if you do inside the parent controller's "write lock"
you avoid the race condition mentioned above.