StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
4678040
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
1
CommunityOwnedDate
CreationDate
2011-01-13T08:24:31.183
FavoriteCount
0
LastActivityDate
2011-01-13T12:49:56.080
LastEditDate
2011-01-13T12:49:56.080
LastEditorUserId
2935
OwnerUserId
2935
ParentId
4667410
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
text
Body
From a <a href="http://www.java.net/forum/topic/glassfish/glassfish/redeploy-tree-0" rel="nofollow">discussion</a> on the Glassfish forums: <blockquote> The injected reference is updated only when a new instance that it is injected into is created by the EJB container. So if you look it up all the time, you get an instance with the updated reference, but if your code holds on to the original instance, or if it is pooled, the injected reference remains stale. </blockquote> So the root problem is that the reference to the EJB is stale. I have found two solutions to this problem: <ol> <li>Look up the EJB on each request (do not use CDI)</li> <li>Wrap EJBs in a proxy that looks up the EJB if the reference is stale</li> </ol> With the second solution, CDI can still be used. You'll need a producer, and an <code>InvocationHandler</code>. The code below is a simplified version of the code I use in my project, and it might not compile properly, but it will show the idea and concepts used in making this work. YMMV. First, in the code that uses the EJB, you use <code>@Inject</code>, as follows: <pre><code>public class Foo { @Inject MyEjb obj; } </code></pre> Second, you'll need a producer that simply returns a wrapped version of the EJB: <pre><code>public class MyEjbProducer { @EJB(name = "MyEjb") private MyEjb obj; @Produces public MyEjb getEjb(final InjectionPoint ip) { InvocationHandler handler = new MyInvocationHandler(obj, MyEjb.class); return (MyEjb)Proxy.newProxyInstance(obj.getClass().getClassLoader(), obj.getClass().getInterfaces(), handler); } } </code></pre> Third, the invocation handler needs to test for <code>NoSuchEjbException</code> and look up the bean again: <pre><code>public class MyInvocationHandler implements InvocationHandler { private MyEjb obj; private Class lookupClass; public MyInvocationHandler(MyEjb obj, Class lookupClass) { this.obj = obj; this.lookupClass = lookupClass; } public Object invoke (...) { try { return method.invoke(impl, args); } catch (final InvocationTargetException e) { if (e.getTargetException() instanceof NoSuchEJBException) { // 1. look up EJB again // 2. try calling invoke again } } } } </code></pre> This code is by no means complete. Some of the code, such as looking up the EJB and invoking the method again has been omitted. Doing it this way will work. Another method would be to do something similar, but adding a separate method to the EJBs for checking for staleness, instead of using the method that the user attempts to invoke. What do you think? Is there a better solution?
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POjavax.ejb.NoSuchEJBException after redeploying EJBs
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USVetle
UserOwnerUserId
1. USVetle
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POjavax.ejb.NoSuchEJBException after redeploying EJBs
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.