[Design the new POJO MicroContainer] - Re: Scoped beans deployment
by adrian@jboss.org
Yes, but a missing DESCRIBED dependency should not stop the context
moving to the new PRE_INSTALL state.
By default most dependencies are required at INSTANTIATED,
see AbstractKernelControllerContext
| protected abstract class AbstractMetaDataVistor implements MetaDataVisitor, PrivilegedAction<Object>
| {
| /**
| * The current context for when the dependencies are required
| */
| protected ControllerState contextState = ControllerState.INSTANTIATED;
|
Parts of the tree override the "whenRequired" to be later,
e.g. property injections are required at CONFIGURED.
The only problematic one I can see is the ClassLoader,
which is currently required at DESCRIBED.
This should be moved to the PRE_INSTALLED since we need the classloader
to get the class, to get the annotations.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016372#4016372
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4016372
19 years, 1 month
[Design the new POJO MicroContainer] - Re: Scoped beans deployment
by alesj
"adrian(a)jboss.org" wrote : But isn't that something you already started to workaround with the
| initial and describe visit?
|
| i.e. The visitor is already in two stages.
|
| It should simply be a case of making sure that the visited metadata uses
| the correct controller.
|
| In fact, the problem is where the visitee does
|
| | KernelControllerContext controllerContext = visitor.getControllerContext();
| | // Remember in local state
| | controller = (KernelController) controllerContext.getController();
| |
| or similar.
|
| Instead, it should just remember the ControllerContext and ask
| for the controller from the context when it needs it.
| i.e. the second line should be done lazily
Ok, Controller should be set (lazily) in the 2nd (describe) phase - where possible (and I think it is possible in all cases).
But that is not the problem I have in mind.
e.g. When we add DependencyItem in DependsMetaData (or DependencyValueMetaData, ...), this context waits for this to be resolved till some other bean supplies this dependency - but it does this via AbstractController.resolveContexts which puts itself as a parameter to DependencyInfo.resolveDependencies. So we are 'asking' the 'describe state' Controller to resolve some bean that will actually be installed in child Controller.
| public boolean resolve(Controller controller)
| {
| boolean previous = resolved;
| ControllerContext context;
|
| if (dependentState == null)
| context = controller.getInstalledContext(iDependOn);
| else
| {
| context = controller.getContext(iDependOn, dependentState);
| if (context == null)
| {
| if (ControllerState.INSTALLED.equals(dependentState))
| context = controller.getInstalledContext(iDependOn);
| }
| }
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016357#4016357
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4016357
19 years, 1 month
[Design the new POJO MicroContainer] - Re: DependencyInfo remove items
by adrian@jboss.org
For the removeIDependOn() it is because the DescribeAction is buggy :-)
It should be removing the dependency items in uninstall()
that it added in install() from the AOP dependencies.
Of course, nobody noticed because all that would happen is that
the dependencies would be resolved multiple times if the context is re-installed.
Besides that case, there are no other occurances of dynamic dependencies
that I can think of?
i.e. Where a dependency is added that should be removed before the
context is uninstalled from the controller.
The other possible example would be that in principle a user can
create their own ControllerContext and reuse the AbstractDependencyInfo.
That may want to abitrarily add/remove dependencies?
e.g. The JMX controller does the first part (creates a ServiceControllerContext)
but it has no requirement to remove dependencies. :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016348#4016348
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4016348
19 years, 1 month
[Design of JBoss jBPM] - Re: various questions
by tom.baeyens@jboss.com
"kukeltje" wrote : I think that an externally generated businesskey on the process level, other than in a standard process variable, makes sense for jpdl as well, but that is my opinon. You should be able to pass it when starting a process.
|
i don't yet see the use cases.
first of all. technically, i think we could most easily implement a business key as a specially identified variable. (i don't think an extra join in the query is a big problem. even if that would be the case, it boils down to a performance issue and not a conceptual one)
second, while i can see the value of business keys for a number of use cases. making it mandatory is something else. i still see many use cases that would not require a business key. would they need to start inventing one ? that is still not clear to me. and just posing the invention of business key onto the user is unacceptable to me as i think this will increase the learning curve for a lot of people that don't need this feature.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016326#4016326
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4016326
19 years, 1 month
[Design of JBoss jBPM] - Re: various questions
by tom.baeyens@jboss.com
"estaub" wrote : Hibernate/JPA can't solve the identity problem when the requirement is to apply a specific externally-generated identifier to the process and be able to reference the process by it later. This is a frequent business requirement.
|
IMO, HB/JPA could do a better job of supporting the object identity versus object equality problem.
"estaub" wrote : In BPEL, all of the "Correlation Set" support addresses this - far more comprehensively than you/we perhaps have any need for.
correlation is related. but i don't see how this justifies the need for business keys. it could only show the opposite. namely that a single business key is not sufficient. to support correlation in bpel, we would need a set of correlations (set of set of primitive values) for each process instance.
regards, tom.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016322#4016322
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4016322
19 years, 1 month