I'm looking for a tutorial or any additional information on how to make an EJB (or underlying MBean) accessible via CORBA.
This is all I've found: http://www.jboss.org/jbossiiop
I have an existing CORBA server (java-based, but non-standard) and I want to allow it to call into my JBoss MBean. This MBean is already exposed via RMI using an EJB (v2.1).
The current AppServer target version is jboss-eap-4.3.
Edit: I'm hoping my question is just too vague to get answered so here's an update:
I want my EJB running in JBoss to register with the Corba ORB running on a remote separate server. At least I think I do. The existing CORBA client connects to services via a defined IDL/interface that I'm trying to implement via a JBoss EJB. At this point, said client connects to several instances of the same interface to pull information and manage local (same process) services via this interface. I want the JBoss EJB to be dropped in as just another implementation of this CORBA IDL.
My understanding of CORBA is rusty and weak to begin with so I'm not getting very far. I can run an ORB in JBoss easily enough, but it's not clear to me how to set up the binding so the "legacy" CORBA ORB can find it. I can change any part of the JBoss implementation to make this work, but changing the other server is difficult.
Is there a way for the EJB to register itself with a remote server (ala jndi)?
Will the existing client be able to connect to Jacorb without adding jboss specific classes?
In short you have to implement an adapter, deploy it in Jboss, register it with the remote NamingService. In your adapter implementation you call your MBeans.
Now more in details
You have a CORBA idl, you generate stubs and skeletons.
interface Stock {
int getQuote( in string company);
};
You provide necessary implementation
public class StockImpl extends StockPOA {
public int getQuote(String company) {
//forward a call to MBean here
}
}
You do the usual CORBA registration stuff. something like:
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(...);
org.omg.PortableServer.POA poa = org.omg.PortableServer.POAHelper.narrow(orb.resolve_initial_references("RootPOA"));
poa.the_POAManager().activate();
NamingContextExt nc = NamingContextExtHelper.narrow(orb.resolve_initial_references("NameService"));
NameComponent [] name = new NameComponent[1];
org.omg.CORBA.Object o = poa.servant_to_reference( new StockImpl(orb,poa));
name[0] = new NameComponent( "Stock", "server");
nc.bind(name, o);
orb.run();
Now your object is registered in the remote NamingService and is accessible via CORBA.
You have to include CORBA jars in the JBOSS classpath.
A Corba orb is a socket listener, so best to use the one under JBoss's control, i.e. the standard orb:
ObjectName ORB_NAME = ObjectNameFactory.create("jboss:service=CorbaORB");
ORB orb = (ORB)server.getAttribute(ORB_NAME, "ORB");
to automatically start your Corba service do it in a JBoss Service mbean:
http://community.jboss.org/wiki/examplehelloworldservice
To avoid having to compile IDL you could use the Dynamic Invocation Interface.
Have a look at how Axis2 CORBA Module does it: http://wso2.org/library/2807
You do not need an Orb on the classpath if you use the JBoss "all" configuration, this includes Corba.
Related
I have introduced LRA on a MicroProfile application already running on WildFly AS.
To get the LRA working I have added the following depedency on my application pom.xml
<dependency>
<groupId>org.jboss.narayana.rts</groupId>
<artifactId>narayana-lra</artifactId>
<version>5.10.6.Final</version>
</dependency>
and I have created an LRA coordinator running on the same host ad listening on port 8080.
The application works as expected.
Now I want to move LRA coordinator on a remote host, but I'm not able to configure my application to point to it (on new host and port).
I have tried to put in my microprofile-config.properties the following parameters:
mp.lra.http.host=<new_host>
mp.lra.http.port=<new_port>
but without effect.
Can anyone suggest me hot to configure LRA coordinator host and port on client application?
Thanks in advance
Narayana doesn't support MicroProfile Config yet even if it is something that it probably should. The properties you want to set are defined only as system properties (i.e., read with System.getProperty(String, String).
Another issue is that the properties you are looking for are defined as lra.http.host and lra.http.port respectively. MP LRA made a deliberate decision to remove all coordinator references from the specification to not specify the implementation architectures (saga can also be implemented as an orchestration pattern).
So you need to set these system properties for instance when you are starting the WildFly server:
bin/standalone.sh -Dlra.http.host=lra-coordinator.com -Dlra.http.port=7777
Finally, if you ever move to the latest Narayana releases, these properties were merged only into single property lra.coordinator.url which is however still read only from system properties.
I try EJB invocations from a client to a server, they are actually same copied ear files each other and on same machine.
I think that I must set "distinct-name" in somewhere, but I can not find it.
WildFly Developer Guide - EJB invocations from a remote client using JNDI:
distinct-name : This is a WildFly-specific name which can be optionally assigned to the deployments that are deployed on the server. More about the purpose and usage of this will be explained in a separate chapter. If a deployment doesn't use distinct-name then, use an empty string in the JNDI name, for distinct-name
Where is "a separate chapter"?
Set <distinct-name> attribute in jboss-app.xml(EAR) or jboss-ejb3.xml(WAR/EJB jar).
We migrated from Jboss EAP 5 to EAP 6 in our development environment.
I now see the following in my JBOSS logs. I am trying to understand how this binding happens. I have read JBOSS docs on JNDI namespace binding. Still I am not totally clear how it works. Here is my log.
java:global/customerCare/services/UserDaoImpl!com.example.services.UserDao
java:app/services/UserDaoImpl!com.example.services.UserDao
java:module/UserDaoImpl!com.services.UserDao
java:global/customerCare/services/UserDaoImpl
java:app/services/UserDaoImpl
java:module/UserDaoImpl
Here are my EJBs
#Local
public interface UserDao {
public static final String JNDI_NAME = "java:global/customCare/services/UserDaoImpl";
//interface methods here
}
#Stateless
public class UserDaoImpl implements UserDao {
// implement methods
}
My doubts are:
I explicitly had JNDI binding to be java:global/customCare/services/UserDaoImpl in my UserDao interface.
Then why do I see I binding for others such as app and module.
what is the difference between app and module? when would binding to these components be needed? some example here to illustrate will be very helpful
The last three lines of log show binding to UserDaoImpl. Is it something that JBoss does without I ask it to bind? ( I set only UserDao but not UserDaoImpl for JNDI binding).
I am a bit illiterate on JNDI Namespace binding. Reading docs helped me but not to great extent.
Thanks
I can answer doubt 2:
All the names are the same thing but with different contexts.
The global name is a full JNDI context that is used to bind globally, ie. from a client or from another EAR file
The module name can be used to bind within the same application, ie different EJBs within the same EAR
The local name is used to bind locally, ie within an jar or war.
It is slightly more efficient to use the shorter names to bind locally than specifying a full global name each time.
From what I have seen JBoss EAP 6 will always list the three / six names for every enterprise bean during deployment. It is intended to help you as a developer identify the JNDI name(s) for the bean.
I need to be able to circumvent the whole deployer malarkey and programmatically register/unregister (dependency-less) POJOs as services in JBoss.
Currently I'm dynamically creating an MBean interface and registering this with the JBoss MBeanServer, and then registering local/remote with Jndi.
This works ok (I can have a standard service from a vanilla SAR reference one of these service POJOs with the #EJB annotation) - however the container seems to leaves stale references behind as after calling unbind() and unregisterMBean().
Obviously I'm missing something by not dealing with the container in a way it expects, but what am I missing? Or is there an easier way (can't see much in the way of an API)?
thanks.
In Jboss 5.1 the Profile Service does what the Deployment Service was doing in Jboss 4.x.In Jboss 4.x I was using the Deployment Service to create a datasource "on-the-fly" and I was wondering if I could do the same thing using the Profile Service (since Deployment Service doesn't exist any more in Jboss 5.x).
Does anyone know a practical guid on using ProfileService?
Thank you ,
Regards.
I don't know of any guide but I can provide you with my experience using the Profile Service and a few links to JBoss wiki pages on this topic. I'd like to post more links but the spam protection doesn't allow me to post more than two, but you should easily find the other pages in the wiki on the ProfileService. Don't be suprised in case you don't find much, there isn't more.
ProfileService ManagementView
http://community.jboss.org/wiki/ProfileServiceManagementView
ProfileService DeploymentTemplates
http://community.jboss.org/wiki/ProfileServiceDeploymentTemplates
There you'll find usefull information about the ProfileService but no detailed information is available in the jboss wiki as far as I can tell.
In order to create Datasources on the fly you can use the DeploymentTemplates (also for creating message queues and topics) The last link provides you with information on how to use the templates but not with all the template names and their properties. You can list them programatically though.
// Get all Templates
for(String template : mgtView.getTemplateNames())
{
System.out.println("=========================================");
System.out.println("Listing properties for template: "+template);
DeploymentTemplateInfo info = mgtView.getTemplate(template);
for(String prop : info.getProperties().keySet())
System.out.println("- "+prop);
}
In order to get the ManagementView (mgtView) from an external java programm you can use something similiar to this:
// set security policy
System.setProperty("java.security.policy", "<path_to_policy_file>");
System.setSecurityManager( new RMISecurityManager() ) ;
// set initial context properties
Hashtable<String, String> env = new Hashtable<String, String>();
env.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
env.put("java.naming.provider.url","jnp://localhost:1099");
env.put("java.naming.factory.url.pkgs","org.jboss.naming:org.jnp.interfaces");
ctx = new InitialContext(env);
// login to JBoss
SecurityClient client = SecurityClientFactory.getSecurityClient();
client.setSimple("admin", "admin");
client.login();
// get ProfileService and ViewManager
ProfileService ps = (ProfileService) ctx.lookup("ProfileService");
mgtView = ps.getViewManager();
What you want to get is the Java Naming Conext (InitialContext). In order to do that you'll need a security policy (you can use the java.policy file which is located in JBOSS_HOME/server/SERVER_DIR/conf/),security manager and environment properties to get the context. The java.naming.provider.url specifies the location of the JBoss naming service (default port is 1099).
Usually you would have to authenticate at this point which is done with the SecurityClient.
Finally you can use the context to grap the ProfileService.
At this point most of the anoying stuff is done und you can start playing around.
getViewManager() returns the ViewManager with which you can create datasources on the fly and getDeploymentManager() will give you the DeploymentManager with which you can deploy, undeploy, start, stop applications and other deployments.
The libraries you'll need to do that are located in
JBOSS_HOME/client
JBOSS_HOME/lib
JBOSS_HOME/common/lib
I've read several times that including the jbossall-client.jar in the client directory should be enough but that's actually not true. You need libraries from all three directories as far as I can tell (couldn't do it without referencing all of them at least). I haven't figured out which exact jars you need though...
IMPORTANT: The ProfileService in Jboss 5 Community Edition has some bugs though which got fixed in JBoss 6. I'd either suggest using a newer JBoss version or the Enterprise Edition.