-
1. Re: Install Items
alesj Apr 16, 2007 9:36 AM (in response to adrian.brock)Why should InstallItem be referenced by DependencyInfo?
I need to register a 'callback / install' item directly into the controller - holding the information of requested class, cardinality, target context, target method/property.
Since with Controller.resolveContexts() I never iterate over already installed context's.
And even if I did, I should only iterate over those who actually hold any install item. -
2. Re: Install Items
adrian.brock Apr 18, 2007 5:43 AM (in response to adrian.brock)I don't understand any of your comment. e.g.
"alesj" wrote:
Why should InstallItem be referenced by DependencyInfo?
Because that is where cross context dependency info is stored
and where the real implementation of the dependency resolution is done.
I need to register a 'callback / install' item directly into the controller - holding the information of requested class, cardinality, target context, target method/property.
The only thing registered directly in the controller are the contexts.
These have DependencyInfo, i.e. what is required before the context can
change state.
Since with Controller.resolveContexts() I never iterate over already installed context's.
And even if I did, I should only iterate over those who actually hold any install item.
What does that have to do with it? There are two points of integration.
1) I add something that wants to pickup all previously deployed implementations
of an interface.
2) I install something that implements the interface wanted by something (1)
type (1)
Neither is directly related to resolveContexts().
The only part of the resolution process is the cardinality. And that is
only indirectly in that there should be a "DependencyItem implementation"
that says the context is not resolved for this state unless there N other
objects implementing the interface.
The "N" could be zero meaning it is always resolved. -
3. Re: Install Items
alesj Apr 18, 2007 6:03 AM (in response to adrian.brock)"adrian@jboss.org" wrote:
I don't understand any of your comment. e.g.
Yes, I expected this. :-)
Let me try to put it better.
I don't see any other place to hold the information about callback - e.g. (2) in JBMICROCONT-165 - than the KernelController. I need something like Class --> CallbackItems.
Since when a new bean is instantiated - its classes, interfaces are resolved - I don't want to go over all already installed beans and 'ask' them if they need this new bean.
I have already hacked something in this direction, I can put it in after I have tests done.
Or how/where do you see the point of integration of this Class --> CallbackItems mapping? -
4. Re: Install Items
adrian.brock Apr 18, 2007 6:37 AM (in response to adrian.brock)No. The whole point of making the InstallItem seperate on the DependencyInfo
is that it will hold just that callback information.
Internally, the controller will pull out that information and index it by interface
(in a similar way to the @Inject was done).
It will pull out that information at the "required state" specified on the InstallItem
(default INSTALLED).
It is then just a case of iterating over all the callbacks
by looking up that index as new contexts reach the relevant state.
NOTE: There are two states in the above.
1) At what state we inject into the context
2) At what state the injectee must be before we add it -
5. Re: Install Items
alesj Apr 18, 2007 7:32 AM (in response to adrian.brock)Where to put such code:
/** * Add callback context. * * @param name the depend on name * @param context context interested in name */ void addCallbackContext(Object name, ControllerContext context); /** * Remove callback context. * * @param name the depend on name * @param context context interested in name */ void removeCallbackContext(Object name, ControllerContext context); /** * Get interested contexts. * * @param name dependent name * @return set of contexts interested in name or null if none such exists */ Set<ControllerContext> getCallbackContexts(Object name);
Best place would be Controller, but this is too specific for state machine.
Should I create a middle interface, between Controller and KernelController? -
6. Re: Install Items
adrian.brock Apr 18, 2007 7:54 AM (in response to adrian.brock)You still don't understand.
The callback is a generic thing.
It's also an implementation detail handled internally by the controller,
so you don't need anything on the controller itself.
e.g. something likepublic interface InstallItem<T> { ControllerState whenRequired(); ControllerState requiredState(); int getCardinality(); Class<T> getItemType(); } public interface SingleInstallItem<T> extends InstallItem<T> { add(T item); remove(T item); } public interface CollectionInstallItem<T> extends InstallItem<T> { set(Collection<? extends T> items); }
And then in the controller (pseudo code):protected void install(ControllerContext context, ControllerState toState) { // do it (what it does now) Collection<InstallItem> installs = context.getDependencyInfo().getInstallItems(); if (installs != null && installs.isEmpty() == false) { for (InstallItem install : installs) { if (install.getWhenRequired().equals(toState) { addToIndex(install.getItemItype(), install); // also install what already exists } } } Collection<Class<?> implements = getClassesImplemented(context.getTarget()); if (implements != null && implements.isEmpty() == false) { for (Class implement : implements) { Set<InstallItem> installs = getFromIndex(implement); // Do the installs if we are at the required state { // eventually leading to something like InstallItem install = // from installs if (toState.equals(install.getRequiredState)) install.add(context.getTarget()); } } } }
-
7. Re: Install Items
adrian.brock Apr 18, 2007 7:59 AM (in response to adrian.brock)Well actually you've got to hook up the intallation target as well in there somewhere
so you've either got to havepublic interface InstallItem { // ... setTarget(Object object) } or public interface SingleInstallItem { add(Object target, Object item); }
I think I prefer the second method since it is more stateless for the user
(less error prone and less likely to leak)
But that means the internal index of install items must also remember which context
owns the install item so it can retrieve the target from the context. -
8. Re: Install Items
alesj Apr 19, 2007 4:48 PM (in response to adrian.brock)Would this work:
MethodInfo mi = Configurator.findMethodInfo(getClassInfo(context), methodName, new String[]{signature}); TypeInfo info = mi.getParameterTypes()[0]; Class parameterType = info.getType(); if (Collection.class.isAssignableFrom(parameterType)) { if (info instanceof ParameterizedClassInfo) { ParameterizedClassInfo pci = (ParameterizedClassInfo)info; Class clazz = pci.getActualTypeArguments()[0].getType(); callback = CollectionCallbackItemFactory.createCollectionCallbackItem(parameterType, clazz, whenRequired, dependentState, context, methodName); } else throw new IllegalArgumentException("Unable to determine collection element class type: " + this); }
Or how to get element class type?
Is this (the only) way?
- http://www.jboss.org/index.html?module=bb&op=viewtopic&t=88613&postdays=0&postorder=asc&start=30 -
9. Re: Install Items
alesj Apr 19, 2007 6:11 PM (in response to adrian.brock)Changed previous post from ParameterizedArrayInfo to ParameterizedClassInfo. ;-)
-
10. Re: Install Items
adrian.brock Apr 20, 2007 7:41 AM (in response to adrian.brock)Without seeing the context its hard to say. :-)
This is the way I have it working in some uncommitted code for the
managed object stuff.if (typeInfo.isCollection()) return generateCollection((ClassInfo) typeInfo); /** * Generate a collection metatype * * @param typeInfo the type info * @return the metatype */ public ArrayMetaType generateCollection(ClassInfo typeInfo) { TypeInfo elementType = objectTypeInfo; TypeInfo[] types = typeInfo.getActualTypeArguments(); if (types != null) elementType = types[0]; MetaType elementMetaType = resolve(elementType); return new ArrayMetaType(1, elementMetaType); }
Of course in that code, I fallback to java.lang.Object when it is not Generic. :-)