[EJB 3.0] New message: "Re: EJB3 Session Bean Container error"
by jaikiran pai
User development,
A new message was posted in the thread "EJB3 Session Bean Container error":
http://community.jboss.org/message/528223#528223
Author : jaikiran pai
Profile : http://community.jboss.org/people/jaikiran
Message:
--------------------------------------------------------------
> julianovidal wrote:
>
>
>
> The error ocurrs when I try to access a Remote SessionBean.
>
>
>
You mean the client is not in the same JVM as the deployed bean, right? (Just trying to get a better picture of what's happening)
> julianovidal wrote:
>
>
>
> The weird thing is that I actually get the instance when I do the lookup:
>
> *public* CategoryRemote getCategory() *throws* CMSException {
> Object obj = CMSServiceLocator.getInstance().getObject(CategoryRemote.REMOTE);
> *return* (CategoryRemote) PortableRemoteObject.narrow(obj, CategoryRemote.class);
> }
>
>
>
>
>
>
The interceptor is considering it to be a in-JVM call (i.e. client and bean are in same JVM). Before i look into the details, can you remove that PortableRemoteObject.narrow call? It's not required in EJB3. (I have a suspicion that it's messing up with the returned proxy - although i am not sure yet).
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/528223#528223
15 years, 10 months
[JBoss Microcontainer Development] New message: "Re: JBDEPLOY-226 - DeployerClient change extension"
by Ales Justin
User development,
A new message was posted in the thread "JBDEPLOY-226 - DeployerClient change extension":
http://community.jboss.org/message/528219#528219
Author : Ales Justin
Profile : http://community.jboss.org/people/alesj
Message:
--------------------------------------------------------------
> Nope. But that probably needs resolving (pun intended) in the jboss-dependency project?
> I can prototype this in the ClassLoading project, but I think it is a general requirement?
What ever is easier for you.
Although it sounds like it should be a general requirement,
I don't really see any other valid use case apart from classloading+deployments,
hence it could easily only exist in ClassLoading project.
Although you would still have to provide a couple of mixins in jboss-dependency?
As you already mentioned, to make this generic,
dependency item itself would have to be somehow aware of what is valid or what's not.
e.g. the circular ctor case is not valid, but CL dependencies are
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/528219#528219
15 years, 10 months
[EJB 3.0 Development] New message: "Fail on deploy: NullPointerException"
by Jose M. M. M.
User 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
15 years, 10 months
[JBoss Microcontainer Development] New message: "Re: Web beans on top of Microcontainer deployment order"
by Kabir Khan
User 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
15 years, 10 months
[Datasource Configuration] New message: "Problem connecting to Oracle using OCI driver"
by Ludovic Lecras
User development,
A new message was posted in the thread "Problem connecting to Oracle using OCI driver":
http://community.jboss.org/message/528212#528212
Author : Ludovic Lecras
Profile : http://community.jboss.org/people/llecras
Message:
--------------------------------------------------------------
Hello,
I would like to connect my datasource using the oracle jdbc oci driver to make some tests on failover modes.
I installed an Oracle 11 client on my server and I change my oracle-ds.xml to something like that:
<local-tx-datasource>
<jndi-name>DefaultDS</jndi-name>
<connection-url>jdbc:oracle:oci:@(DESCRIPTION=(xxx))</connection-url>
<user-name>xxxx</user-name>
<password>xxxx</password>
<min-pool-size>1</min-pool-size>
<max-pool-size>20</max-pool-size>
<query-timeout>60</query-timeout>
<driver-class>oracle.jdbc.OracleDriver</driver-class>
<exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.OracleExceptionSorter</exception-sorter-class-name>
<metadata>
<type-mapping>Oracle9i</type-mapping>
</metadata>
</local-tx-datasource>
Wen I start my jboss server, I have the following error:
Caused by: java.lang.UnsatisfiedLinkError: no ocijdbc11 in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1709)
at java.lang.Runtime.loadLibrary0(Runtime.java:823)
at java.lang.System.loadLibrary(System.java:1030)
at oracle.jdbc.driver.T2CConnection$1.run(T2CConnection.java:3171)
at java.security.AccessController.doPrivileged(Native Method)
at oracle.jdbc.driver.T2CConnection.loadNativeLibrary(T2CConnection.java:3167)
at oracle.jdbc.driver.T2CConnection.logon(T2CConnection.java:233)
at oracle.jdbc.driver.PhysicalConnection.<init>(PhysicalConnection.java:490)
at oracle.jdbc.driver.T2CConnection.<init>(T2CConnection.java:133)
at oracle.jdbc.driver.T2CDriverExtension.getConnection(T2CDriverExtension.java:53)
at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:465)
at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.getLocalManagedConnection(LocalManagedConnectionFactory.java:207)
... 96 more
I tried to add the path to the oracle .so library by adding the following option to my command line -Djava.library.path=/oracle/product/11.1.0/db_1/lib...
But I still have the error...
Does anybody have an idea?
Many thanks,
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/528212#528212
15 years, 10 months