Re: Struts2 + JPA + JSON - Help with error
Nathan Schulte nathan.schulte at ngc.com writes: Nathan Schulte nathan.schulte at ngc.com writes: here, http://article.gmane.org/gmane.comp.jakarta.struts.user/170543, http://article.gmane.org/gmane.comp.jakarta.struts.user/170543 Here is a link to the error, http://pastebin.com/m5d0d22c8. http://pastebin.com/m5d0d22c8 Also, here is the exception report (of a similar action) given as the HTTP response: http://pastebin.com/m21348ec5 I have found a fix for this issue. As it turns out, because the JSON Plugin is using reflection, and the entities the JSON Plugin is reflecting on are using Hibernate/JPA lazy initialization magic, the JSON Plugin was serializing the magic as well. This magic contains references to underlying JPA implementation, which also contains references, which also contain references, all the way down past the JDBC layer. I didn't go as far as to find out what was causing this particular error/exception, but simply knew that I don't want the Plugin to serialize the hibernateLazyInitializer instances in my entities. The Plugin supports property exclusion via regex, thus the simple fix. Hey, perhaps this property exclusion property will come in handy to keep from loading the whole database into memory for those self joins I have on my entities... :P. On another note, although this fixes my particular issue, perhaps there is some more elegant solution to help with anything implementing this (or other problematic) OOP patterns. -Nate - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Struts2 + JPA + JSON - Help with error
Hey all, I've got an issue I can't seem to solve. I'm using Struts2 with the JSON Plugin. The error I am receiving is below. This occurs when trying to access the Action. I am not sure why this error is being thrown, but I believe it has something to do with the way I implemented the Open Session in View pattern. The Action consists of querying via JPA for a List of entities, and returning ActionSupport.SUCCESS. The Action has a single result, result name=success type=json/. The entities that the list consists of have lazily fetched associations. My solution to the Open Session in View pattern is described here, http://article.gmane.org/gmane.comp.jakarta.struts.user/170543, and works for other result types (specifically the dispatcher type). Here is a link to the error, http://pastebin.com/m5d0d22c8. Thanks! - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: EJB Injection in Interceptor
Robin Mannering robin at mtndesigns.co.uk writes: http://cwiki.apache.org/S2PLUGINS/ejb3-plugin.html Are you using that plugin, or the following? http://cwiki.apache.org/S2PLUGINS/ejb3-jboss-plugin.html With the JBoss plugin, I am able to use Local interfaces rather than remote. I can show an example of this as well if you think it might help. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Struts2 + JPA + JSON - Help with error
Nathan Schulte nathan.schulte at ngc.com writes: here, http://article.gmane.org/gmane.comp.jakarta.struts.user/170543, http://article.gmane.org/gmane.comp.jakarta.struts.user/170543 Here is a link to the error, http://pastebin.com/m5d0d22c8. http://pastebin.com/m5d0d22c8 Also, here is the exception report (of a similar action) given as the HTTP response: http://pastebin.com/m21348ec5 - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Struts2 + JPA - Lazy Initialization During View Generation
So is this the only resolution out there? To lazily initialize the contents I know I'll need before the container decides to trash the persistence context? There is no way to extend the context such that the lazy initialization will work when rendering the view? - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Struts2 + JPA - Lazy Initialization During View Generation
Jim Kiley jhkiley at summa-tech.com writes: I assume that the OpenEntityManagerInViewFilter is not the solution for you? I'm not using Spring. As such, I'm not familiar with this filter, but from the description, yes, that is what is needed. However, the app server manages the transactions, and injects the EntityManager when needed. I can do a JDNI lookup and receive an EntityManager, but I'm unsure of where this would actually need to be placed (an interceptor? in the action, to be placed on the stack somewhere(so a reference is held?)). - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Struts2 + JPA - Lazy Initialization During View Generation
Wes Wannemacher wesw at wantii.com writes: This is not exactly what you want, and it's based on Hibernate and a hibernate session, but if you think of hibernate sessions as jpa EMs, then you can just make the appropriate changes to this and at least be further than you are now. Thanks Wes, I don't know how I didn't catch that page when browsing the docs. That's actually very similar to the interceptor I just started working on. I'll let you know what I come up with. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Struts2 + JPA - Lazy Initialization During View Generation
Nathan Schulte nathan.schulte at ngc.com writes: I'll let you know what I come up with. Well, I was able to get this to work. The interceptor is placed on the end of the stack, although it's location oughtn't matter. Also, it is placed on the stack for _all_ actions. I'm not sure if this is a problem, it may actually be a good thing (at least in my case, I was not wrapping all of the actions' calls to the EJBs in a UserTransaction, this takes care of that, everywhere). Also note, this doesn't support transaction rollback in it's current form. As a simple test, it worked though. This would look ten times prettier if only the container supported resource injection, :). http://pastebin.com/f3c76ae6f -Nate - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
EJB Injection in Interceptor
This may be more related to XWork2, but I'll start by asking here. I'm creating a custom Interceptor to handle user permissions for an application. Rather than redirecting to an action to actually process a login attempt (requiring a custom result type), the Interceptor itself will process the login attempt. However, in order for this to work, the Interceptor needs access to a session bean that is the interface to the persistence layer. Is it possible to use the Java EE 5 @EJB annotation to inject an EJB, or even the Inject EJB Plugin? I've tried both, and neither seem to work (both result in a null object reference). I realize I can use a JNDI lookup to get a reference to the bean, but I would much rather use injection if possible, as that's why it's there. Thanks! -Nate - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: EJB Injection in Interceptor
Nils-Helge Garli Hegvik nilsga at gmail.com writes: The short answer - You have to do the lookup yourself. :/ The long answer - There's a similar discussion going on that pretty much covers the topic: http://www.nabble.com/Struts2-Action-Class-and-EJB-Injection-td24497801.html Yes, I'm familiar with this issue. I guess, in order to resolve it in an Interceptor as opposed to an Action (the method of using an Interceptor and reflection to do the injection), one would have to do the same for the Interceptors... Oh well, you can't win all of the time. Thanks for the speedy reply! - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: EJB Injection in Interceptor
Wes Wannemacher wesw at wantii.com writes: Seems to me that my idea to create an ObjectFactory based plugin ... needs to pick up some steam. I only have one question for the EJB users out there... Do you guys need Spring integration as well? To answer your question, _I_ personally don't need Spring integration. I've never used Spring, and for this project, it was too much overhead to learn (on top of Java EE, the JPA, Hibernate intricacies, Struts2...), and from what I understand, it seemed like using it and S2 together provided duplicate functionality (another topic altogether...). On another note, I find it awesome that the community (or whatever group you're part of) is so willing to provide support. I mean, in my eyes, this is something that I could see myself writing to make my coding easier, it's just that given my situation, it's easier to use the workaround. Admittedly, I'm not very familiar with JEE5. Some of this is still black magic, and I don't fully understand the issue, I just know enough to understand that the architecture permits it as an issue (and not everyone is just blowing smoke my way) and can leave all of the intricate details be, as they don't directly affect my project. -Nate - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Struts2 Action Class and EJB Injection
Robin Mannering wrote: Is there anybody that is using Struts2 as the 'frontend' to an EJB 3 'backend' and what solution do you currently employ. I am using the described setup, yes. Our solution was to use the mentioned EJB3 plugin and it's @InjectEJB annotation. It works well, I have not had any issues thus far. Wes Wannemacher wrote: Would anyone else be interested in an ObjectFactory based plugin? If so, would any of you also want it to work with Spring? I am interested in this, particularly for supporting persistence annotations, like the aforementioned @PersistenceContext. Most of the persistence support that I have seen for struts, and the questions posted regarding persistence, all seem to be using application managed persistence. Getting things to work with CMT would be excellent. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Struts2 + JPA - Lazy Initialization During View Generation
I'm currently using Struts2 in a project that is utilizing the Java Persistence API (JPA, specifically Hibernate) with container managed transactions (CMT). To access the Persistence layer, a layer was created using SLSBs as service objects which provide simple entity_type getentity_typeById( int ) and Listentity_type getentity_types() type methods. The Struts2 Actions use these beans (by injection (provided by some interceptor, such as the EJB3 Plugin) or a JNDI lookup, it doesn't matter really) to get the instances of the entities. Up until now, all of the properties of the entities that were being accessed to create the view were either eagerly fetched associations, or private members of the entity. Recently, I have the need to start using lazily fetched associations (self joins and the like), and need to find a way to extend the Persistence context through to the view generation. Although there isn't much need to explain, the error I am receiving is the following: ERROR [LazyInitializationException] failed to lazily initialize a collection of role: private_member_name, no session or session was closed I noticed recently that there was a Full Hibernate Plugin that supports injection of a Session (presumably into an Action?) and will close the Session after the view generation. This works fine for application managed persistence, but does not solve the issue of when using CMT (or at least to my knowledge). Searching the web for solutions to the problem resulted in a suggestion to create an interceptor (that runs after the Action, but before the view generation?) that does a JNDI lookup to create an EntityManager (extending the Persistence Context to the interceptor, I think). I'm not sure what this was supposed to resolve, but I have not tried this as 1) I'm not sure how to create such an interceptor and get it to intercept at the appropriate time, and 2) I don't think this would resolve anything, as I don't think this would really extend the Persistence Context through to the view generation. How are others resolving this issue and using lazy initialization? I have a few more ideas as last resorts, but I don't want to taint the responses, so I will hold onto them for now. Thanks, -Nate - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Struts2 Action Class and EJB Injection
Robin Mannering robin at mtndesigns.co.uk writes: Can you please tell me how you obtained the EJB plugin and a short example of using it. I would prefer to use this if possible. Sorr, I misspoke earlier. I'm actually using the EJB3 JBoss Plugin, from here http://cwiki.apache.org/S2PLUGINS/ejb3-jboss-plugin.html. However, browsing the source for the EJB3 Plugin, the annotations and even classes are named the same, so the following example should still apply; http://pastebin.com/f7053a2bc. - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: Struts2 + JPA - Lazy Initialization During View Generation
David Canos davidcanos at gmail.com writes: I use a Hibernate.initilize() call in the DAO layer for every object I need to see in the presentation layer (common jsp files).it avoids Lazy Initializations without passing Hibernate Proxy around layers. This was one of my last resort ideas. It completely flies in the face of lazy initialization, by proactively initializing them. Obviously something I want to avoid. There ought to be no need to pass around a hibernate proxy at all, the container should take care of everything for you, that's the point of CMT. I know there has to be a proper solution out there, I just have to wait for the right person to stumble onto the mailing list. Thanks for letting me know that this method does indeed work though. I have not tested it myself, but at least I know now that not _all_ hope is lost. -Nate - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
