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

[EJB 3.0 Development] New message: "Fail on deploy: NullPointerException"

by Jose M. M. M.

JBoss development, A new message was posted in the thread "Fail on deploy: NullPointerException": http://community.jboss.org/message/528215#528215 Author : Jose M. M. M. Profile : http://community.jboss.org/people/jotremar Message: -------------------------------------------------------------- I make a project with EJB 3.0 with netbeans + jboss. When I deploy it, alway say: 15:48:30,489 ERROR [Ejb3Deployment] Exception while processing container metadata for EJB: Ingreso in unit: TodoRecargas-Admin.jar 15:48:30,490 ERROR [AbstractKernelController] Error installing to Real: name=vfszip:/E:/jboss/server/default/deploy/TodoRecargas-Admin.jar/ state=PreReal mode=Manual requiredState=Real org.jboss.deployers.spi.DeploymentException: Error deploying TodoRecargas-Admin.jar: Exception while processing container metadata for EJB: Ingreso in unit: TodoRecargas-Admin.jar at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:196) at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:99) at org.jboss.deployers.vfs.spi.deployer.AbstractVFSRealDeployer.internalDeploy(AbstractVFSRealDeployer.java:45) at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50) at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171) at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439) at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157) at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098) at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348) at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631) at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082) at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822) at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553) at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781) at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702) at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117) at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:362) at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:255) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: java.lang.Exception: Exception while processing container metadata for EJB: Ingreso in unit: TodoRecargas-Admin.jar at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:549) at org.jboss.ejb3.deployers.Ejb3Deployer.deploy(Ejb3Deployer.java:189) ... 28 more Caused by: java.lang.NullPointerException at org.jboss.injection.ResourceHandler.loadXmlResourceRefs(ResourceHandler.java:185) at org.jboss.injection.ResourceHandler.loadXml(ResourceHandler.java:335) at org.jboss.ejb3.EJBContainer.processMetadata(EJBContainer.java:588) at org.jboss.ejb3.Ejb3Deployment.processEJBContainerMetadata(Ejb3Deployment.java:418) at org.jboss.ejb3.Ejb3Deployment.start(Ejb3Deployment.java:527) ... 29 more 15:48:30,879 WARN [HDScanner] Failed to process changes org.jboss.deployers.client.spi.IncompleteDeploymentException: Summary of incomplete deployments (SEE PREVIOUS ERRORS FOR DETAILS): *** DEPLOYMENTS IN ERROR: Name -> Error vfszip:/E:/jboss/server/default/deploy/TodoRecargas-Admin.jar/ -> org.jboss.deployers.spi.DeploymentException: Error deploying TodoRecargas-Admin.jar: Exception while processing container metadata for EJB: Ingreso in unit: TodoRecargas-Admin.jar DEPLOYMENTS IN ERROR: Deployment "vfszip:/E:/jboss/server/default/deploy/TodoRecargas-Admin.jar/" is in error due to the following reason(s): java.lang.NullPointerException at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:993) at org.jboss.deployers.plugins.deployers.DeployersImpl.checkComplete(DeployersImpl.java:939) at org.jboss.deployers.plugins.main.MainDeployerImpl.checkComplete(MainDeployerImpl.java:873) at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.checkComplete(MainDeployerAdapter.java:128) at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:369) at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:255) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/528215#528215

14 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: Web beans on top of Microcontainer deployment order"

by Kabir Khan

JBoss development, A new message was posted in the thread "Web beans on top of Microcontainer deployment order": http://community.jboss.org/message/528213#528213 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- I have updated the jsr330 branch and will merge to trunk once I have a added a few more tests. The kernel now supports the JSR 330 usage of @javax.inject.Inject, e.g.: public class SomeBean { @Inject @SomeQualifier Thing t; @Inject public SomeBean(@SomeQualifier Thing t){} @Inject public void setThingA(@SomeQualifier Thing t){} @Inject @SomeQualifier public void setThingB(Thing t){} @Inject public void installMethod(@SomeQualifier Thing t, @OtherQualifier Thing t2){} } If we have the following MC bean public class MyBean{ @Inject Thing t; @Weld @Inject Other o; } +t+ will be injected from the MC using contextual injection, while +o+ will be injected from Weld. This is done by maintaining a registry of annotations that should be ignored by the @Inject annotation plugins, so if the member also has one of those annotations (e.g. @Weld) we don't create the standard MC injection value metadata for it. When creating the weld injection we create a weld AnnotatedType for the bean, for which there is a decorator that looks at the MDR metadata for the bean. I modified the getAnnotations(), isAnnotationPresent() and getAnnotation() methods to strip out the @Inject unless @Weld is also present, so that weld does not try to inject into those members. To make an MC bean injectable into Weld it needs the @WeldEnabled annotation, e.g.: If we have the following MC bean @WeldEnabled public class McBeanForWeld{ } -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/528213#528213

14 years, 1 month

1
0
0 / 0

[EJB 3.0 Development] New message: "Re: EJBTHREE-2007: VFS Abstraction"

by John Bailey

JBoss development, A new message was posted in the thread "EJBTHREE-2007: VFS Abstraction": http://community.jboss.org/message/528205#528205 Author : John Bailey Profile : http://community.jboss.org/people/johnbailey Message: -------------------------------------------------------------- > jaikiran wrote: > > When your changes have been commited, let us know. The release will not take long. We have the hudson build environment to catch any regressions. The changes to EJB3 core have been committed. Let me know how the hudson build goes. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/528205#528205

14 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: JBDEPLOY-226 - DeployerClient change extension"

by Adrian Brock

JBoss development, A new message was posted in the thread "JBDEPLOY-226 - DeployerClient change extension": http://community.jboss.org/message/528201#528201 Author : Adrian Brock Profile : http://community.jboss.org/people/adrian@jboss.org Message: -------------------------------------------------------------- > alesj wrote: > > I see we're on the same page -- this feature is just a nicer API, done width first. > > I was just wondering if you're tackling the circular references problem. > ((ab)using this thread to check up on you ) Nope. But that probably needs resolving (pun intended) in the jboss-dependency project? Currently a DependencyItem knows what it wants to resolve against and just checks whether it is in the correct state. If however this leads to a circular dependency, nothing moves. e.g. A depends upon B at CLASSLOADER B depends upon A at CLASSLOADER For A, ControllerContext context = controller.getContext(B, CLASSLOADER); will return null and the same for B with respect to A. Instead, what is required is some api within the DependencyInfo/Item to say, well actually I will return a context because the only thing that is stopping them moving is the circular dependency. Something like: RequirementDependencyItem extends AbstractDependencyItem { public boolean resolve(Controller) { Module module = resolveModule(); // Now we know what we want to resolve to if (module != null) { ControllerContext ctx = module.getControllerContext(); putThisDependencyInASemiResolvedStateOnContext(ctx) boolean resolved = doesTheOtherContextAndItsTransientsHaveCompletelyUnresolvedDependenies(ctx, getDependentState()); // i.e. not resolved at all rather resolved or semi-resolved // etc. } } } I can prototype this in the ClassLoading project, but I think it is a general requirement? NOTE: This feature is only possible for a dependency where the underlying model can handle circular dependencies. e.g. constructors on pojos can't do it But the classloading can, since it can lazily wire the classloaders together using the ClassLoaderPolicyFactory on the DelegateLoader. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/528201#528201

14 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: JBDEPLOY-226 - DeployerClient change extension"

by Adrian Brock

JBoss development, A new message was posted in the thread "JBDEPLOY-226 - DeployerClient change extension": http://community.jboss.org/message/528188#528188 Author : Adrian Brock Profile : http://community.jboss.org/people/adrian@jboss.org Message: -------------------------------------------------------------- > mailto:adrian@jboss.org wrote: > I've left the JIRA open in case we want to add some other methods? > I've also added a notion of bouncing a set of deployments since this is really the use case for the new api. bounce(DeploymentStages.DESCRIBE, true, deploymentNames); will move all the deployments listed that have proceed beyond the DESCRIBE stage back to the DESCRIBE stage then return them to their original required stage. i.e. it will re-resolve the classloader dependencies and re-create the classloaders. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/528188#528188

14 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: JBDEPLOY-226 - DeployerClient change extension"

by Thomas Diesler

JBoss development, A new message was posted in the thread "JBDEPLOY-226 - DeployerClient change extension": http://community.jboss.org/message/528179#528179 Author : Thomas Diesler Profile : http://community.jboss.org/people/thomas.diesler@jboss.com Message: -------------------------------------------------------------- Yes, the additional checks for completeness seem to have been the problem. I now doin PackageAdmin // Advance the bundles to stage CLASSLOADER and check at the end advanceBundlesToClassloader(resolvableBundles); try { DeployerClient deployerClient = getBundleManager().getDeployerClient(); deployerClient.checkComplete(); } catch (DeploymentException ex) { log.error("Error resolving bundles: " + resolvableBundles, ex); allResolved = false; } There is an additional deployer which sets the bundle state to RESOLVED once the deployment reaches the CLASSLOADER stage. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/528179#528179

14 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: JBDEPLOY-226 - DeployerClient change extension"

by Ales Justin

JBoss development, A new message was posted in the thread "JBDEPLOY-226 - DeployerClient change extension": http://community.jboss.org/message/528177#528177 Author : Ales Justin Profile : http://community.jboss.org/people/alesj Message: -------------------------------------------------------------- I see we're on the same page -- this feature is just a nicer API, done width first. I was just wondering if you're tackling the circular references problem. ((ab)using this thread to check up on you ) -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/528177#528177

14 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: JBDEPLOY-226 - DeployerClient change extension"

by Adrian Brock

JBoss development, A new message was posted in the thread "JBDEPLOY-226 - DeployerClient change extension": http://community.jboss.org/message/528172#528172 Author : Adrian Brock Profile : http://community.jboss.org/people/adrian@jboss.org Message: -------------------------------------------------------------- I'm saying this feature is irrelevant to the problem. Whether it can resolve circular references is a seperate issue for the dependency mechanism to spot. The order in which you change the state of things shouldn't make a difference. If A depends upon B which then depends upon A all at stage 1, it does not matter whether you do: change(A, stage1); change(A, stage2); change(B, stage1); change(B, stage2); checkComplete(A, B); or change(A, stage1); change(B, stage1);change(A, stage2); change(B, stage2); checkComplete(A, B); The result should be the same. If you add more checkComplete()s between the steps then obviously it is going to report an incomplete deployment until A and B are both at stage1. change(A, stage1); checkComplete(A); // Oops, IncompleteDeploymentException - A depends B which is not in the correct state yet, so A is not at stage 1 either. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/528172#528172

14 years, 1 month

1
0
0 / 0

[JBoss Microcontainer Development] New message: "Re: JBDEPLOY-226 - DeployerClient change extension"

by Ales Justin

JBoss development, A new message was posted in the thread "JBDEPLOY-226 - DeployerClient change extension": http://community.jboss.org/message/528169#528169 Author : Ales Justin Profile : http://community.jboss.org/people/alesj Message: -------------------------------------------------------------- > I don't see why resolving circular dependencies needs this feature? > The problem with Thomas's implementation (if it is like what he has done elsewhere) > is that he is doing a checkComplete() too often. > He should check them all at the end, not during/after every single move. :-) I doesn't. But it would definitely be good if it was the other way around - this feature needs circular resolving. Otherwise it doesn't make much sense, if the deployments are not actually moved into the state you wanted them to move. At least for the "valid" circular deployments -- which is often the case in OSGi -- according to TCK. I don't see how checking at the end would help. They would still not be in the "right" state. Or are you saying Controller::change(deploymentContext, state) already knows how to resolve this? e.g. deployment A imports some B's packages, and vice versa, and afterwards we would expect both of them in past Describe state (or how do valid OSGi circular depencies look like?) -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/528169#528169

14 years, 1 month

1
0
0 / 0

[jBPM Development] New message: "Re: presumable bug JPDL 4 Graphical Editor, erase <field>"

by Ralf Nagel

JBoss development, A new message was posted in the thread "presumable bug JPDL 4 Graphical Editor, erase <field>": http://community.jboss.org/message/528126#528126 Author : Ralf Nagel Profile : http://community.jboss.org/people/edvseppel Message: -------------------------------------------------------------- I can confirm this bug. I have the same experience. If you write the jPDL by hand (or use only the source view of the GPD) it work's. In the documentation (6.7 user code) fields are allowed for custom tags. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/528126#528126

14 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2010