JBoss Seam cannot create Java Persistence Entity Manager - persistence

I am at a complete loss with this one. I am scouring the Internet via Google to try and find a solution for this problem. I haven't used JBoss in a very long time, and we use Seam version 2 ... not sure what exact version. I've never used Seam before, so I don't know anything about this framework. My boss wrote most of this code, but he has moved beyond looking at this code, and has tasked me to fix this problem.
So, the problem is ... A user is logged into our Seam app, everything is fine, but when we try to load users from a CSV file, it's as if Seam forgets who we are, and then we get an error.
We have a UserIdentity class starts off like:
#Name("org.jboss.seam.security.identity")
#Scope(ScopeType.SESSION)
#Install(precedence = Install.APPLICATION)
#BypassInterceptors
#Startup
public class UserIdentity extends Identity {
In this class, we have one line of code:
EntityManager entityManager = (EntityManager)Component.getInstance("entityManager",true);
That is returning null, and hence we get an NullPointerException (NPE).
I presume that "Component.getInstance" fails, and it would be nice if we could refresh this and get it back again. It would be great if I could update to a newer seam jar and fix this.
I will continue to scour the Internet for a fix, but in the meantime, if someone has seen this issue, and knows how to fix it, that would be great.
Thanks!

When you use Component.getInstance method is used to get a reference to a Seam session bean component.
True end your context and creates again. As it is not finding that context It is returning null.
As the EntityManager is used in Session Scope, You don't have to Create it again.
Simple you can inject entity manager as,
EntityManager entityManager = (EntityManager)Component.getInstance("entityManager");
or
#In
EntityManager entityManager;

Related

How can I access one Eclipse RAP entry point from another?

I have an Eclipse RAP 2.3 application with two entry points, say /first and /second.
In the GUI of the first entry point, there is a button with which I would like to open the second entry point in a new browser tab. The event handler of that button is currently
UrlLauncher launcher = RWT.getClient().getService( UrlLauncher.class );
launcher.openURL( "/second");
This already doesn't work when the application is deployed as myapp.war in a Tomcat web server (should then be /myapp/second).
My questions:
What's the best way to determine the URL to open within the event handler?
Do I have to fetch the HttpServletRequest, get the context path and so some string manipulation?
Is it actually safe to call RWT.getRequest() at this point?
Update
According to RĂ¼diger's comment I can acquire the context path in two different ways.
The first approach is
RWT.getRequest().getContextPath();
where RWT.getRequest() is documented with
This method is not recommended
Secondly, I could obtain it with
ApplicationContextImpl ac = (ApplicationContextImpl) RWT.getApplicationContext();
String contextPath = ac.getServletContext().getContextPath();
where the IDE displays the warning
Discouraged access: The type ApplicationContextImpl is not accessible due to restriction on required library ...\org.eclipse.rap.rwt_2.3.2.20150128-1013.jar
Despite the warning, it still works when deploying a WAR file with OSGi bundles to Tomcat.
So, in both cases there is some kind of warning, which makes the solutions look rather like workarounds.
Using RWT.getRequest() is not recommended because usually RWT would shield you from the lower-level servlet API and certain direct interactions with the request could even interfere with RWTs life cycle and yield funny responses.
While in your case it would be safe to access the ServletContext via RWT.getRequest(), I recommend to use
RWT.getUISession( display ).getHttpSession().getServletContext();
to access the servlet context.
The second approach accesses internal classes that aren't part of the public API and therefore shouldn't be use. The accessed classes may change or be (re)moved in the future without further notice and break your application.

Database.SetInitializer not working

I'm facing a strange problem, I'm trying to run a method that explicitly migrates my database to the latest version withing EF code first, how ever when I run the method, nothing happened, heres my method that intends to migrate the database:
public void migrate()
{
Database.SetInitializer(
new MigrateDatabaseToLatestVersion<Alumnosdb, Migrations.Configuration>()
);
}
when I get to this method by way of debugging and hover over at Database, the connection states is closed and nothing happened.
Here is a snapshot where the problem occurs:
http://s8.postimg.org/r20k94ifp/errormigrate.png
Hopefully someone can point me on how to migrate my schema by way of code cause it seems the way that I'm trying to achieve this is not working, so any advice would be really appreciate it.
This just sets the initializer, not runs it. It will run when you actually use DbContext session.

Java Web App in Eclipse with Spring Framework not recognizing edits to controller

I was given an existing dashboard at work and am new to the whole Java Servlets with Spring Framework deal.
So the pages that are there work, and the flow is that there is the #RequestMapping annotation for the method inside the controller. For Example
#RequestMapping("/index.do")
public ModelAndView index() throws Exception {
LoginDO oLoginDO = new LoginDO();
return new ModelAndView("index","oLoginDO",oLoginDO);
}
The servlet.xml file maps the views to jsp files, and it's all working.
But my issue is, when I edit the controller.java file and create another method returning a new view, which is for a new page to the webpage, the change isn't being recognized by the servlet. It says "No matching handler method found for servlet request."
Now here's the thing, I believe this is happening because somehow the Spring Framework isn't being "updated" (don't know if this is the right term) when the edits are made in controller.java. I deployed my source code from a WAR file in Eclipse, then run it on a Tomcat server. Here's the deal, my mentor's code is working fine along with the edits, but I believe that he created a Tomcat project, and the project directories are different, and the edits are updated onto the website immediately after a save.
Note that when I change the JSPs to the existing pages, the updates are recognized immediately, it's only when I create a new JSP and a new #RequestMapping annotation along with a new method, it's not working. I even tried print statements within the controller.java and nothings showing.
So I guess this is an Eclipse question and deployment question more than anything, but any help would be great! Not too sure what to do to fix this. I've even tried restarting the server, to no success though. Thanks!
New #RequestMapping methods require the context to be reloaded (updated) to make them be available. When STS (Eclipse) detects changes on a spring bean it reloads the context automatically. If you are having problems with this try redeploying the project or restarting Tomcat.
Also, I wonder if you are you putting that new #RequestMapping method in a new Controller or in an existing one. If it's a new controller, have you added that Controller to the Spring Web Context (e.g. #Controller + component-scan or just adding the bean to de config file).

NoClassDefFoundError for EJB Home class

I'm using JBoss 4.2.3, EJB2, XDoclet and have deployed one EAR with the EJBs in it, and other EARs with various websites in them.
When trying to access an EJB from one of the websites, I get NoClassDefFoundError.
It seems that the lookup is successful. I can see, for example, that getContext().lookup(SecurityServiceRemoteHome.JNDI_NAME) returns something of class "$Proxy266". I also see in JBoss's JNDI View this binding:
remote (proxy: $Proxy266 implements interface com.icumed.ifactory.service.session.SecurityServiceRemoteHome,interface javax.ejb.Handle)
FYI, SecurityServiceRemoteHome.JNDI_NAME = "ejb/ifactory/SecurityService/remote"
Right after the lookup, I call this, which is where the error is thrown:
home = (SecurityServiceRemoteHome)PortableRemoteObject.narrow(obj,
SecurityServiceRemoteHome.class);
I've heard that this might be unnecessary and I can just do a straight type conversion here, but I don't think that's the problem. From what I've read on the web so far, it seems like maybe the SecurityServiceRemoteHome cannot be fully loaded. Perhaps some ancillary classes are missing? I don't see any errors indicating this, though. What's the best way to go about debugging this?
After even more digging around, I found the answer. It has to do with the jboss-app.xml file and the loader-repository element. The background is that I previously had one complete EAR file with all the WARs and EJBs in it. I have decided to break them apart, and when I did so, I modified the jboss-app.xml files so that the archive name was different for each one. That was wrong. They must be the same between the EAR for the EJBs and the EARs for the WARs (Yes, I don't really need an EAR file if it's just a WAR...except on OC4J). Furthermore, I must have the loader-repository element present with an archive name. Leaving that out causes other problems.

Wicket 1.4 EJB Support

I tried implementing the JavaEE Inject jar from Wicket Stuff. (glassfish v3, wicket 1.4)
- however, the code given in the tutorial doesn't work
method
addComponentInstantiationListener in
class org.apache.wicket.Application
cannot be applied to given types
required:
org.apache.wicket.application.IComponentInstantiationListener
found:
org.wicketstuff.javaee.injection.JavaEEComponentInjector
looks to me like the API has changed. The JIRA link inside
http://wicketstuff.org/confluence/display/STUFFWIKI/JavaEE+Inject
and the Repository link are both broken. Is it still maintained?
Another short question: Is it possible to populate ListView directly with entity beans? I'd like to avoid too many proxy classes.
Thanks in advance
Yes, you can inject a ListView with entity beans. You should do so by creating an implementation of IDataProvider (or one of it's sub-interfaces) for the iterator and have it wrap the entities with LoadableDetachableModel so they can be reloaded instead of serialized as a part of the session.
Figured it out: I didn't expect there to be a difference between 1.4.13 and 1.4.14 but apparently the API changed there significantly.