It may be pretty basic question. But no luck Googling.
I was going through this URL. Because I had an issue accessing EJBs deployed on JBoss. After following this, it worked. Mainly this line.
jboss-ejb3-client.jar, jboss-aop-jdk50-client.jar, jboss-aspect-jdk50-client.jar and jbossall-client.jar -
all these .jar files are found in client folder of JBoss installation directory
But for a newbie of EJBs like me, this is following the steps without understanding the dependencies. So my question, can we find documentation like this somewhere? How do we know the jars we need to copy to client application classpath?
jbossall-client.jar for JBoss 4.X is enough - it contains all needed libraries.
For JBoss 5.X the story is more difficult - you need to reference in your project only jbossall-client.jar, but inside this JAR there are no actual classes, only MANIFEST file, which lists needed dependencies.
So, on JBoss 5, you need to have jbossall-client.jar added to classpath of your client plus all listed JARs lying next to it. Crazy, isnt't it?
JBoss 7 has sane approach. There is bin\client\jboss-client.jar that contains all dependencies needed by clients.
Related
I have an application that is currently running on JBoss AS but does not work on Glassfish. I'm trying to work through the documentation here but I'm having trouble figuring out things like what the file structure of the application should be and what (if any) additional files are needed. This documentation also refers to examples but to get the examples you need to install Netbeans and access an update tool tied to the glassfish instance installed with Netbeans. When I do this the server won't start, the update tool won't run, and I can't get the examples. Is there an easy way to get these examples (e.g. a simple download)? I've found other examples such as this one, but they are also dependent upon Netbeans.
Is there a simple and complete ejb/servlet example for Glassfish that can be simply downloaded and does not depend upon Netbeans or other IDE?
The obvious example is the Java EE CargoTracker. It was written to show what a "real" application might look like with pure Java EE APIs so should work on both JBoss and GlassFish. You will need Maven installed to build and run it, but there are more complete details in the readme for the project. Note that some of the information is a little out of date (mostly links to java.net which has been sunset in favour of a GitHub site) but the application itself is still a good example of Java EE 7 APIs.
https://github.com/javaee/cargotracker
I found the examples on github here:
https://github.com/javaee/glassfish-samples
To get and build the examples you will need Git and Maven. These examples are small, complete, and concise. The example that was helpful for my particular problem was this example:
glassfish-samples\ws\javaee5\enterprise\servlet-stateless-ear
It demonstrated that I needed to change the structure of my project such that the servlet was in a .war file and not in a .jar file in the lib folder of my project.
I need to connect to a mysql database via servlet. I understood that it's not enough to add the jar to the project (properties->java build path->add external), but I need also to add the jar to the classpath.
What means that? How to do it? I searched here for answer and didn't find, except the idea to copy-paste the jar to the src directory - that doesn't fix my problem.
My main problem is:
java.lang.ClassNotFoundException: com.mysql.jdbc.Driver
It depends on, which servlet container (== java web server) are you using. It is probably tomcat, but you need to share this information with us. My answer is for tomcat.
On tomcat, your application has somewhere a root directory (for example, /var/lib/tomcat/yourAppName on linux).
Below this directory, there is a lib subdirectory. This directory is already in your classpath, so it is enough to copy the needed jar into it.
There are much more complex solutions (for example, installing jars into the server classpath and into this application-specific lib directory), but these are probably unneeded in your case.
I'm a bit confused. I need to compile a project in jDeveloper 11.1.1.6.0. The server side of the project is deployed on the Glassfish server. On the machine of the project's creator everything compiles without any problems.
Using project properties -> Libraries and Classpath I added the libraries such as gf-client.jar, security etc. from $glassfish_home/glassfish/modules and some others (e.g. hibernate3.jar from hibernate dir).
When I try to compile the project I receive the following errors:
package javax.annotation.security does not exist
and
package javax.persistence does not exist.
I suppose that I miss some jars to include. I tried to find which jars (from Glassfish or from JDK) contain javax.annotation.* and javax.persistence.* but I couldn't.
If you have any ideas I would be thankful!
I was having the same problem and was able to solve it by adding a couple of dependencies to the Maven pom.xml file. See this answer for more details.
So I found the source of the problem. The application consists of 2 projects, of which only one (mentioned in the question) uses EJB. I'm not sure if it is the way it should be, but I tried adding ejb-files to another project. And after clean all and rebuild all it compiled like a charm for me. I hope this will help somebody in the future.
I am integrating security to my web MVC application and couldn't get idea what I have to do (What JARS required for it), so after some googling i found this link
Now I have download spring security 2.0.4 from spring security web site. In spring-security-2.0.4\dist folder there is some JAR files. There is some file with minimum changes e.g
spring-security-xxx-2.0.4.jar
spring-security-xxx-2.0.4-sources.jar
Please some body explain to me what is the difference between them. And which one is better from two of them to choose.
Note My existing MVC application is on spring 2.5.
I know its a very newbie question but I am learning security. Thanks
Just to clarify, this isn't really a security related question but rather a general code packaging question.
Jar files are actually just zip files and therefore can contain anything.
By convention a jar name that ends with -sources contains source code i.e. the actual .java files.
Jar files without the -sources contain the compiled java byte-code i.e. all the .class files. Essentially the files that you get when you run the .java files from the corresponding -sources jar through javac.
You only need the compiled .class files at runtime. That is why the two are split.
The -sources jar is useful at development time so that you can inspect the code that you are calling. This is especially useful if you are using 3rd party code that isn't well documented.
So i received a java api from a client and the main code is in main.jar. But the instructions he gave me require me to add these other jars (a.jar, b.jar, etc..) into the classpath whenever I want to use main.jar. These other supporting jars are things like Xerces, jakarta-oro, and a few other publicly available libraries. The problem is i don't know what versions they are, so i'm not sure if there would be issues if i just update the pom.xml file in my app to depend on main.jar and also have dependencies to these other jars as well with the latest versions of them.
Whats the best strategy for using main.jar in my maven application? I'm planning on adding main.jar to our internal maven repository, but what should i do about the xerces, jakarta-oro, and other jars when i dont know what versions they are?
Thanks
If you are lucky the file /META-INF/MANIFEST.MF inside a.jar, b.jar etc. contains an entry "Implementation-Version" or some other useful information which tell you what version they are. If not, you can download the latest release(s) from the project web site and check if they have the same file size as your bundled dependencies.
You may also come to the idea to bundle the dependencies with the main.jar in one big jar, but this may become funny, when you have the dependencies twice in your classpath at some point in the future...
What about just asking the client what version numbers this dependencies have?
If you don't have any information about these third-party libraries, just add them to src/resources/META-INF/lib and commit to SVN. That's the best way, if we're talking about black box approach.