[adrian.brock]

"alesj" wrote:

1) ScopingOverridingTestCase

This is failing because of the problem I suspected when taling to Kabir
about the issue that led to finding JBMICROCONT-330
i.e. a scoped controller context is sharing the same metadata
as one that should not be scoped.

How did this ever worked? :-)
Or what changed that 'broke' this?

It only worked because the second bean to be deployed overwrote the first's bean
instance scope. That's what I fixed with JBMICROCONT-330

[alesj]

You need to change the name of the INSTANCE scope for scoped beans
to include something that identifies the scoped controller, e.g.

new ScopeKey(CommonLevels.INSTANCE, scopedController.getScopeID() + "/" name.toString());

The scoped controller is only known in PreInstallAction,
where ScopeInfo is created when ControllerContext is created.

And in order to get the annotations that actually define which scoped controller the bean belongs to,
you already need the INSTANCE value - see PreInstallAction.
Almost like chicken-n-egg. ;-)

[adrian.brock]

"alesj" wrote:

And in order to get the annotations that actually define which scoped controller the bean belongs to,
you already need the INSTANCE value - see PreInstallAction.
Almost like chicken-n-egg. ;-)

There must be a way where you can "rename"/"rework" the instance scope
when you move the context to the scoped controller?

Actually the best way would be if we had the GUID for each
controllerContext/deployment component, but absent that you'll have to hack it.

[alesj]

There must be a way where you can "rename"/"rework" the instance scope
when you move the context to the scoped controller?

Sure, would probably take some hassle, but could be done.
But the issue is still here - the current ScopedOverride test, where I changed the order:
e.g. 'simple' org.jboss.foobar.Simple bean in top controller.
Then I wanna deploy scoped 'simple' org.jboss.foobar.Simple bean.
Woudln't that pick up metadata from the first one?

Actually the best way would be if we had the GUID for each
controllerContext/deployment component, but absent that you'll have to hack it.

How would you know what that GUID will be, to do this:

You also need to be able to do this ahead of time in the deployers
so people can populate the instance scope before controller context exists.

and you deploy that bean via xml - most of the actions are transparent.

We're back to the same problem:
How to map some ID from deployers (we set some predetermined metadata),
to a bean's ScopeInfo, where our only info is className and bean's name,
no idea if the bean is gonna be scoped.

[adrian.brock]

"alesj" wrote:

We're back to the same problem:
How to map some ID from deployers (we set some predetermined metadata),
to a bean's ScopeInfo, where our only info is className and bean's name,
no idea if the bean is gonna be scoped.

The idea is that every Component/ControllerContext has a GUID.
When you create the ControllerContext from the Component, you copy the GUID.

The INSTANCE scope would then just be INSTANCE/GUID rather than
INSTANCE/BeanName.

[alesj]

When you create the ControllerContext from the Component,
you copy the GUID.

OK, makes sense.

But still makes it hard to create some predetermined INSTANCE scope metadata,
since it's again, how are gonna know which GUID is the one you actually want from a set of GUIDs from components.
e.g.

<deployment>
 <bean name="simple" class="org.jboss.acme.Simple"/>

 <bean name="simple" class="org.jboss.acme.Simple">
 <annotation>@org.jboss.acme.SomeScopeAnnotation("myscope")</annotation>
 </bean>
</deployment>

And now I want to add some predetermined INSTANCE metadata to 2nd bean.
How am I gonna know which GUID is assigned to its component?
Unless I do some detailed lookup, e.g. Component --> BeanMetaData --> annotations --> are they scope annotations ---> ...

And you cannot do any MDR modification before Real deployment phase,
since the components are not there yet - no GUID.

[adrian.brock]

"alesj" wrote:

And you cannot do any MDR modification before Real deployment phase,
since the components are not there yet - no GUID.

Why would you have a deployer adding instance metadata not working
at the component deployment level?

If this really is an issue, then they can override the INSTANCE scope
to be something specific, the controller context will just use what it is told.

But I think you're just making up requirements that don't exist :-)
Except possibly in the tests.

[alesj]

The idea is that every Component/ControllerContext has a GUID.
When you create the ControllerContext from the Component, you copy the GUID.

The INSTANCE scope would then just be INSTANCE/GUID rather than
INSTANCE/BeanName.

This looks like a big change at the last moment.
Should we/I really introduce this into CR1?

If it's only Kabir's AOP that is suffering from this,
there is a simple workaround, as shown in the 'fixed' ScopedOverridingTestCase.