This content has been marked as final.
Show 22 replies
-
1. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
adrian.brock Aug 8, 2008 11:07 AM (in response to adrian.brock)I also fixed up the api where it was assuming MemoryMetaDataLoader
when populating the annotations from the BeanMetaData.
It now uses the more correct MutableMetaDataLoader and ComponentMetaDataLoader
where relevant. -
2. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
adrian.brock Aug 8, 2008 11:08 AM (in response to adrian.brock)JIRA issues:
ScopedController MDR
https://jira.jboss.org/jira/browse/JBMICROCONT-333
Tidying up BeanMetaData annotations
https://jira.jboss.org/jira/browse/JBMICROCONT-334
Fail the build when tests fail
https://jira.jboss.org/jira/browse/JBMICROCONT-335 -
3. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
alesj Aug 8, 2008 11:41 AM (in response to adrian.brock)"adrian@jboss.org" 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.
This is passing for me in IDE.
Due to luck/random behavior? -
4. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
alesj Aug 8, 2008 11:50 AM (in response to adrian.brock)This move
projects/microcontainer/trunk/kernel/src/main/org/jboss/kernel/plugins/metadata/basic/BasicKernelMetaDataRepository.java =================================================================== --- projects/microcontainer/trunk/kernel/src/main/org/jboss/kernel/plugins/metadata/basic/BasicKernelMetaDataRepository.java 2008-08-08 14:37:38 UTC (rev 76832) +++ projects/microcontainer/trunk/kernel/src/main/org/jboss/kernel/plugins/metadata/basic/BasicKernelMetaDataRepository.java 2008-08-08 15:11:04 UTC (rev 76833) @@ -21,20 +21,13 @@ */ ... - - /** - * Create metadata context. - * - * @param retrievals the retrievals - * @return new metadata context instance - */ - protected MetaDataContext createMetaDataContext(List<MetaDataRetrieval> retrievals) - { - return new AbstractMetaDataContext(null, retrievals); - } }
made the following classes:
- CachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
- PolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
- LRUPolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
- TimedPolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
useless, since they don't serve the caching override function anymore.
What's the best way to port this?
Overriding this in some ControllerContext impl doesn't seem like a good fit. -
5. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
alesj Aug 8, 2008 11:56 AM (in response to adrian.brock)"alesj" wrote:
Overriding this in some ControllerContext impl doesn't seem like a good fit.
e.g.protected void initKernelScopeInfo() { String className = null; Object target = getTarget(); if (target != null) className = target.getClass().getName(); BeanMetaData bmd = getBeanMetaData(); if (bmd != null) { String bean = bmd.getBean(); if (bean != null) className = bean; } setScopeInfo(createScopeInfo(className, bmd)); } protected ScopeInfo createScopeInfo(String className, BeanMetaData bmd) { return new KernelScopeInfo(getName(), className, bmd); }
Where you could push in your ControllerContext impl,
which would override this createScopeInfo method,
providing ScopeInfo that again has overridden createMetaDataContext method.
Yuck. :-) -
6. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
alesj Aug 8, 2008 12:04 PM (in response to adrian.brock)"alesj" wrote:
This is passing for me in IDE.
Due to luck/random behavior?
OK, got the failure:*** DEPLOYMENTS IN ERROR: Name -> Error simple -> java.lang.IllegalStateException: Unable to register context name=simple state=Not Installed, name already exists: simple
Should be able to fix it now. ;-) -
7. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
adrian.brock Aug 8, 2008 12:51 PM (in response to adrian.brock)"alesj" wrote:
This move
- protected MetaDataContext createMetaDataContext(List<MetaDataRetrieval> retrievals)
made the following classes:
- CachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
- PolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
- LRUPolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
- TimedPolicyCachingBasicKernelMetaDataRepository (org.jboss.kernel.plugins.metadata.basic)
useless, since they don't serve the caching override function anymore.
You should add @Override so it doesn't compile if somebody refactors
the callback.
Why didn't I see any failing tests? I must be blind?
What's the best way to port this?
Overriding this in some ControllerContext impl doesn't seem like a good fit.
I don't think there is a one best way. The simplest would be to allow
a setMetaDataContextFactory() on the ScopeInfo, it could be set
by the BasicKernelMDR if you want.
If you wanted to be "clever", you could make it a piece of metadata itself. :-)
i.e. which MetaDataContextFactory to use by looking through the retrievals
before you construct it. That would allow application and system wide construction,
but how it gets populated is a different question.
NOTE: The deployers also do this, see DefaultScopeBuilder,
although there you can override it by adding a ScopeBuilder attachment
to your deployment. -
8. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
adrian.brock Aug 8, 2008 1:04 PM (in response to adrian.brock)"adrian@jboss.org" wrote:
What's the best way to port this?
Overriding this in some ControllerContext impl doesn't seem like a good fit.
A simple way to make it backwards compatible would be to make KernelScopeInfo
delegate back to the BasicKernelMDR.
i.e. change AbstractScopeInfo::createMetaDataContext to pass in the ControllerContext
then in KernelScopeInfo do
context -> controller -> kernel -> BasicKernelMDR::createMetaDataContext
Phew! :-) -
9. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
adrian.brock Aug 8, 2008 1:16 PM (in response to adrian.brock)"adrian@jboss.org" wrote:
"adrian@jboss.org" wrote:
What's the best way to port this?
Overriding this in some ControllerContext impl doesn't seem like a good fit.
A simple way to make it backwards compatible would be to make KernelScopeInfo
delegate back to the BasicKernelMDR.
i.e. change AbstractScopeInfo::createMetaDataContext to pass in the ControllerContext
then in KernelScopeInfo do
context -> controller -> kernel -> BasicKernelMDR::createMetaDataContext
Phew! :-)
I've done that boss. ;-) -
10. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
alesj Aug 8, 2008 3:10 PM (in response to adrian.brock)"adrian@jboss.org" wrote:
I've done that boss. ;-)
Nice work, my apprentice. :-)
I only added a small change,
by the API in AbstractScopeInfo::initMetaDataRetrieval,
it's enough to get MetaDataRetrieval, no need for full MetaDataContext.
So, I've changed the methods involved
to return/use just MetaDataRetrieval.
The actual impl will still be our AbstractMetaDataContext,
but I'm always in favor for minimal interface when applicable. -
11. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
emuckenhuber Aug 8, 2008 5:18 PM (in response to adrian.brock)This is really Adrian...
With reference to your apprentice, in Yoda speak:
interface BasicKernelMDR isn't, therefore bloat it is not :-) -
12. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
alesj Aug 11, 2008 7:14 AM (in response to adrian.brock)"adrian@jboss.org" 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?
I remember adding WORK scope to handle this duplicate issue.
Looking at the code, I don't see how that helped,
since it's the other two scopes that are 'interesting'; CLASS and INSTANCE,
which were always the same.
I don't see a good way to solve this,
since although scoped, beans should still share the same metadata,
if the key matches, e.g. CLASS scope on the same class.
Perhaps we should change what value we keep at INSTANCE scope.
e.g. the stuff we already discussed, adding ID to ControllerContext,
which is unique, and pass that as INSTANCE value. -
13. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
alesj Aug 11, 2008 7:24 AM (in response to adrian.brock)"alesj" wrote:
Perhaps we should change what value we keep at INSTANCE scope.
e.g. the stuff we already discussed, adding ID to ControllerContext,
which is unique, and pass that as INSTANCE value.
Changing INSTANCE value toscopeKey.addScope(CommonLevels.INSTANCE, name.toString() + hashCode()); if (className != null) scopeKey.addScope(CommonLevels.CLASS, className); setScope(scopeKey); setMutableScope(new ScopeKey(CommonLevels.INSTANCE, name.toString() + hashCode()));
Only breaks tests that explicitly set MetaData to repository via bean name.
All other tests pass.
Perhaps completely random/unique INSTANCE value isn't good solution,
since then you cannot do what we do in MutableMetaDataTestCase,
setting predetermined metadata to an instance.
But then again, getting some ID in advance, applying predetermined metadata,
and the somehow passing this ID to ControllerContext,
is again the same problem as we already have - how to uniquely map ID to class and bean name. -
14. Re: JBMICROCONT-330 - Preconfigured MDR and scopes
adrian.brock Aug 11, 2008 9:31 AM (in response to adrian.brock)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());
It should be something predictable - not hashCode().
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.