September 2007 - jboss-dev-forums

[Design of Messaging on JBoss (Messaging/JBoss)] - ManagedObject support in next messaging release

by scott.stark＠jboss.org

ManagedObject support in next messaging release One of the issues I have linked to the http://jira.jboss.com/jira/browse/JBAS-4689 1.4.0.GA task is the need for managed object annotations to properly identify the jms destination types. Currently the org.jboss.jms.server.destination.QueueService/TopicService components are coming from the jms release. These need mc management annotations to describe the management interface for jbossas5. For 1.4.0.GA to be usable in jbossas5/4.x, a separate integration layer is needed to isolate the jbossas specific dependencies. JBMESSAGING-1065 was raised as a blocking task for the JBAS integration. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082238#4082238 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082238

18 years, 7 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Deployer order solely based on inputs/outputs now?

by adrian＠jboss.org

"adrian(a)jboss.org" wrote : "bill.burke(a)jboss.com" wrote : Ok, after talking to Ales I think i get it. | | | | There would be: | | | | EJBParserDeployer | | EJBDescribeDeployer | | EJBComponentDeployer | | | | So, if my EJBDescribeDeployer is part of the DESCRIBE stage, it should happen after EVERY DeploymentUnit has gone through Parsing, right? | | This can only work if you add the dependencies to the deployment rather than | the ejb instance. The same way OSGi dependencies work. | I should also point out that with the latest rev of the deployers, the deployment dependencies are implemented on the whole deployment. i.e. adding a dependency on an ejb subdeployment of ear will actually be a dependency for the whole ear. So if the describe deployer adds a dependency saying don't move to the "REAL" stage until java:/DefaultDS is deployed, nothing in the EAR will move to "REAL" until that is done. In that sense, it can't be piecemeal if you have real dependencies on the deployments. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082237#4082237 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082237

18 years, 7 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Deployer order solely based on inputs/outputs now?

by adrian＠jboss.org

"bill.burke(a)jboss.com" wrote : | FYI, my question on DependencyItem is simple. When does it get invoked upon. What triggers it. If i know this information, then I can proceed. I'll answer your question with some psuedo code that describes the MC algorithm :-) | whenSomebodyInstallsANewContext() | { | registerItInNotInstalledState(); | | // Go through all the states from NOT_INSTALLED TO INSTALLED | | for (ControllerState state : allStates) | { | | // Go through all the contexts at the current state | | List<ControllerContext> contexts : getContextsInState(state); | for (ControllerContext context : contexts) | { | List<DependencyItem> items = context.getDependencyInfo().getDependencies(context.getNextState()); | | // See whether the depenencies are resolved | | boolean readyToGoToNextState = true; | for (DependencyItem item : items) | { | if (item.resolve() == false) | readyToGoToNextState = false; | } | | // If they are bump it to the next state | | if (readyToGoToNextState()) | doIt(); | } | } | } | Of course the real implementation is more complicated because of ControllerMode, multithreading, recursion and error handling, but that algorthim is effectively all the MC does. So you can see it will check dependency items for every context that is not in a fully installed state when somebodyinstalls a new context. But only those dependency items that lead to the next state. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082235#4082235 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082235

18 years, 7 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Deployer order solely based on inputs/outputs now?

by alesj

Plus this: | public boolean resolveDependencies(Controller controller, ControllerState state) | { | boolean resolved = true; | if (unresolved.isEmpty() == false) | { | for (DependencyItem item : unresolved) | { | if (state.equals(item.getWhenRequired()) && item.resolve(controller) == false) | { | resolved = false; | break; | } | } | } | return resolved; | } | btw: you can always check the code for more details ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082234#4082234 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082234

18 years, 7 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Deployer order solely based on inputs/outputs now?

by alesj

"bill.burke(a)jboss.com" wrote : What triggers it. If i know this information, then I can proceed. Any addition (e.g. new install) to Controller triggers this: | | Set<ControllerContext> unresolved = contextsByState.get(fromState); | Set<ControllerContext> resolved = resolveContexts(unresolved, toState, trace); | | protected Set<ControllerContext> resolveContexts(Set<ControllerContext> contexts, ControllerState state, boolean trace) | { | HashSet<ControllerContext> result = new HashSet<ControllerContext>(); | | if (contexts.isEmpty() == false) | { | for (ControllerContext ctx : contexts) | { | if (advance(ctx)) | { | DependencyInfo dependencies = ctx.getDependencyInfo(); | if (dependencies.resolveDependencies(this, state)) | result.add(ctx); | } | } | } | | return result; | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082232#4082232 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082232

18 years, 7 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Deployer order solely based on inputs/outputs now?

by bill.burke＠jboss.com

anonymous wrote : EAR subdeployments are always going to piecemeal unless you make | them wait for their dependencies. | If its non-deterministic then nothing is going to work, its just random. | 1. Parsing deployer runs generating metadata for each EJB in the EAR 2. Describe deployer runs adding dependency metadata for each EJB 3. Component deployer runs, creating EJB beans with "real" kernel dependencies based on metadata in step #2. Again, this would be for @EJB and @PC refs that do not have a mapped-name defined. Metadata refs with mapped-name specified don't have the ambiguity that @EJB and @PC might have that don't have mapped-name defined. FYI, my question on DependencyItem is simple. When does it get invoked upon. What triggers it. If i know this information, then I can proceed. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082229#4082229 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082229

18 years, 7 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Deployer order solely based on inputs/outputs now?

by adrian＠jboss.org

"bill.burke(a)jboss.com" wrote : anonymous wrote : he real solution is to create your own DependencyItem implementation | | like I've been telling you to over a year now. | | And I've been telling you that EE injection requirements are not simple... | I know. anonymous wrote : | Are you sure the DependencyItem stuff will work since EJB and PC ref's metadata may be incomplete or even ambiguous? Does a DependencyItem get queried EVERY TIME any arbitrary thing is deployed or when ANY arbitrary thing changes state within the MC? I also worry about a dependency item matching and picking up the wrong reference because an inner deployment scope hasn't been processed/deployed yet. | You can make a DependencyItem do whatever you like, e.g. just delegate to the EJBContainer to do all the work. anonymous wrote : | I don't understand why I have to add the dependencies to the deployment to make this work. The subdeployments of an EAR are not going to be deployed piecemeal. | EAR subdeployments are always going to piecemeal unless you make them wait for their dependencies. If its non-deterministic then nothing is going to work, its just random. anonymous wrote : | Also, we're not going to make configuration more complicated for the user for the edge cases 90% of people don't care about. Meaning, we're not going to require a mapped-name with @EJB or @PersistenceContext refs. i.e. requiring them to specify a mapped-name. | I'm not saying you should. I'm saying you create a dependency that is relevant to what the user requests. If they say mapped-name then that is more specific and should respected over whatever heuristic rules you use otherwise. anonymous wrote : | Where is there documentation on how dependency items work? The Javadoc isn't very helpful ;-) Not done, yet... http://jira.jboss.com/jira/browse/JBMICROCONT-81 Ales has been concentrating on what most people will actually use in the documentation. There's many examples though, e.g. the deployment dependencies I added for OSGi a few weeks ago: http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas?view=rev&revision=64469 Mapping of OSGi requirement to MC dependency (currently only modules and packages are implemented as requirements) http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbossas/projects/microcontaine... View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082223#4082223 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082223

18 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

by bill.burke＠jboss.com

Also, we need the dependency, especially for datasources and JMS references. So we might as well implement a hard dependency. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082222#4082222 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082222

18 years, 7 months

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: KernelRegistryPlugins and dependencies

by bill.burke＠jboss.com

You have to explain to me how DependencyItems work, specifically how it could work with JNDI. As of right now, i don't see how it can. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082221#4082221 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082221

18 years, 7 months

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: Deployer order solely based on inputs/outputs now?

by bill.burke＠jboss.com

anonymous wrote : he real solution is to create your own DependencyItem implementation | like I've been telling you to over a year now. And I've been telling you that EE injection requirements are not simple... Are you sure the DependencyItem stuff will work since EJB and PC ref's metadata may be incomplete or even ambiguous? Does a DependencyItem get queried EVERY TIME any arbitrary thing is deployed or when ANY arbitrary thing changes state within the MC? I also worry about a dependency item matching and picking up the wrong reference because an inner deployment scope hasn't been processed/deployed yet. I don't understand why I have to add the dependencies to the deployment to make this work. The subdeployments of an EAR are not going to be deployed piecemeal. Also, we're not going to make configuration more complicated for the user for the edge cases 90% of people don't care about. Meaning, we're not going to require a mapped-name with @EJB or @PersistenceContext refs. i.e. requiring them to specify a mapped-name. Where is there documentation on how dependency items work? The Javadoc isn't very helpful ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4082220#4082220 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4082220

18 years, 7 months

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 September 2007