I see URLs like jnp://localhost:1099/ mentioned when reading about HornetQ. What is the jnp protocol? What does it stand for? Where is the specification?
All I could find was this forum thread, "What is JNP", in which the question does not get answered.
In short, JNP is the official JNDI naming implementation of JBoss AS prior to its version < 7.x, based on the JNP project (refer to the code repo URL).
From the new AS7 documentation:
Previous versions of JBoss AS (versions < 7.x) used JNP project
as the JNDI
naming implementation. Developers of client applications of previous
versions of JBoss AS will be familiar with the jnp:// PROVIDER_URL URL
they used to use in their applications for communicating with the JNDI
server on the JBoss server.
Starting AS7, the JNP project is not used.
Neither on the server side nor on the client side. The client side of
the JNP project has now been replaced by jboss-remote-naming project.
There were various
reasons why the JNP client was replaced by jboss-remote-naming
project. One of them was the JNP project did not allow fine grained
security configurations while communicating with the JNDI server. The
jboss-remote-naming project is backed by the jboss-remoting project
which allows much
more and better control over security.
Its specification is poor, most of the references we find about it are located at JBoss docs prior to the version 7, like in https://docs.jboss.org/jbossas/jboss4guide/r1/html/ch3.chapter.html
Hi I'm porting our EJB Server/Client application from JBoss 5.2 to JBoss 7.
Currently the EJB's on the Server are invoked over an HTTP Invoker on the server. (also includeing JNDI...)
I have read that the guys at JBoss have developed a new HTTP Server for WildFly where it should work like cham, but I haven found a way to do this under JBoss 7 (EAP 6.1)
Greetings
Florian
It is not possible in any official releases of as7 or EAP6
There was an experimental build that had limited support, but probably best avoided. Message me directly if you still want to try it for non production use
Currently, our applications are running on Websphere Community Edition 6, which internally uses the Geronimo application server.
Due to increased demand of our applications, we are evaluating the migration to Websphere Application Server 8.5. However, we are having several issues with the classloader. In case some of our libraries need to be performed without interference from the application server.
In geronimo, we get this effect by changing the file geronimo.xml and including in it all packages that we did not want interference by hidden-class tag.
Example:
<hidden-classes>
<filter>org.apache.commons.logging</filter>
<filter>org.apache.log4j</filter>
<filter>org.apache.axiom</filter>
<filter>org.apache.axis2</filter>
<filter>org.apache.commons.beanutils</filter>
<filter>org.apache.struts</filter>
<filter>org.directwebremoting</filter>
<filter>com.thoughtworks</filter>
</hidden-classes>
Is there an equivalent mechanism in Websphere Application Server 8.5? We tried to use the policy "parent last" for class loading but some things did not work as expected (using our version of xerces, for example).
I am starting to look into Enterprise Java and the book I am following mentions that it will use JBoss. Netbeans ships with Glassfish. I have used Tomcat in the past.
What are the differences between these three programs?
Tomcat is just a servlet container, i.e. it implements only the servlets and JSP specification. Glassfish and JBoss are full Java EE servers (including stuff like EJB, JMS, ...), with Glassfish being the reference implementation of the latest Java EE 6 stack, but JBoss in 2010 was not fully supporting it yet.
Tomcat is merely an HTTP server and Java servlet container. JBoss and GlassFish are full-blown Java EE application servers, including an EJB container and all the other features of that stack. On the other hand, Tomcat has a lighter memory footprint (~60-70 MB), while those Java EE servers weigh in at hundreds of megs. Tomcat is very popular for simple web applications, or applications using frameworks such as Spring that do not require a full Java EE server. Administration of a Tomcat server is arguably easier, as there are fewer moving parts.
However, for applications that do require a full Java EE stack (or at least more pieces that could easily be bolted-on to Tomcat)... JBoss and GlassFish are two of the most popular open source offerings (the third one is Apache Geronimo, upon which the free version of IBM WebSphere is built). JBoss has a larger and deeper user community, and a more mature codebase. However, JBoss lags significantly behind GlassFish in implementing the current Java EE specs. Also, for those who prefer a GUI-based admin system... GlassFish's admin console is extremely slick, whereas most administration in JBoss is done with a command-line and text editor. GlassFish comes straight from Sun/Oracle, with all the advantages that can offer. JBoss is NOT under the control of Sun/Oracle, with all the advantages THAT can offer.
You should use GlassFish for Java EE enterprise applications.
Some things to consider:
A web Server means: Handling HTTP requests (usually from
browsers).
A Servlet Container (e.g. Tomcat) means: It can handle
servlets & JSP.
An Application Server (e.g. GlassFish) means: *It can manage
Java EE applications (usually both servlet/JSP and EJBs).
Tomcat - is run by Apache community - Open source and has two flavors:
Tomcat - Web profile - lightweight which is only servlet container and does not support Java EE features like EJB, JMS etc.
Tomcat EE - This is a certified Java EE container, this supports all Java EE technologies.
No commercial support available (only community support)
JBoss - Run by RedHat
This is a full-stack support for JavaEE and it is a certified Java EE container.
This includes Tomcat as web container internally.
This also has two flavors:
Community version called Application Server (AS) - this will have only community support.
Enterprise Application Server (EAP) - For this, you can have a subscription-based license (It's based on the number of Cores you have on your servers.)
Glassfish - Run by Oracle
This is also a full stack certified Java EE Container. This has its own web container (not Tomcat).
This comes from Oracle itself, so all new specs will be tested and implemented with Glassfish first. So, always it would support the latest spec. I am not aware of its support models.
jboss and glassfish include a servlet container(like tomcat), however the two application servers (jboss and glassfish) also provide a bean container (and a few other things aswell I imagine)
It seems a bit discouraging to use Tomcat when you read these answers. However what most fail to mention is that you can get to identical or almost identical use cases with tomcat but that requires you to add the libraries needed (through Maven or whatever include system you use).
I have been running tomcat with JPA, EJBs with very small configuration efforts.
JBoss and Glassfish are basically full Java EE Application Server whereas Tomcat is only a Servlet container.
The main difference between JBoss, Glassfish but also WebSphere, WebLogic and so on respect to Tomcat but also Jetty, was in the functionality that an full app server offer. When you had a full stack Java EE app server you can benefit of all the implementation of the vendor of your choice, and you can benefit of EJB, JTA, CDI(JAVA EE 6+), JPA, JSF, JSP/Servlet of course and so on. With Tomcat on the other hands you can benefit only of JSP/Servlet. However to day with advanced Framework such as Spring and Guice, many of the main advantage of using an a full stack application server can be mitigate, and with the assumption of a one of this framework manly with Spring Ecosystem, you can benefit of many sub project that in the my work experience let me to left the use of a full stack app server in favour of lightweight app server like tomcat.
Both JBoss and Tomcat are Java servlet application servers, but JBoss is a whole lot more. The substantial difference between the two is that JBoss provides a full Java Enterprise Edition (Java EE) stack, including Enterprise JavaBeans and many other technologies that are useful for developers working on enterprise Java applications.
Tomcat is much more limited. One way to think of it is that JBoss is a Java EE stack that includes a servlet container and web server, whereas Tomcat, for the most part, is a servlet container and web server.
Apache tomcat is just an only serverlet container it does not support for Enterprise Java application(JEE). JBoss and Glassfish are supporting for JEE application but Glassfish much heavy than JBOSS server : Reference Slide
I have an application that was written on JBoss 3.2.5 and I am tasked with migrating it to JBoss 5.
I am unable to deploy the application because it relies on JBoss MQ, which I read has been replaced by JBoss Messaging.
Is there any way I can get the app to work on JBoss 5 without making any code changes? Config changes are OK.
Actually JBoss Messaging is already being replaced by HornetQ.
In JBoss Application Sever 6.0, HornetQ will be the default messaging provider.
http://jboss.org/hornetq/
Is there any way I can get the app to
work on JBoss 5 without making any
code changes? Config changes are OK.
Assuming that your code is written to the JMS API, then yes, you probably can. However, don't underestimate how different JBossMQ is from JBossMessaging, the configuration is completely different.
Depending on how hard your app pushes the JMS API, you may get behavioural differences, but the odds are you'll be fine, as long as you can reconfigure JBossMessages within JBoss5 appropriately.
Another option is to move to JBoss 4.2, which still has JBossMQ, but is miles ahead of JBoss 3.2. Much of the functionality that JBoss5 gives you can be done with JBoss 4 (e.g. it has partial JavaEE 5 support).
JBossMQ will be replaced by JBoss Messaging in JBoss AS 5.0.
A good starting point to find out how to migrate would be JBossMQ