I need to access EJBs deployed in JBoss AS 6, but I am using JBoss AS 7.1.1 Final, which dropped the JNP lookup.
Is it possible to do so, or do I need to downgrade to JBoss AS 6 (upgrading the other server is impossible)?
I've dug through the AS 7 forums and SO, but did not find any references for this..
Thanks in advance!
In general EJB remote communication between two different servers never works.
JBoss is especially known to have a total lack of attention for compatibility. Even a minor difference in version (a minor security update for instance) is already enough to break compatibility. I know for a fact that EJB remoting between JBoss AS 5 and 6 does not work, and I'm pretty sure it doesn't work between 6 and 7.
The root of the problem is that Java EE never specified how remote bean discovery should take place and what the requirements for the client exactly are (one exception is the application client container, which only works in Java SE and is so arcane that almost nobody uses it).
Most vendors use some kind of client jar, which in case of Jboss is nearly the entire server. Because it's nearly the entire server, you can't include it in another server as hundreds if not thousands of classes would clash.
A Jboss employee once started an experiment with an isolating class loader that would load these clients libs isolated from the main server, but as far as I know nobody ever got this to work.
Related
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.
I migrating someone else's EJB 2.X app from jboss 3 to jboss 5 (and then maybe onto AS7).
When I do a test deployment of one of the EJBs I am getting this error
org.jboss.deployment.DeploymentException: Could not load class:
at org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCEntityCommandMetaData.<init>
(JDBCEntityCommandMetaData.java:76)
at org.jboss.ejb.plugins.cmp.jdbc.metadata.JDBCEntityMetaData.<init>
(JDBCEntityMetaData.java:954)...
Googling this stack trace doesn't give me any leads I can work on. As far as I can tell this means that the entity-command in conf/standardjbosscmp-jdbc.xml is wrong but I have no idea what it should be. Looking at the jboss 3 conf/standardjbosscmp-jdbc.xml file doesn't even have an entity-command listed so I assume "default" should be ok, no? I am using Oracle 11g, if that is meaningful and otherwise seem to have no db connection issues. The Oracle datasource seems to be created without problems. This is the very first error in the output. Any clues as to what i should look a to resolve this?
Are you sure you build everything against JBoss 5 libs? This could be a build problem...
We could see JBI in Glassfish V2 but it is not in V3, what's happening? Which application server is useful for SOA development?
can I deploy WSO2 on Glassfish or JBoss?
RGDS
I'm not sure this answer is definitive, just based on my own experience with these systems.
JBI isn't a Glassfish feature (if it ever was its news to me). Its a (kinda/sorta) Sun community standard which has many implementations (ServiceMix to name one of several) that can be installed on any J2EE container (such as Glassfish to name one). Although it was once very popular it seems to have fallen on hard times of late, perhaps simply because ESB hype got swamped by the new wave of cloud hype.
WSO2 is much larger and includes JBI as one of its many options. By default its based on its own embedded Tomcat, but WSO2 claims its possible to run it on an external Tomcat (I never managed to make this work). To my knowledge no one has tried or succeeded to make it work on Glassfish.
I have inherited an application that is running on JBoss 2.4.3 (which I believe is EJB spec 2.0 compatible), and I'm running into quite a few issues (like being able to use modern log4j "Logger" apis [JBoss 2.4 specific issues pushing me to upgrade]).
I understand that I should be able to use a EJB 2.1 container (Jboss 4) without issue, but should I expect to be able to go further?
What are the backwards compatibility requirements for EJB?
Are they meant to be backwards compatible through major versions?
Do application vendors make them fully backwards compatible?
What modifications are necessary to make an older application conform? (small or large? application configuration or re-compilation? etc)
log4j and EJB 2.0 are not related. If you have problems with log4j, then most likely it is a class path issue and not EJB 2.0 compatbility issue. Probably your old application assumes that log4j is somewhere on system class path.
http://what-when-how.com/enterprise-javabeans-3/backward-compatibility-and-interoperability-with-ejb-2/ states that
The EJB 3 specification requires that all complying containers support EJB 2
Which is a good sign. It goes on further to talk about mixing EJB 2 and 3 functionality. So there may be some exceptions, but it really shouldn't be any where near impossible.
Reality may be different; I'll update if I find problems with my jboss upgrade.
See this compatibility report for the EJB library:
I need to use some EJBs which are deployed on JBoss version 4.x from another EJB deployed on JBoss version 3.2.x. Is this possible?
I ask because I have a third party application which uses some strange bridge's to do that and don't know why (though I haven't try to do this on my own).
This is unfortunately not possible. One of the major drawbacks of remote EJBs is that there is nothing in the specification that guarantees or even suggests any kind of interoperability between different vendors or between different EJB versions from the same vendor.
In practice I found that at least with JBoss AS it never works. Even minor upgrades break binary compatibility completely. There have been some very hacky attempts with special class loaders that are only been given access to the client libs of the target JBoss AS, but this is very tricky to get right.
I guess this "strange bridge" you are talking about is using such a trick. Kudos to whoever build that bridge for getting this to work at all.
See this topic I started on the JBoss community forum for some more details: http://community.jboss.org/message/587180