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
Related
I did search on jBoss EAP 7.x documentation but didn't find any detailed explanation on how to do the configuration I'm looking for: [jBoss EAP 7.2] <--Remote queues--> [jBoss EAP 7.2 - The actual Queues are here]
As I used to do on jBoss EAP 6.4, I was using Netty with remoting configuration with Acceptor/Connector on Client Side with a defaut remoting on the port 5445.
I'm here to find out the best used practice on how to configure and what are the Actual configurations to be done (which variable on which module etc...)
Thank you community.
You shjould be able to do the same: create a connection factory and a connector on your 'client' server to connect to the acceptor on the 'server' server.
As proposed the solution:
- Using Acceptor on "Server" server side
- Using Connecor on "Server" client side
Another hint is using the Outbound-socket-binding to choose where to the remote queues will publish/read data.
Thanks community.
I maintain a server client system build upon JBoss Remoting library version 2.5.0.SP2. The system consists a modular client, a central server which runs as registry/router and specialized servers which contains the application logic, database access, etc.
For the communication it implements java.lang.reflect.InvocationHandler with a java.lang.reflect.Proxy object on the client side (internally uses org.jboss.remoting.Client and org.jboss.remoting.InvokerLocator) and uses org.jboss.remoting.transport.Connector on the server side to publish the application logic.
The whole system is around 7 years old and it should be modernized, because some components got incompatible with JRE 7 and 8, like JBoss Serialization, and on the security side it lacks for the support of authentication.
I found out that JBoss Remoting is actively developed and updated to version 5, but it seems that there is no documentation about it since version 3. The developers of JBoss Remoting say April 2016 about the missing documentation in a issue on github:
[...] it has grown into a very internal project, used to underpin several of our services but generally hidden from users.
I used a sample client and server and updated it to run with JBoss Remoting 5.0.6 to check if it runs (gist with the source). I noticed while developing that the org.jboss.remoting.Client is gone and I didn't find inside JBoss Remoting anymore.
The developers of JBoss Remoting mentioned that it's possible to implement RCP over it (see quote above). I figured out that JBoss Remoting is part of the WildFly application server which uses it.
Is it possible to implement RPC like JBoss Remoting version 2 without using the whole WildFly application server (using EJB)? If yes, how?
If not, is there a good alternative for it?
Is it possible to deploy different versions of single application on one IBM Websphere Application Server (WAS)?
For example I have:
App1 with url binding http://app/1.0/service/
App2 with url binding http://app/2.0/service/
Is it possible?
I think not due to port listening issue, but maybe there is some chance...
It should be possible, but with some restrictions (depending on your application). If you have WAS ND 8.5.5, then you have Application Edition management feature. Read more details on that page.
If you are on the older version, you will have to change several things during deployment, e.g.:
context-root of the application
JNDI EJB binding names
if other version is using different database - update the JDBC references
if other version is using additional resources (like queues, qcf) update them also.
Actually, port listening has nothing to do with it, as both application will use same port, but different context-roots.
This of course assumes that application doesn't have hard coded values in it (like context root, jndi names, etc).
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
This might be duplicate of this and this question.
I have a java application in which i am using JAX-WS (WEB SERVICES). and many other features in it like apache-commons utils.
My application is swing application, that connects to my server code
and uploads and downloads, and sync files with the server. my
database is mysql.
I have compiled my server code and created a .WAR file. i deployed
that .WAR (containing all the required libraries for my server
side application) file on a JBoss server and its working fine.
Now my Management says me to why use JBoss instead of Tomcat, which
easy to manage and setup on a linux server. actualy they have a
linux server which supports tomcat, but not JBoss. so they said to
me to deploy on Tomcat on Linux Server. I installed and configured
tomcat on my windows and deployed a .WAR file. and also created
virtual directory for my resources its working fine[but not tested
completely]
My Application does not have EJB so I think that Tomcat is good enough.
Please suggest me is it fine to use Tomcat instead of JBoss server,
I am worried if it may get problems in the future, or it might not
support features of my application in future or after complete testing.
JBoss uses Tomcat under the hood to host war applications anyway.
Using Tomcat for you war application instead of JBoss should be perfectly fine.
Any commons-jars that you are using can be downloaded from http://commons.apache.org/. Put them in your lib directory and you should be good to go. Most apache commons libraries should allready be included with Tomcat though, you'll have to check.
PS:
JAX-WS is standard in the latest JDK6 updates. If your using a earlier version of the JDK then just download the JAX-WS jars. The standard reference implementation from Oracle/Sun can be downloaded from here http://jax-ws.java.net/
Do you have EJB? JBoss comes with its implementation of the EJB JSR specification.
For Tomcat, you require plugins like openEJB.
Many application servers use Tomcat internally as its Servlet container. But for compliance to JavaEE standards, most would choose a JBoss application server over Tomcat anyday.
Note that JBoss 7 Application Server Web Profile is certified.
Tomcat functions well as a plain vanilla Servlet container. Many enterprises when using Tomcat, couple it with Proxy and HTTPD servers for security and load balancing reasons.