I was curious about what being a "shared J2EE library" means, and the things that I should consider prior to saying that my JAR is a "shared J2EE library".
According to the Oracle docs, a shared J2EE library can be a "single, simple JAR". What does the term "simple" mean in this situation?
Are there restrictions on what a simple JAR that is a shared J2EE library can do or not do? Can my JAR spawn threads, do network I/O etc.? I understand that the J2EE framework was originally designed with libraries being treated as beans originally, and this bean design had some set of restrictions (eg. they weren't in charge of threads, network I/O etc.). But it seems like if I simply want my JAR to be a shared J2EE library, these restrictions for beans do not apply.
Finally, should my library be following the list of best practices for shared J2EE libraries, even if it is not a J2EE library, so that client web applications which refer to my library can follow best practices? Eg. Should my library be publishing both the "specification version" and "implementation version" and adhere to their semantics, or is this not our concern once we state we are not a shared J2EE library.
I think you're a bit confusing about java library and J2EE library.
Each JAR can be a java library. There are a lot of examples: Spring, apache-commons, junit, etc...
All that you need to do in order to use a JAR as a library in your application is include it in your classpath.
Those JARs can perform all the standar task provided by java API: Sockets, NIO, files, concurrency, etc...
You can configure your server to load this kind of libraries (just a normal JAR) into your applications. In this case, the server will include all the content of the JAR in your classpath automatically, but it does not resolve any J2EE annotation from it (#EJB, #Inject, etc...)
On the other hand, a J2EE shared library can contains J2EE objects. That's, it can contain EJBs, Servlets, and so on.
Related
My task is to make a small a project for start my ee studies. Till now, I learned standard java, but i don't get what ee means exactly, how my project would be an enterprise stuff. Has it a different syntax or different setup in IDE? I know it's not a clever question, but I really don't know where to start. Do you have any idea for start a project?
Java EE is no different language or has no different syntax than Java SE. It's built on top of Java SE and comprises a set of standardized APIs and libraries that are helpful for solving problems in an enterprise context.
To name a few:
Web Applications (Servlets, JSPs, JSF, WAR-packaging)
RESTful- and WebServices (Jax-RS, Jax-WS)
Persistence (EJB, JPA)
Context Dependency Injection (CDI)
Security
Batch
Messaging
...
Further it defines a runtime environment - an Application Server - to run enterprise applications. Nevertheless, the classic application server model has become somewhat obsolet, nowadays you either run a single application in an application server or use only parts of the libraries and APIs and embedd those in your applications.
So basically, all you need is an IDE and the libraries. When you're using maven as build environment, all you need is the java-ee maven dependency, see Maven Central
Usually you don't need to know all the libraries and APIs of Java EE in detail, it's good to know what is available out-of-the-box (so you don't reinvent the wheel), but you hardly will need all of them in all of your projects.
I personally avoid JSF, hardly have to deal with JPA, only occasionally do something with Batch or EJBs. More common are CDI, Restful or WebServices and WebApps, and usually a bit of Security.
And a good example for a Java EE Projects, a simple one with some typical use cases and very little code is Adam Bien's Guestbook2.0, which only requires Docker to run.
I am writing a java web application using spring, hibernate and mysql. The applications is getting larger so I want to break it into smaller parts e.g. smaller projects, components or which ever way possible. For example I have login and image uploading functionality, I don't want both of these to be in a single code base or project. I want to be able to use these separately almost like separate services independent of each other. Is there a way of doing this e.g. convert the image uploading functionality into a jar and then reference this jar in the actual project? How are the Enterprise projects split?
Hope it make makes sense and please advice if I am going the right direction as it is my first project? It would be nice if someone can point me to a mini example or recommend reading.
thanks in advance
Try with OSGi. If you are using Spring, then declarative services and possibly blueprint container in OSGi specs are what you need to leverage what you have done until now.
Try reading OSGi in Action by Richard S. Hall, Karl Pauls, Stuart McCulloch, and David Savage to get an insight in this technology.
OSGi is a modularazied approach for java software development that enforces loosely coupled services creation. Quoting from the OSGi alliance website:
OSGi technology is a set of specifications that defines a dynamic component system for Java. These specifications reduce software complexity by providing a modular architecture for large-scale distributed systems as well as small, embedded applications.
Hibernate supports OSGi as it can be seen here. As for the OSGi implementation, I would recommend Equinox, but many other valid OSGi implementations exist. Since your project is a web application, you could check also Virgo
Virgo from EclipseRT is a completely module-based Java application server that is designed to run enterprise Java applications and Spring-powered applications with a high degree of flexibility and reliability
and in particular,
supports vanilla WAR files, with all their dependencies in WEB-INF/lib, and Web Application Bundles, that import their dependencies via OSGi manifest metadata, via the reference implementation of the OSGi Web Container specification, based on embedded Apache Tomcat and configured using the standard Tomcat server.xml
I ended up using maven modules and maven dependency management capability. I created a separate maven project and kept adding maven modules as needed e.g. created a module for image uploading, one module for common libraries and so on.
Each of these modules are then packaged to jar files. I then import each one of these jar files using maven dependency to my main web project.
It seems to have worked great so far. Hope this is helpful for someone else, too.
I try to implement most of the logic in any XPages application in Java. I don’t like the idea of attaching the jars or java code in the NSFs. I want to create repositories of java code that is available in all applications on a given server (maven). I know about the Domino/jvm /lib/ext folder. I also know I can use the JavaUserClassesExt=pathToJava resources in notes.ini
So the question is, are those methods mentioned above the best options to share java resources in an pure XPages environment or should I consider other alternatives?
You might check out this link, it will show you the basics of creating an "extension library"
http://www-10.lotus.com/ldd/ddwiki.nsf/dx/creating_an_xpages_library#Create+the+library+class
that you can use to implement a java jar across the whole server and replicate using the updatesite template to all your domino servers.
The XPages way to create shared resources for all applications for a given server is to code an OSGi plug-in (a.k.a. extension library). This way you can clearly declare the dependencies of your NSFs, it will survive reinstalls upgrades and when you use the updatesite.nsf approach can be shared between servers too.
There's a book detailing how to build one.
Are there ready solutions (gems, plugins, libraries, etc) for integration ruby (rails) applications and jbilling?
I didn't find even api client for ruby.
I need someone to share his experience with integration. Jbilling has web-service (SOAP ,Java RMI, Burlap) but there is no specific gem for easy accessing and editing data via API.
JRuby 1.6.0 was Released yesterday.
Lines from jbilling manual "All of the API classes are located in the jbilling_api.jar file located in your jBilling
distribution.
The API also makes use of several third-party libraries, such as the Log4j library and
Commons Logging, which provides a powerful logging infrastructure; Spring, which
handles configuration and remoting; CXF, a SOAP library; and Hessian, for
Hessian/Burlap support. You'll therefore need to provide the log4j.jar, commons-
logging.jar and spring.jar files in your class path, if your project does not already
include them.
"
Is that good practice to include so many jars in jruby rails application ?
You can try making your app run on JRuby and using the Java libraries directly. We did an experimental branch of our own app for a similar reason and found some useful projects in the process:
https://github.com/nicksieger/warbler/
https://github.com/calavera/trinidad
In the end we didn't go for JRuby, for various reasons that weren't necessarily of a technical nature.
What version of jB are you using? You could use this project as an example to do your integration.
You can also build such a project from scratch using wsdl2 java utility. Typically, you can access jBilling wsdl at localhost:8080/jbilling/services/jbilling?wsdl assuming jb is running on your local at port 8080.
When I looked into Java EE6 doc and some other articles, Java EE6 is a platform.
To me, platform is just Java with bunch of API/framework available like JSF, JPA, Web services like REST. (more like bunch of jars maybe?)
So anyway I got Netbean6.9/Java EE6/GlassFish v3 bundle but figured I don't need JSF at all.
Is there a way to remove JSF from Java EE6 so that I can save some disc space on my server?
Sorry if my statement doesn't make sense because I'm not fully understand what exactly Java EE6 by reading documentation.. (or this JSF is bundled with Netbean6.9...)
Update:
I'm building REST web app so far using JAX-RS and JPA (toplink essential) and for UI side, JSF was going to be used but we decided not to, so wondering if things that won't get used can be removed. (after reading comments I think removing JSF is not good idea though)
Java EE is a set of interfaces/annotations/etc for performing tons of different kinds of tasks commonly needed when building, well, 'Enterprise' applications. (the definition of which is its own multipage thread.) Glassfish is includes an implementation for each of the different APIs that make up JavaEE. Basically, when you use Glassfish, you can just go ahead and use anything in a 'javax ' package and it will be there for you, working. (although sometimes not the most performant or scalable implementation available...)
There are several options for java web containers that don't include implementations of the entire J2EE API built in. Tomcat and Jetty are probably the two most popular and widely used. Tomcat installs and integrates right into netbeans very well. But if you find yourself wanting to use something in most javax packages, you will need to provide an implementation, include the jar files yourself, etc.
--
Also, as an aside, the very, very nice Glassfish administration console (which is to me the chief motivator for using Glassfish) is done in JSF, so no, you can't really remove it :)
Regarding JavaEE, you don't need any jar file, but only a compliant application server, Glassfish in your case. And no, you can't remove features you don't need. But you don't have to use them if you don't want to... ;-)
In order to be J2EE certified there are certain requirements that must be met, and removing some of the functionality may cause problems.
For a nice discussion on what it means to be certified, you can start with this:
http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition
A Java EE application server can
handle transactions, security,
scalability, concurrency and
management of the components that are
deployed to it, in order to enable
developers to concentrate more on the
business logic of the components
rather than on infrastructure and
integration tasks.
If you find that you don't want to use much of J2EE you can look at something like the Spring framework (http://www.springsource.org/) which will offer more capabilities than just tomcat/jetty, but you can add/remove the parts you don't need, though you will need to include the core.
If you just need JAX-WS for example, then you can just add that manually, but, depending on your application you may find that there are many parts you will eventually need to make your life easier.