I'm connecting via jms, and I have had problems with sending jms messages until I add all jars from jboss client folder. It solved the problem but my app weight now +5MB and I'm sure that not all ofthem are required. How can i check which jars are really needed? Please dont tell me I have to remove one by one :)
I also want to ask U about jboss.jar I cant find groupId artifactId for jboss 5.1.0.GA help..
I lifted this from think 1.3 docs I think your up in the 1.4's somwhere
*
jboss-messaging-client.jar - This is available in the messaging distribution
*
jbossall-client.jar - This is available in your $JBOSS_HOME/client directory
*
$JBOSS_HOME/server/<SERVER_NAME>/deploy/jboss-aop.deployer/jboss-aop.jar
JBoss AOP 1.5.5.GA+
http://repository.jboss.com/jboss/aop/1.5.5.GA/lib/
(For AOP, sometimes you have to use a specific JAR according to your JVM of choice. Use the most convenient for you)
*
$JBOSS_HOME/server/<SERVER_NAME>/lib/javassist.jar
Javassist 3.5.0.GA-brew+
http://repository.jboss.com/javassist/3.5.0.GA-brew/lib/
*
$JBOSS_HOME/server/<SERVER_NAME>/lib/trove.jar
trove 1.0.2-brew
http://repository.jboss.com/trove/1.0.2-brew/lib/
*
log4j
If you look at the community documentation under "Connecting from a remote client" you should get your answer
Related
I am very new to jboss app server and using jboss app server 4.1.4 and want to upgrade to any latest version like 6 or 7. What’s the best process to perform i.e. I have seen that “copy the .rar and .war files” and these can’t make right scene to work. What's the best process?
The best way to start is to get an overview over your existing application. In particular:
Which non-standard JBoss features do you use (JBoss Cache, JCA Work Manager, …)?
What "managed resources" (data sources, connection factories, …) do you use?
Which configuration changes did you make (connection pool, transaction timeout, …)?
Which classloading assumptions does your packaging make?
and then individually check how these are handled in the JBoss version you want to migrate to.
there is no one to answer this question..looks shame about it.
I'm trying to find the best way to grammatically determine if my program is running on Jboss 5 or Jboss 7 (eap-6.1). The ways I've been finding so far are jboss 5 or jboss 7 specific, which doesn't work because the code has to work in both. Tried both solutions from here: How do I programmatically obtain the version in JBoss AS 5.1? and they didn't work. One complained about org.jboss.Main not existing in jboss 7, the other complained aobut not finidng "jmx/rmi/RMIAdaptor".
The only way I can see is to do Class.forName to look for "org.jboss.Version" (should be found if jboss 5) and if that fails, do Class.forName "org.jboss.util.xml.catalog.Version" (jboss 7). But that seems like a terrible idea.
The reason I need to know if the war is running on jboss 5 or 7 is because there are some custom files that are located in different places in both. So it's like "if jboss 5, execute this piece of code, if jboss 7 execute the other.
Ok i just saw what the problem is.
I would suggest you to think about design issues/refactoring of your software.
If you want to provide your software within different environments, seperate your logic from
technology dependencies.
Build facedes and interfaces to meet environmental requironments.
In my oppionen thats much better as to think we must support all integration platforms and support all there versions. This is completely impossible.
So decouple your business logic and offer specific interfaces. These interfaces (adapters) are much simplier to implement and to maintain.
Hope it helps.
UPDATE DUE TO COMMENT.
I think a solution is for servers 4 to 6 is to use
the MBean Server of JBoss to lookup the registered web application
which is associated to the deployed WarFile.
I suggest first to lookup the registered MBean of the web application manually using the JBoss jmx-console. The name of the WebApplication should be found under the capital "web" or "web-deployment" within the jmx-console.
If you found that name you can implement an own jmx based lookup mechanism
to check for that name.
Here is an Tutorial: pretty old but i think it gives you an idea how to do.
There must be more tutorials for this problem:
http://www.theserverside.com/news/1364648/Using-JMX-to-Manage-Web-Applications
Within JBoss 7 i just can give you the hint that its architecture is based on OSGI. So to lookup for other services you should have a look to this mechanism.
In any case you don't have direct access to the file system and the deployment directory
from an application which is deployed within a JEE container, except of
using the mechanisms provided by the container. JNDI Lookup, JMX ManagedBean mechanism, Java Connector Archicture (JCA) (makes no sense in your case)
It's not an answer just an suggestions since the implementations are completely different
One way could be to use the "interceptors" which are executed during bootstrap and before any ejb invocation and there you have access to the invocation context in other words ejb container.
I can't give you any example but this would be an access point to start.
Another accesspoint is to check for system wide JMX Beans by looking through the
Adminstratore console of the JBoss Server.
You can inject JMX Bean state into your application through the Context Mechansim.
Take a look from Version 4 to 6 at the JMX Managed Bean mechanism. The JMX Achitecture is the main concept of JBoss 3 to 6, so at this point you can influence and maintain the JBoss behaviour.
Aditionally i think you have differences from 4 to 6.x version and 7.0 because since
7 it's a completely new architecture. Since 7.0 the JMX architecture doens't exists anymore.
As mentioned in the article https://community.jboss.org/wiki/DataSourceConfigurationInAS7 JBoss 7 provides 2 main ways to configure a data source.
What is the BEST practice of configuring a data source in JBoss 7 AS ? Is it
As a module?
As a deployment?
(The same question has been asked in the thread https://community.jboss.org/thread/198023, but no one has provided an acceptable answer yet.)
The guide JBoss AS7 DS configuration says the recommended way is to configure the datasource by deployment
But according to discussion on the link Jboss 7 DS configuration JBoss Community Discussion on page 54 of the guide it mentions that the recommended way to deploy JDBC driver is to use modular approach
But I personally say that the better(not the best) approach to configure JDBC driver would be to use modules because of 3 reasons
JDBC driver will generally not change.
Re-usability : You can use the same module across various applications and not deploy the jar along with each application, this prevents duplicacy
Space Effective : Using the module approach lets you reduce the size of your EAR/WAR as you do not need to supply the jar with the package
Hence I would argue that the better of the two approaches is via modules
#Mukul Goel
It's not necessary to include it the EAR of your application it's sufficient to put the .jar inside the deployments folder so:
no need to embed in ear
no need to create a module
Jist deploy in deployments folder or via admin console
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.
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.