[EJB 3.0] - Possible Bug?
by green_bean_1
So, I have two different SLSB mapped to two different locations in JNDI:
javaEEApplication/HelloWorldStatelessBean/remote-com.di.examples.HelloWorld - EJB3.x Remote Business Interface
javaEEApplication/StatelessLifecycle/remote-com.di.examples.HelloWorld - EJB3.x Remote Business Interface
As you can see, they share the same "Business Interface", yet the implementation classes are different.
When I do a DI within a JSP using:
<%!
@EJB(name="javaEEApplication/HelloWorldStatelessBean/remote-com.di.examples.HelloWorld") HelloWorld helloWorld;
@EJB(name="javaEEApplication/StatelessLifecycle/remote-com.di.examples.HelloWorld") HelloWorld lifecycle;
%>
The two references point to the same object.. I would assume each reference would point the correct implementation ...
So, it seems to me like if two impls share the same interface, JBoss doesn't differentiate them?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197479#4197479
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197479
17 years, 6 months
[EJB 3.0] - Re: JNDI lookup of EJB3 SLSB from Quartz
by jharby1
I also occasionally see this come up:
|
| 14:33:07,135 ERROR [STDERR] java.lang.ClassCastException: $Proxy104 cannot be cast to com.csatp.service.policy.FundingService
| 14:33:07,135 ERROR [STDERR] at com.csatp.service.scheduler.checkHandlerBean.execute(checkHandlerBean.java:58)
| 14:33:07,151 ERROR [STDERR] at sun.reflect.GeneratedMethodAccessor281.invoke(Unknown Source)
| 14:33:07,151 ERROR [STDERR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
| 14:33:07,151 ERROR [STDERR] at java.lang.reflect.Method.invoke(Method.java:597)
| 14:33:07,151 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:112)
| 14:33:07,151 ERROR [STDERR] at org.jboss.ejb3.interceptor.InvocationContextImpl.proceed(InvocationContextImpl.java:166)
| 14:33:07,151 ERROR [STDERR] at org.jboss.ejb3.interceptor.EJB3InterceptorsInterceptor.invoke(EJB3InterceptorsInterceptor.java:63)
| 14:33:07,151 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| 14:33:07,151 ERROR [STDERR] at org.jboss.ejb3.entity.TransactionScopedEntityManagerInterceptor.invoke(TransactionScopedEntityManagerInterceptor.java:54)
| 14:33:07,151 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| 14:33:07,151 ERROR [STDERR] at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
| 14:33:07,151 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| 14:33:07,151 ERROR [STDERR] at org.jboss.aspects.tx.TxPolicy.invokeInCallerTx(TxPolicy.java:126)
| 14:33:07,151 ERROR [STDERR] at org.jboss.aspects.tx.TxInterceptor$Required.invoke(TxInterceptor.java:195)
| 14:33:07,151 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| 14:33:07,151 ERROR [STDERR] at org.jboss.ejb3.stateless.StatelessInstanceInterceptor.invoke(StatelessInstanceInterceptor.java:62)
| 14:33:07,151 ERROR [STDERR] at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
| 14:33:07,151 ERROR [STDERR] at org.jboss.ejb3.mdb.MessagingContainer.localInvoke(MessagingContainer.java:249)
| 14:33:07,151 ERROR [STDERR] at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.delivery(MessageInflowLocalProxy.java:268)
| 14:33:07,151 ERROR [STDERR] at org.jboss.ejb3.mdb.inflow.MessageInflowLocalProxy.invoke(MessageInflowLocalProxy.java:138)
| 14:33:07,151 ERROR [STDERR] at $Proxy231.execute(Unknown Source)
| 14:33:07,151 ERROR [STDERR] at org.jboss.resource.adapter.quartz.inflow.QuartzJob.execute(QuartzJob.java:57)
| 14:33:07,151 ERROR [STDERR] at org.quartz.core.JobRunShell.run(JobRunShell.java:203)
| 14:33:07,151 ERROR [STDERR] at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)
|
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197470#4197470
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197470
17 years, 6 months
[Persistence, JBoss/CMP, Hibernate, Database] - Recomended approach for using JPA and JDBC together?
by dbush21
I want to use new JPA Entities in conjunction with straight JDBC (because of an existing stored procedure layer). Is there a recommended approach for acquiring the connection to do the JDBC operations?
I have tried the following two approaches and both seam to work, In A I retrieve a connection from the same data source that the entity manager is using. In B, I use getDelegate() to obtain the Hibernate session and then borrow / release a connection.
I am leaning towards A but, I am worried that the two connections are actually different instances. As for B it's more programmatic, centric to JBoss/Hibernate, and am not sure about the whole borrow / release deal. I see that there is also a plain getConnection() on ConnectionManager and I'm really not sure which approach is intended to be used in this situation if any ....
I am also unclear as to any transactional implications. Although at this point both look to be operating as expected.
A)
1. look up an entity via the entity manager
2. modify the entity
3. flush the entity manager so the modifications are visible
4. retrieve the data source via a JNDI lookup
5. get a connection from the data source
6. execute JDBC operation to verify the modification is visable
B)
1. look up an entity via the entity manager
2. modify the entity
3. flush the entity manager so the modifications are visible
4. get a connection from the entity manager via:
Object obj = (Object) em.getDelegate();
org.hibernate.impl.SessionImpl session = (SessionImpl) obj;
JDBCContext jdbcCtx = session.getJDBCContext();
ConnectionManager cm = jdbcCtx.getConnectionManager();
Connection conn = cm.borrowConnection();
5. execute JDBC operation to verify the modification is visable
6. release the connection via cm.releaseBorrowedConnection();
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197469#4197469
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197469
17 years, 6 months
[Clustering/JBoss] - Re: strace shows futex
by bstansberry＠jboss.com
I just pinged the JGroups folks again. You can also try the jgroups user mail list at https://lists.sourceforge.net/lists/listinfo/javagroups-users .
Re: HASingletonController, first thing to understand is that who the master is is a function of what nodes in the cluster have that HASingletonController deployed. There is the overall cluster view, which more people are familiar with, and then something that I call the "service view", which reflects what nodes in the cluster have a particular service deployed.
So, say you have a 4 node cluster and the view for the cluster is {A, B, C, D}. But the "Foo" service's HASingletonController is only deployed on 2 nodes. So it's service view is {C, D}. The "Bar" service's HASingletonController is deployed on a different 2 nodes, so it's service view is {A, B}.
In this example the master for the "Foo" service is C and the master for "Bar" is A.
A service view is always a subset of the overall cluster view. If a node crashes, it's removed from all service views.
How all this works behind the scenes is an HASingletonController uses a component of the HAPartition known as the DistributedReplicantManager. The DRM basically maintains the service views. When for example the "Foo" service HASingletonController is deployed on node D, it registers itself with the DRM by invoking the DRM add method. DRM in turn invokes a method on the HAPartition which does a group RPC telling the other DRMs in the cluster that "Foo" is now available on D. Those DRMs in turn issue a notification to the "Foo" HASingletonController on their nodes telling them that the service view for the "Foo" service has changed, and now includes "D". From that they can determine who the master is.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4197463#4197463
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4197463
17 years, 6 months