I am trying out simple JPA example on TomEE 4.0.0 and I am not able to get PersistenceContextType.EXTENDED working
If I make my session bean Stateless and leave PersistenceContextType then it works fine
#PersistenceContext(unitName = "xxx" )
private EntityManager entityManager;
If I keep my session bean as Stateless and then try to use this
#PersistenceContext(unitName = "xxx", type = PersistenceContextType.EXTENDED))
private EntityManager entityManager;
it gives me an error while deploying, which is perfectly fine and in line with expectation.
However now when I make my bean as #Stateful, then also it gives me an error
Managed ejbs are not capable of using EntityManagers with EXTENTED persistence. Convert your bean to a Stateful ejb or update the "java:comp/env/com.testwebservice.TestJPAService/entityManager" PersistenceContext reference to PersistenceContextType.TRANSACTION.
Can some one please help, I am really confused for this
#Stateful EXTENDED persistence contexts are tested in numerous ways in the TomEE build and also in the Java EE TCK.
Likely this is something else completely. We do our best to warn you when you make obvious mistakes as you note with the incorrect combination of #Stateless with PersistenceContextType.EXTENDED
Looking at the JNDI name which contains com.testwebservice.TestJPAService and given the fact it was #Stateless before it was changed to #Stateful, my guess is that this bean is also an #WebService which is illegal. #Stateful beans cannot be #WebService beans. Without a proper check to prevent this mistake, my guess is that the bean is actually being deployed twice; once as a #Stateful bean and once as an pojo #WebService. The pojo web service is the one causing the error.
In case that is the error, I've filed a JIRA for us to explicitly check that condition.
Related
Although there already are quite some StackOverflow questions, blog entries, etc. on the web, I still cannot figure out a solution to the problem stated below.
Similar to this question (Injecting EJB within JAX-RS resource on JBoss7) I'd like to inject a EJB instance into a JAX-RS class. I tried with JBoss 5, JBoss 7, and WildFly 8. I either get no injection at all (field is null), or the server does not deploy (as soon as I try to combine all sorts of annotations).
Adding #Stateless to the JAX-RS makes the application server know both classes as beans. However, no injection takes place.
Is there a way to inject EJBs into a REST application? What kind of information (in addition to that contained in the question linked to above) could I provide to help?
EDIT: I created a Github project showing code that works (with Glassfish 4.0) and does not work (with JBoss 5).
https://github.com/C-Otto/beantest
Commit 4bf2f3d23f49d106a435f068ed9b30701bbedc9d works using Glassfish
4.0.
Commit 50d137674e55e1ceb512fe0029b9555ff7c2ec21 uses Jersey 1.8, which does not work.
Commit 86004b7fb6263d66bda7dd302f2d2a714ff3b939
uses Jersey 2.6, which also does not work.
EDIT2:
Running the Code which I tried on JBoss 5 on Glassfish 4.0 gives:
Exception while loading the app : CDI deployment failure:WELD-001408 Unsatisfied dependencies for type [Ref<ContainerRequest>] with qualifiers [#Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] #Inject org.glassfish.jersey.server.internal.routing.UriRoutingContext(Ref<ContainerRequest>, ProcessingProviders)]
org.jboss.weld.exceptions.DeploymentException: WELD-001408 Unsatisfied dependencies for type [Ref<ContainerRequest>] with qualifiers [#Default] at injection point [[BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] #Inject org.glassfish.jersey.server.internal.routing.UriRoutingContext(Ref<ContainerRequest>, ProcessingProviders)]
at org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:403)
EDIT3: The crucial information might be that I'd like a solution that works on JBoss 5
If you don't want to make your JAX-RS resource an EJB too (#Stateless) and then use #EJB or #Resource to inject it, you can always go with JNDI lookup (I tend to write a "ServiceLocator" class that gets a service via its class.
A nice resource to read about the topic:
https://docs.jboss.org/author/display/AS71/Remote+EJB+invocations+via+JNDI+-+EJB+client+API+or+remote-naming+project
A sample code:
try {
// 1. Retreive the Home Interface using a JNDI Lookup
// Retrieve the initial context for JNDI. // No properties needed when local
Context context = new InitialContext();
// Retrieve the home interface using a JNDI lookup using
// the java:comp/env bean environment variable // specified in web.xml
helloHome = (HelloLocalHome) context.lookup("java:comp/env/ejb/HelloBean");
//2. Narrow the returned object to be an HelloHome object. // Since the client is local, cast it to the correct object type.
//3. Create the local Hello bean instance, return the reference
hello = (HelloLocal)helloHome.create();
} catch(NamingException e) {
} catch(CreateException e) {
}
This is not "injecting" per-se, but you don't use "new" as-well, and you let the application server give you an instance which is managed.
I hope this was useful and I'm not telling you something you already know!
EDIT:
This is an excellent example: https://docs.jboss.org/author/display/AS72/EJB+invocations+from+a+remote+client+using+JNDI
EDIT 2:
As you stated in your comment, you'd like to inject it via annotations.
If the JNDI lookup is currently working for you without problems, and
If you're using Java EE 6+ (which I'm guessing you are), you can do the following:
#EJB(lookup = "jndi-lookup-string-here")
private RemoteInterface bean;
Acording to another post [1] there's no difference between invoking a session EJB via JNDI lookup and using the #EJB annotation. However, in the following scenario:
1.- call session EJB1(JDBC inserts here)
2.- From EJB1, call session EJB2 (more inserts here)
3.- Rollback the transaction (from EJB1)
If I use the #EJB annotation it works fine, but with the JNDI lookup it doesn´t, the transaction in the second EJB is a new one and the rollback doesn´t happen. All this with CMT.
I'm deploying all this stuff in a Geronimo/ibmwasce-2.1.1.6.
¿Do I need to pass the transaction from one EJB to another explicitly? I thought it was the continer job. ¿Any clues?
[1] #EJB annotation vs JNDI lookup
Update:
Code via annotation:
#EJB
private CodAppEjb codAppejbAnotacion;
Code via jndi:
CodAppEjb codAppejb;
InitialContext ctx;
Properties properties= new Properties();
properties.setProperty("java.naming.provider.url", "ejbd://127.0.0.1:4201");
properties.setProperty("java.naming.factory.initial", "org.apache.openejb.client.RemoteInitialContextFactory");
ctx = new InitialContext(properties);
codAppejb= (CodAppEjb) ctx.lookup("CodAppEjbBeanRemote");
The transaction code is just the same.
It seems, you have a transaction propagation problem.
The problem seems to be, that in your JNDI lookup you search for the remote EJB (not Local), which does NOT get executed in the same transaction context as EJB1.
When using the #EJB annotation above, the local implementation is injected, with the same transaction context.
I am trying to make my first Java Enterprise Application and use UserTransactions.
Therefore I use JNDI Lookup with java:comp/UserTransaction to get my UserTransaction Object.
public void myMethod(MyEntity e) throws ApplicationException {
try {
this.ut = getUserTransaction();
this.ut.begin();
this.myStatefulBean.myBusinessMethod(e);
} catch ...
When I start my Transaction with .begin() and try to invoke any method in my stateful Bean (which works properly before starting a UserTransaction) I get an EJBTransactionRolledbackException which leads me to the following error:
java.lang.IllegalStateException: cannot add non-XA Resource to global JTS transaction
The Bean I am using is annotated with #DataSourceDefinition having className = "org.apache.derby.jdbc.ClientXADataSource" thus there is imo no non-XA Resource.
What am I doing wrong?
I am using openjpa 2.2.1, Java EE Version 6
Solved the problem by myself. I used in my DataSourceDefinition name = "java:global/jdbc/testDB" as name, but in my persistence.xml the DataSource name was defined as <jta-data-source>testDB</jta-data-source>
This seems to work in CMTs but not in a UserTransaction. Correcting the entry in persistence.xml to <jta-data-source>java:global/jdbc/testDB</jta-data-source> fixed the problem.
I already have a integration-test phase, when I ran the selenium tests. I also want to run some unit tests in this phase, because the app is too much complex and have a lot of dependencies between his modules (a hell), so, after a week fighting against OpenEJB and Arquillian, I believe that this would be easier.
The thing is: how do I made it work?
I have the instance already running, if I instantiate an InitialContext and try to lookup some bean, I got an exception telling me that I have not set the java.naming.initial.factory, and I don't know what to put in there.
I'm also complaining about the annotated beans.
Suppose a Bean like this:
#Stateless
public class ABeanImpl implements ABean {
#EJB
private BBean;
}
Will the container automatically get right the BBean?
Thanks in advance
How to connect to JBoss 7.1 remote JNDI:
Here is the code snippet that I use for JBoss 7.1:
Properties props = new Properties();
String JBOSS_CONTEXT = "org.jboss.naming.remote.client.InitialContextFactory";
props.put("jboss.naming.client.ejb.context", true);
props.put(Context.INITIAL_CONTEXT_FACTORY, JBOSS_CONTEXT);
props.put(Context.PROVIDER_URL, "remote://localhost:4447");
props.put(Context.SECURITY_PRINCIPAL, "jboss");
props.put(Context.SECURITY_CREDENTIALS, "jboss123");
InitialContext ctx = new InitialContext(props);
Resolution of ambiguous ejb references:
According to JBoss EJB 3 reference, if at any level of your EJB environment (EJB/EAR/Server) are duplicates in used interfaces, exception will be thrown during resolution of injected beans.
Based on above, if you have got a reference to EJB bean which interface:
has two implementations in your EJB module (JAR/WAR) - exception will be thrown
has two implementations in your application (other EJB JAR's in same EAR) - exception will be thrown
has two implementations, one in module with bean ABeanImpl, second somewhere else - implemetation from current module is used.
I am new to EJB3 and am missing something when it comes to accessing a #Remote #Stateless bean deployed as an ejb module inside an ear file. I want to access a remote bean in lima.ear from soup.ear.
Here is what I am doing now (somewhat abbreviated):
//deployed under lima.ear
#Remote
#Stateless
public interface LimaBean {
String sayName();
}
I want to put LimaBean in the Soup:
//deployed in soup.ear
#Stateless
public class Soup implements SoupLocal {
#EJB
private LimaBean limaBean;
public String taste() {
return limaBean.sayName();
}
}
When I start JBoss I get the following error:
java.lang.RuntimeException: could not resolve global JNDI name for #EJB for container Soup: reference class: com.example.LimaBean ejbLink: not used by any EJBs
I have had a hard time finding out what this ejbLink is about, if that is the right path to go down.
If I deploy LimaBean as a jar file in jboss then everything works great!
I ran accross an article that had a section called "2.5.3. References between beans in different jars and different ears"
(http://jonas.ow2.org/doc/howto/jboss2_4-to-jonas3_0/html/x111.html)
Example of jboss.xml file for SB_BrowseRegions:
<jboss>
<session>
<ejb-name>SB_BrowseRegions</ejb-name>
<ejb-ref>
<ejb-ref-name>ejb/Region</ejb-ref-name>
<jndi-name>protocol://serverName/directory/RegionHome</jndi-name>
</ejb-ref>
</session>
</jboss>
If I touch the soup.ear, after JBoss starts up then it deploys fine, so I am assuming I need to specify a dependency like the above article says.
But even after it deploys then I get an error when accessing the remote LimaBean:
Caused by: java.lang.IllegalArgumentException: Can not set com.soup.LimaBean field com.soup.Soup.limaBean to $Proxy147
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:146)
at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:150)
at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:63)
at java.lang.reflect.Field.set(Field.java:657)
at org.jboss.injection.JndiFieldInjector.inject(JndiFieldInjector.java:115)
... 49 more
I have tried a few things but, if anyone can point me in the right direction about this I would appreciate it.
It looks like the JNDI properties need to be set as if it were a remote client outside of the app server because of the ear isolation we have setup.
properties.put(Context.PROVIDER_URL, url);
InitialContext ctx = new InitialContext(properties);
Just specify the URL for the InitialContext and that should do the trick.