Several REST and EJB problems - rest

I'm trying to deploy a Java EE web application with RESTful web services and an EJB connexion to another Java EE application.
I'm experiencing several problems and I fail to write down every specific question, so I have no choice but tell you all in a row.
1) First, I am using Tomcat to run the app and I cannot get EJB connexion to work. No matter what, I get a JNDI error : NamingContextFactory class not found. Why ?
My JNDI connexion is as follows :
String hostname = "localhost";
String port = "1099";
String url = "jnp://" + hostname + ":" + port + "/";
Properties h = new Properties();
h.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory");
h.put(Context.PROVIDER_URL, url);
h.put(Context.URL_PKG_PREFIXES, "org.jboss.naming.client");
initialContext = new InitialContext(h);
2) Therefore, as the server used is not relevant, and as the app I'm trying to connect to is using JBoss (4.4.2.GA), I tried to deploy my app under the same JBoss. I cannot get it to deploy, I have a REST problem: ClassNotFoundException: javax.ws.rs.core.ApplicationConfig at deploy time.
2.1) I am compiling with Netbeans and the ApplicationConfig.class is not part of the 1.1 version of the JAX-RS api jsr311-api-1.1.jar I'm using at compile time. The implementation of the library was changed since 0.8 version, which I was using before, but I had to upgrade the jar because it didn't include #FormParam. Until now, I had found a workaround using com.sun.jersey.api.representation.FormParam instead but Jersey is not compatible with JBoss as far as I understand.
Why is the server looking for ApplicationConfig while it's not used in the war?
2.2) I understood I had to use RESTEasy, and JBoss 4 does not include it, so have to install it manually. But the RESTEasy doc suggest that I thoroughly modify my project my adding a lot of jars, servlets etc. From my point of view, I simply need a RESTful implementation on the server libs to which my JAX-RS API, which is only an interface, will refer once the app is deployed. I may have some serious misconceptions about how Java EE libraries linking work. Please help.
So I know there are several different problems here but I couldn't manage to separate them. I have lost so much time on this that I'm worried for my project. Thanks in advance.

Related

Error when deploying legacy application to Websphere Liberty

I'm having issues when trying to deploy a somewhat legacy application to Websphere Liberty to facilitate development.
The application runs fine in regular Websphere Server 8.5.5 but won't start in Websphere Liberty. We have another legacy application based on mostly the same technologies/frameworks that runs ok. Unfortunatelöy we won't move to a newer platform anytime soon.
I have the following features configured for my server:
<featureManager>
<feature>localConnector-1.0</feature>
<feature>jpa-2.0</feature>
<feature>jsf-2.0</feature>
<feature>jdbc-4.0</feature>
<feature>servlet-3.0</feature>
<feature>ejbLite-3.1</feature>
<feature>cdi-1.0</feature>
<feature>appSecurity-1.0</feature>
</featureManager>
When I try to start it I get an exception during annotation processing:
[VARNING ] CWNEN0047W: Resource annotations on the fields of the xxx.xxx.EditCardGroupBacking class will be ignored. The annotations could not be obtained because of the exception : java.lang.NoClassDefFoundError: javax.resource.spi.IllegalStateException
whiich seems strange since this would be a part of the JRE?
I have searched various forums/pages for an answer but can't faind the answer. Hopefully someone here can be of assistance.
I'm happy to provide more details of configuration and setup if needed.
javax.resource.spi.IllegalStateException is part of the JCA (Java EE Connector Architecture) specification (see JavaDoc here). You do not get it automatically from Java. Try enabling the jca-1.6 feature,
<feature>jca-1.6</feature>
FYI - if anyone else hits this who has newer level Java EE features, they would instead need:
<feature>jca-1.7</feature>

How does using the javax.ws.rs-api-2.0.jar works at runtime as it is only the API

We were working on creating a RESTful service. We have thought of using frameworks like jersey or cxf. But apparently we found that just using the javax.ws.rs-api-2.0.jar and the related annotations, we can get the service working.
Question is:
How does it work? Is it dependent on the application servers?
What if we application server does not support or have the implementation of the API?
If it is dependent on application servers, can I find out the library which the server is using especially tomcat?
EDIT 1
This question is invalid. javax.ws.rs-api-2.0.jar is just an API. Using this jar does not suffice. It will not give compilation errors.
But at run-time, you need providers which will implement the rs-api. And thus we need the frameworks like jersey or cxf.
In our application, these jars were added to the war during ant-build from external location and that is why it confused us.
I am closing this question.

Netbeans Web Service Client not found

I've always used eclipse before, but I'm using Netbeans for the first time because of it's integration with Web Service clients.
However, after following multiple tutorials, the way to add a web service client is to:
https://netbeans.org/kb/docs/websvc/flower_swing.html
Make a new project
Right click on your project, New->Other->Other->Web Service Client
However, I do not have the web service client option available, not sure what I am doing wrong.
Please mention the net beans version you have. You should use newer version of the IDE to use latest features.
For other developers who will face this problem like me, I will leave my answer here.
I'm currently using Apache NetBeans IDE 11.0 and it's in Web Services -> Web Service Client. If you still cannot find it, just use filter feature. I found it with filter.

Deploying .ear file (contains rest services)

I have a few questions about deploying my .ear file (was provided to me, the file itself should not be the problem). I set up jBoss application server jboss-6.0.0.Final and was able to run a simple hello world app to ensure the server was functioning properly.
I was told to place the .ear file in /server/default/deploy so I did. When I ran jboss (through /bin/run.bat) I got no errors related to deploying the ear file.
Question
Is this all the software I need (jBoss)? Do I also need something like Apache or tomcat?
The .ear file contains RESTful service calls that should return xml. Will these be deployed (accessible through a jQuery ajax call after the server (jboss/bin/run.bat) is executed?
Currently when I try to make the calls, the resources do not seem to exist.
Thanks in advance for taking the time to help.
JBoss AS ships with an embedded Tomcat as a servlet container so you really don't need that anymore. Apache Web Server is NOT required for your .EAR to be deployed properly.
To answer your questions
No other software is needed to deploy the EAR. You simply copy your EAR file to deploy directory (which you have rightfully done so).
If your EAR contains RESTFul services, they will be deployed and you can access them using any client including jQuery or even a simple browsers. The trick is to know the access URL to the RESTFul services.
If you have difficulty identifying the URL for accessing your RESTFul services please refer [1] for more information.
Hope this helps.
Good luck!
[1] https://docs.jboss.org/author/display/AS7/JAX-RS+Reference+Guide
I can answer the first question. You need apache if you want to serve static content or you need to isolate the traffic (say keep apache in the dmz and then use apache to proxy traffic to the internal jboss servers). tomcat is bundled along with jboss, so you do not need it.

JMS without JNDI?

We are running portlets in WebSphere 6.01, using Java 1.4. We want to send JMS messages to a JBoss 5 queue, running Java 5 (or maybe 6, but it's certainly newer than 1.4). Trying to connect using JNDI is not working, since we have to include the JBoss client jars in the classpath of the portlet, and they are Java 1.5. So I get an unsupported major/minor error when I try to create the InitialContext.
Can we connect straight to JBoss without using JNDI? Or is there some way to get around this issue I can't think of?
Even if you were able to connect to JMS without going through JBoss's JNDI, you would still need to include the JBoss client JAR in order to use JMS. Both JNDI and JMS are APIs, and you need the server's implementation of that client API in order to talk to the server.
If it's just your JNDI classes that prereq Java 5 and not the JBoss classes then you can do this. But you would have to set all of the properties of the objects and that is provider-specific. The WebSphere MQ JMS samples show how to do this with WMQ and you would need to know the property and value names for JBoss to make the equivalent code. Here is a code snippet from the WMQ JmsProducer.java sample:
JmsFactoryFactory ff = JmsFactoryFactory.getInstance(WMQConstants.WMQ_PROVIDER);
JmsConnectionFactory cf = ff.createConnectionFactory();
// Set the properties
cf.setStringProperty(WMQConstants.WMQ_HOST_NAME, host);
cf.setIntProperty(WMQConstants.WMQ_PORT, port);
cf.setStringProperty(WMQConstants.WMQ_CHANNEL, channel);
cf.setIntProperty(WMQConstants.WMQ_CONNECTION_MODE, WMQConstants.WMQ_CM_CLIENT);
cf.setStringProperty(WMQConstants.WMQ_QUEUE_MANAGER, queueManagerName);
// Create JMS objects
connection = cf.createConnection();
session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
if (isTopic) {
destination = session.createTopic(destinationName);
}
else {
destination = session.createQueue(destinationName);
}
producer = session.createProducer(destination);
On the other hand, if your JBoss classes prereq Java 1.5 then you need to run Java 1.5 or better.
Depending on the JBoss version you can directly instantiate all the JMS objects.
One particular version:
see http://www.jboss.org/file-access/default/members/jbossmessaging/freezone/docs/usermanual-2.0.0.beta1/html/using-jms.html
(Section 5.5. Directly instantiating JMS Resources without using JNDI)
I think JNDI is the only way that you can create JMS connection factories and destinations (queue or topic), and these are your means of communication.
In fact using JNDI is a way to be independant of the JMS provider, because you can easly change it.
But if you've got no problem with that most provider offer facilities to create a connection factory and destinations
It sounds like the problem isn't with JNDI but with the conflicting classnames between the environments.
You could try doing the classloading yourself when you try to instantiate the JBOSS client classes. That way you get a separate classloader from the one that loaded the Portlet. Just make sure you understand whether you need Parent-first or Parent-last behavior. Also on that page is debugging classloading which can show you how to set the Classpath for the classloader so you can isolate the JBOSS libraries and avoid classname collisions. It is a good resource for understanding even advanced classloading issues.