February 2007 - jboss-dev-forums - Jboss List Archives

[Design the new POJO MicroContainer] - Re: Scoped beans deployment

by adrian＠jboss.org

NOTE: If you look at AbstractDependencyInfo, you'll see that it only invokes the dependency items for the next state that it is interested in. | public boolean resolveDependencies(Controller controller, ControllerState state) | { | boolean resolved = true; | if (unresolved.isEmpty() == false) | { | for (Iterator i = unresolved.iterator(); i.hasNext();) | { | DependencyItem item = (DependencyItem) i.next(); | | // HERE, only try to resolve the next state, not all dependencies | | if (state.equals(item.getWhenRequired()) && item.resolve(controller) == false) | { | resolved = false; | break; | } | } | } | return resolved; | } | So when we ask is "PRE_INSTALL" resolved, it isn't going to look at later dependencies. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016377#4016377 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4016377

19 years, 1 month

1
0
0 / 0

[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

1
0
0 / 0

[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

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: DependencyInfo remove items

by adrian＠jboss.org

For the dependsOnMe is being maintained properly. Again, this probably doesn't matter, since it is only used when you remove a context. See ControllerContext.uninstall() IIRC the reason I don't maintain it is because the only place to do so could be too early. i.e. in the DependencyItem.resolve() implementations. If we removed it at that point, we have only just determined that the dependency is no longer resolved, the controller hasn't had chance to act on that information yet and so the uninstall() may not work correctly? It is certainly something that we should look at tidying up. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016353#4016353 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4016353

19 years, 1 month

1
0
0 / 0

[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

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Scoped beans deployment

by adrian＠jboss.org

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 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016339#4016339 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4016339

19 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: initial nodes

by tom.baeyens＠jboss.com

"kukeltje" wrote : COOOOOOOOOOL..... sorry it took so long :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016328#4016328 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4016328

19 years, 1 month

1
0
0 / 0

[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

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Need to have central wiki page where all different JBM d

by timfox

We should also include instructions for people wanting to use EJB3 for example from the same standalone client that uses JMS. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4016325#4016325 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4016325

19 years, 1 month

1
0
0 / 0

[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

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2007