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

[Deployers on JBoss (Deployers/JBoss)] - Re: EJBRegistrationDeployer causes loop!?

by adrian＠jboss.org

"wolfc" wrote : On one machine (and only on that machine) the EJBRegistrationDeployer won't come up. The EJBRegistrationDeployer doesn't take any inputs, so how can it cause a loop? | 2007-07-03 16:01:59,825 WARN | | | | ... | | | | org.jboss.deployment.security.SecurityDeployer(a)d9b071{inputs=[org.jboss.metadata.BeanMetaData, org.jboss.metadata.ApplicationMetaData, org.jboss.deployment.security.ignoreMe, org.jboss.metadata.WebMetaData] outputs=[jboss.jacc]} | | | | ... | | | | org.jboss.ejb3.deployers.EJBRegistrationDeployer@1d6bff7{inputs=[] outputs=[org.jboss.deployment.security.ignoreMe, org.jboss.ejb3.Ejb3Deployment]} | | } | | | | It's claiming a loop because after the sort the "ignoreMe" that it outputs | is an input for an earlier deployer. | | The problem is because the sort is too simple. Its only looking at neighbours | so it never compares the EJBRegistrationDeployer with the SecurityDeployer | because the EJBDeployer is inbetween and they are in a sorted state relative to that. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4060006#4060006 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4060006

19 years

1
0
0 / 0

[Design of JBoss jBPM] - Re: semantic element creation

by koen.aers＠jboss.com

Hi Matthew, I opt for the semantic element constructor. This guy is the master, the xml and notation element are nothing but observers of this master. The initialize in the xml adapter is used to make sure the values of the different attributes on the model are being set on the xml, so you have to implement this initialization step as well. The getDefaultValue() in the adapter serves only to remove attributes in the xml that have their default value. e.g. if the default value of an attribute is 'abc', specifying this in the getDefaultValue() method will make sure that the attribute disappears from the xml if the model has the value 'abc' for this particular property. Regards, Koen View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059998#4059998 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059998

19 years

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - EJBRegistrationDeployer causes loop!?

by wolfc

On one machine (and only on that machine) the EJBRegistrationDeployer won't come up. The EJBRegistrationDeployer doesn't take any inputs, so how can it cause a loop? 2007-07-03 16:01:59,825 WARN [org.jboss.kernel.plugins.dependency.AbstractKernelController] Broken callback: ClassSingleCallbackItem@dfcb47{name=interface org.jboss.deployers.spi.deployer.Deployer whenRequired=ControllerState@850e8c{Configured} dependentState=ControllerState@101ac1c{Installed} owner=AbstractKernelControllerContext@1f8bd0d{ metadata=AbstractBeanMetaData@ca9a2d{name=Deployers bean=org.jboss.deployers.plugins.deployers.DeployersImpl properties= constructor=AbstractConstructorMetaData@502819{parameters=[null]} autowireCandidate=true installCallbacks=[method=addDeployer] uninstallCallbacks=[method=removeDeployer]}name=Deployers target=org.jboss.deployers.plugins.deployers.DeployersImpl@1d50fd2 state=Installed depends=AbstractDependencyInfo@15004dd{idependOn=[AbstractDependencyItem@6f6068{name=Deployers dependsOn=jboss.kernel:service=KernelController whenRequired=Instantiated dependentState=Installed resolved=true}] unresolved=[AbstractDependencyItem@6f6068{name=Deployers dependsOn=jboss.kernel:service=KernelController whenRequired=Instantiated dependentState=Installed resolved=true}]}} method=addDeployer signature=org.jboss.deployers.spi.deployer.Deployer} | java.lang.IllegalStateException: Cannot add org.jboss.ejb3.deployers.EJBRegistrationDeployer@1d6bff7 it will cause a loop | org.jboss.deployers.vfs.deployer.kernel.KernelDeploymentDeployer(a)eafb71{inputs=[org.jboss.beans.metadata.spi.BeanMetaData, org.jboss.kernel.spi.deployment.KernelDeployment] outputs=[org.jboss.beans.metadata.spi.BeanMetaData]} | org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer(a)2c9103{inputs=[org.jboss.beans.metadata.spi.BeanMetaData] outputs=[]} | org.jboss.deployment.ClientDeployer@304648{inputs=[] outputs=[org.jboss.metadata.ClientMetaData]} | org.jboss.deployment.security.SecurityDeployer(a)d9b071{inputs=[org.jboss.metadata.BeanMetaData, org.jboss.metadata.ApplicationMetaData, org.jboss.deployment.security.ignoreMe, org.jboss.metadata.WebMetaData] outputs=[jboss.jacc]} | org.jboss.ejb.deployers.EjbDeployer(a)147a16f{inputs=[org.jboss.metadata.ApplicationMetaData] outputs=[org.jboss.system.metadata.ServiceMetaData]} | org.jboss.ejb3.deployers.EJBRegistrationDeployer@1d6bff7{inputs=[] outputs=[org.jboss.deployment.security.ignoreMe, org.jboss.ejb3.Ejb3Deployment]} | org.jboss.resource.deployers.RARDeployer(a)393167{inputs=[org.jboss.resource.metadata.ConnectorMetaData] outputs=[org.jboss.system.metadata.ServiceMetaData]} | org.jboss.system.deployers.ServiceDeploymentDeployer(a)1aacd5f{inputs=[org.jboss.system.metadata.ServiceMetaData, org.jboss.system.metadata.ServiceDeployment] outputs=[org.jboss.system.metadata.ServiceMetaData]} | org.jboss.system.deployers.ServiceDeployer(a)14b081b{inputs=[org.jboss.system.metadata.ServiceMetaData] outputs=[]} | | at org.jboss.deployers.plugins.deployers.DeployersImpl.sort(DeployersImpl.java:905) | at org.jboss.deployers.plugins.deployers.DeployersImpl.addDeployer(DeployersImpl.java:178) | at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source) | at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) | at java.lang.reflect.Method.invoke(Method.java:585) | at org.jboss.reflect.plugins.introspection.ReflectionUtils.invoke(ReflectionUtils.java:55) | at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.invoke(ReflectMethodInfoImpl.java:108) | at org.jboss.joinpoint.plugins.BasicMethodJoinPoint.dispatch(BasicMethodJoinPoint.java:66) | at org.jboss.beans.info.plugins.AbstractBeanInfo.invoke(AbstractBeanInfo.java:255) | at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.invoke(AbstractKernelControllerContext.java:268) | at org.jboss.dependency.plugins.SingleCallbackItem.changeCallback(SingleCallbackItem.java:73) | at org.jboss.dependency.plugins.AbstractCallbackItem.changeCallback(AbstractCallbackItem.java:74) | at org.jboss.dependency.plugins.OwnerCallbackItem.changeCallback(OwnerCallbackItem.java:88) | at org.jboss.dependency.plugins.AbstractController.resolveCallbacks(AbstractController.java:1152) | at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:695) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:813) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:735) | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:525) | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:361) | at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:69) | at org.jboss.deployers.vfs.deployer.kernel.BeanMetaDataDeployer.deploy(BeanMetaDataDeployer.java:42) | at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.deploy(AbstractSimpleRealDeployer.java:65) | at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:164) | at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:657) | at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:672) | at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstall(DeployersImpl.java:623) | at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:587) | at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:304) | at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1257) | at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:685) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:813) | at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:735) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:573) | at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:374) | at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:426) | at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:340) | at org.jboss.system.server.profileservice.ProfileServiceBootstrap.loadProfile(ProfileServiceBootstrap.java:372) | at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:247) | at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89) | at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:403) | at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:342) | at org.jboss.Main.boot(Main.java:210) | at org.jboss.Main$1.run(Main.java:523) | at java.lang.Thread.run(Thread.java:595) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059992#4059992 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059992

19 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Precedence

by adrian＠jboss.org

You'll be suprised how fast a "bubble sort" is with modern cpus that do caching. :-) When we get to more than 100 deployers and it doesn't fit in the cpu cache then we might want to look at optimizing it. :-) It's actually much less than O(n^2) since (n-1) of the deployers are already in the correct order anyway. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059984#4059984 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059984

19 years

1
0
0 / 0

[Design of JBoss jBPM] - semantic element creation

by msandoz

i am trying to figure out the least intrusive way to code in creation of a hierarchy of semantic elements from a new node dropped from the palette. here's my scenario (the first two steps work fine) 1. user selects a palette entry for my node. 2. a semantic element and adapter are created 3. an action and data for the action are created with the node and adapters and xml nodes are created what is the preferred way of making sure multiple levels of defaults exist both in the xml and model? the model constructor? initialize() in the adapter? getDefaultValue() in the adapter? or is there a better way? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059973#4059973 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059973

19 years

1
0
0 / 0

[Design of JBoss/Tomcat Integration] - Tomcat application publish messages in jboss queue

by susthiya

Hi.., I have install jboss-4.0.5.GA and Tomcat 5.5 in the windows platform.My aaplication is deployed in the tomcat server and this application want to publish messages to queue define in jboss server (tomcat is not the jboss integrated web server) how can i setup this configuration? Any links or documents available under jboss documentaion and any guide is hightly appriciated. Thanks, Susthiya View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059967#4059967 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059967

19 years

1
0
0 / 0

[Design of JBossCache] - Re: Optimistic locking doesn't scale well with large 'flat'

by manik.surtani＠jboss.com

Listeners may not be necessary - the WorkspaceNodeImpl could do something like: 1) Load child nodes lazily. I.e., when the base node is loaded into the workspace, don't load child map. 2) Changes made to child node map maintained as a delta in the workspace (e.g., adds, modifications, removes) with lazy loading of children. 3) trying to get a child node will cache a null in the workspace if the child node doesn't exist - to maintain repeatable_read 4) Merge back changes on commit time. The drawback here is that it allows for s slight difference in semantics from pessimistic locking, due to the lazy locking (copying into workspace) of children ... Is this approach workable? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059963#4059963 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059963

19 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Precedence

by alesj

Or O(n*log(n)) vs. O(log(n)) if we 'exaggerate' on the implementation. ;-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059956#4059956 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059956

19 years

1
0
0 / 0

[Design the new POJO MicroContainer] - Re: Precedence

by alesj

"adrian(a)jboss.org" wrote : | Yes. But you're welcome to examine the code and try to come up with new testcases | where it breaks. The only thing that should be not supported is loops. :-) | See DeployersImpl.sort() Do we really need to check all current deployers (O(n^2))? Since the original set is already ordered, thus we only need to find the position of the newly added deployer (O(n)). View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059954#4059954 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059954

19 years

1
0
0 / 0

[Deployers on JBoss (Deployers/JBoss)] - Re: HOWTO: remove a deployment context that is in error?

by adrian＠jboss.org

"wolfc" wrote : "Brian" wrote : | | Thus remains the question: how to remove a deployment context that is in error state? | | If the deployment is already in error, then it should already be undeployed! | removeDeployment() for a context already in error just tidies up the maps in the | MainDeployer. | | Any error during the deployment will rollback the deployment to the undeployed state. | | If this is not happening then it is a bug in one of the deployers somewhere, | most likely the common problem with broken error handling like the issues | raised with the AOP deployer: | http://www.jboss.com/index.html?module=bb&op=viewtopic&t=112184 | | If you changed the relevant deployer to use Components, then you'd automatically | get the correct pattern (it is handled by the deployment framework) | without having to think about unwinding explicitly. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4059922#4059922 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4059922

19 years

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