I have an application developed on RAD using WAS 6.0. I migrated the code to WID 7.0. After making some changes in the EJB modules(Had to remove the bnd.xmi file from each ejb module to deploy the application on Application Server)the application is running fine, but the EJB modules give the following error:
NamingException has Occured While Getting Local Home
javax.naming.NameNotFoundException:nullName ejb/com/igcc not found in context "local:".
I am not able to figure out what changes do it need to make to run the application on WID.
Any help is appreciated.
Thanks,
Ayush
Well, the "bnd.xmi" files you deleted are the WebSphere-specific deployment descriptors, containing binding information. One of the things that are mentioned there is the name under which to bind each individual EJB home.
You cannot possibly run an EJB module without this binding information existing somewhere.
If you delete these files (which are generated by RAD), you have to assign new binding information from within the administration console, or via your wsadmin-based deployment scripts.
In short... lets start by recovering those files that you erased. :-)
Related
Hello Everyone!
I'm deploying a multi-module project on JBoss and with the help of HotswapAgent( GitHub ) and DCEVM.
The Problem is that the deployment loads with hotswap-agent but it doesn't reload the classes when I perform any changes!
I read the configuration for JBOSS modules in HA-Agent : Configuration
but I can't seem to understand the following:
Add extraClassPath from hotswap-agent.properties to org.jboss.modules.ModuleClassLoader, so that all application servers (JBossAS, WildFly) based on jboss’s module classloader can use HotswapAgent’s extraClassPath
I mean as in I added extraclass path properties to my HA-properties files but how do I transfer them to org.jboss.modules.ModuleClassLoader.
Also if there is any other cause that might be preventing HotswapAgent from reloading classes in JBoss then do tell me! As all plugins load correctly but when I make changes ( In intelli J using HA plugin ) and build the class after changes then I get no message from HA in the console that the class has been reloaded nor does it show any effects from the changes.
We are trying to setup JackRabbit Oak on one of our Linux machine with IBM WAS application server and facing some issues starting the sever on WAS.
The Apache JackRabbit is a content repository which is a hierarchical content store with support for structured and unstructured content, full text search, versioning, transactions, observation, and more. We are using it for storing digital assets in structured form (specifically, as a tree) as per our requirement.
We have a REST application and another application DAM (Digital Asset Management) which handles creation of repository, providing connection with the repo whenever requested (Singleton), creating nodes, etc. on the repository. In our local development setup we have exported this DAM as a JAR, say dam.jar and have put this in REST application’s class path. We have JackRabbit Oak’s JAR (oak-run-1.4.11.jar), which we have put in class path of DAM application.
While doing a similar setup on Linux machine on WAS application server, we are using the same dam.jar which is created by exporting the project as a JAR in eclipse on Windows machine. We put this in REST application’s class path on WAS by configuring this in the server on which REST app is deployed.
While debugging we found that application is able to access classes from dam.jar, but when DAM’s class tries to call JackRabbit’s classes it fails throwing java.lang.NoClassDefFoundError. We tried putting JackRabbit’s JAR (oak-run-1.4.11.jar) in the class path on WAS by configuring this for REST app’s server, but then server fails to start.
Attached is the log file: /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/servers/RESTAPP/configuration/1489493294429.log
There is nothing much inside server logs from /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/RESTAPP (RESTAPP is the server name for our REST application), below is the snippet:
[3/14/17 17:38:04:872 IST] 00000001 ModelMgr I WSVR0801I: Initializing all server configuration models
[3/14/17 17:38:08:564 IST] 00000001 WorkSpaceMana A WKSP0500I: Workspace configuration consistency check is disabled.
[3/14/17 17:38:08:834 IST] 00000001 AdminTool A ADMU3200I: Server launched. Waiting for initialization status.
[3/14/17 17:38:18:241 IST] 00000001 AdminTool A ADMU3011E: Server launched but failed initialization. Server logs, startServer.log, and other log files under /opt/IBM/WebSphere/AppServer/profiles/AppSrv01/logs/RESTAPP should contain failure information.
We suspect dam.jar here, as this has been created from our eclipse workspace by exporting it as a JAR file and this might need some extra information to have this JackRabbit Oak libraries included in that.
We are putting classpath entries in Application servers > RESTAPP > Process definition > Java Virtual Machine of WAS.
Thanks
I would try creating a "Shared library" in Websphere and putting your JackRabbit dependency jars in there:
Environment -> Shared libraries -> New...
Set then name "Jackrabbit", and then in the Classpath box add the paths to your jars.
Then in your REST application (Applications -> Application Types -> WebSphere enterprise applications -> [your application name])
Click "Shared library references" under "References"
Select the application and click "Reference shared libraries"
Select the Jackrabbit shared library and click the right arrow to reference that shared library from the application.
Classloading in WebSphere is very complicated -- see chapter 22 of the WebSphere Application Server V8.5 Administration and Configuration Guide for the full description. Trying to add classpath entries at the JVM definition level definitely won't work.
To piggyback on Andrew's answer above, the real key is to make sure that both dam.jar and oak-run-1.4.11.jar are within the same class loader, and that they are NOT in a server-level class loader - putting custom code in the server JVM class path makes it visible to the server runtime and can actually override server classes (which is probably why your server init failed after doing that).
The very easiest answer, assuming this is a simple web application, is to put both jars in the WEB-INF directory of your WAR module. Both will be loaded by the web app class loader, and they'll be able to see each other. If there's some reason you don't want them in the application itself, then Andrew's shared library suggestion would have the same practical effect.
I have worked on implementation of the Entity remote service.
I have created one custom service method in EntityServiceImpl,Created custom service method providing service through InstitutionServiceUtil.
After deploy the portlet, while sending request to service method through from browser window,I am getting below Exception
exception":"java.lang.ClassCastException: com.institutions.model.impl.InstitutionImpl
cannot be cast to com.institutions.model.Institution
Note: If I send the request after restart the server, I didn't get above exception.
How to resolve the above Exception?
I assuming that InstitutionImpl implements the interface Institution. If so, then the root cause of the exception is classloading: Classloader A did load Institution but InstitutionImpl was loaded from a different classloader. Two classes in Java are only equivalent if the fully qualified name and the classloader are the same.
I don't know enough about liferay to tell you how it's class loading works. But to solve the problem, you need to find out if the Institution interface could already be around when you try to load your implementation (maybe from a previous deployment attempt).
While deploying the portlets that throws the class cast exception, do the following:
deploy the application in the liferay/deploy.
shutdown the liferay
move the service jar from the WEB-INF/lib from the portlet to the /lib/ext of the tomcat
remove the temp and work folder from the tomcat
restart the tomcat.
OR ...what worked for me was
change the package name while building the service.xml in the service.xml file
Or if you have already built the service, do these steps
Just delete the 5 packages that are created from the service builder,
i.e
model.impl
service.base
service.http
service.impl
service.persistence
delete the .xml generated in the META-INF folder except for the file ext-spring.xml
delete the XX-service.jar from the docroot/lib folder
delete the service folder in the docroot folder.
change the package name in the service.xml and build the path.
I've got an issue deploying an application that contains one custom tag I've made.
Every times that I try to test the application, I get this error:
Deployed application at context path / but context failed to start
C:\\NetBeansProjects\\nbproject\build-impl.xml:1048: The module has not been deployed.
I followed this guide up to before "Accessing the Tag Body" chapter.
I have a little doubt in this part:
Let us compile above class and copy it in a directory available in environment variable CLASSPATH.
I have to create a CLASSPATH variable between Windows System's or User's variables, but which path I have to put into? The MyCustomTag.java class's path? Maybe this could be the problem.
I use NetBeans 7.4 with Tomcat 7.0.41 and Struts2.
I created a Netbeans Platform Application using Netbeans 7.0.1 and the JDK 1.7.
I implemented my own Web Application on a normal module using Embedded Jetty 7.4.5 (consisting of a Web Service and a couple of servlets), and I created a Library Wrapper Module including all the Jetty jar files and the "jetty-j2sehttpspi-7.4.5.v20110725.jar" that I needed to be able to publish the Web Service's Endpoint. The Web module has a dependency on the Jetty module.
The code I'm using is this:
System.setProperty("com.sun.net.httpserver.HttpServerProvider",
"org.mortbay.jetty.j2sehttpspi.JettyHttpServerProvider");
server = new Server();
JettyHttpServerProvider.setServer(server);
//We read the config file
String[] configFiles = {"etc/jetty.xml"};
for(String configFile : configFiles) {
XmlConfiguration configuration =
new XmlConfiguration(new File(configFile).toURI().toURL());
configuration.configure(server);
}
// Web Services
QueryWeb qWS = new QueryWeb();
Endpoint.publish("http://0.0.0.0:" +
(server.getConnectors()[0].getPort()) + "/ws", qWS);
// Servlets
HandlerCollection hc = (HandlerCollection)server.getHandler();
ServletContextHandler sch =
new ServletContextHandler(ServletContextHandler.SESSIONS);
sch.setContextPath("/web");
sch.addServlet(stream.class, "/stream");
// We add the servlet handler to the server's context handler collection
// because it's the one used by the Web Service Endpoint
ContextHandlerCollection chc = (ContextHandlerCollection)hc.getHandlers()[0];
chc.addHandler(sch);
server.start();
When I try and run the application, I get the following error after the "Endpoint.publish" call:
Exiting C:\Program Files (x86)\NetBeans 7.0\harness\run.xml.
Exiting C:\Program Files (x86)\NetBeans 7.0\harness\run.xml.
C:\Program Files (x86)\NetBeans 7.0\harness\suite.xml:500:
The following error occurred while executing this line:
C:\Program Files (x86)\NetBeans 7.0\harness\run.xml:225:
The following error occurred while executing this line:
C:\Program Files (x86)\NetBeans 7.0\harness\run.xml:193:
The application is already running within the test user directory.
You must shut it down before trying to run it again.
As far as I understand, this is happening because the system can't find the "org.mortbay.jetty.j2sehttpspi.JettyHttpServerProvider" class. Therefore it defaults back to the web server included in the JDK, which causes a conflict since we get both web Servers (Jetty and the JDK's) trying to run on the same port (in this case it's 8081).
The only way I managed to fix this problem was by copying all the Jetty jar files into the JRE's "lib/ext" folder (copying only the "jetty-j2sehttpspi-7.4.5.v20110725.jar" results in no errors, but the server won't start). In this way the system can find the class it needs and all it's dependencies.
I suppose that what's going on is that even if NetBeans uses it's own classpath loader, the System.setProperty method is ignoring this and trying to access the standard classpath, and since a NetBeans Platform Application doesn't actually let you change the classpath directly (that would beat the whole purpose of having modules administered by the NetBeans platform), I don't really know how to make it use the library included in the wrapper module.
I can keep developing the application with the temporary solution I found, but honestly, copying stuff into the JRE folders is not an acceptable solution and will eventually result in distribution and installation problems in client machines (already tried it in a Mac OS machine and I didn't even know where the JRE kept it's libraries to try and do the same dirty trick).
Therefore I want to ask you guys if there is any solution to this particular problem or if anyone has a better explanation of what's going on and how I might fix it without having to recreate the whole architecture of my project (which actually works OK except for this little inconvenient).
Thanks in advance!
Write your question to the mailing list, dev#platform.netbeans.org, and you're more likely to get an answer.