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).
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.
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'm looking for a way to replace this on my ActiveMQ config:
<transportConnector uri="tcp://localhost:60019"> disableAsyncDispatch="false"/>
with a "not-hardcoded" URI (e.g., replacing "localhost" with a variable that resolves to an instance dependent value). The problem is that as we have many JBoss instances per server, and that URI above resolves to 0.0.0.0:60019, only one instance at a time can be running, unless we configure it in a per-application basis, which is not only frustrating, but there are circumstances where it is not enough (should be per-instance based, which is much more frustrating).
Each JBoss server has its own IP address, so I thought of using ${jboss.bind.address} to circumvent this, but it won't syntax. We also have an environment variable %SERVERIP% which could be used for this calling it from a start up script, but I don't know if ActiveMQ reads an environment variable for assigning its transport connector URI.
Any help would be much appreciated.
Use a PropertyPlaceHolderConfigurer and you should be able to replace the uri with some ${variable} from file or from jvm system variable. This should work since ActiveMQ configuration is really just a Spring context.
I am using httpinvoker in JBoss 4.0.4 (little old) for EJB invocations.
Since there are so many clients that make calls to my server, I want to identify the clients for each call in server.
Is there a way to do this with JBoss httpinvoker?
I could imagine adding a header to identify my client in each HTTP request, but cannot find a way to add a header in httpinvoker.
Auditing builds on a name, and thus on an authentication scheme somehow.
Therefore I suggest using the standard client authentication infrastructure to solve your problem. This works for RMI as well (it's not bound to HTTP), and the user ID is even passed down into your EJBs.
Server
Put the EJB in a security-domain (ejb.jar: META-INF/jboss.xml)
You could use the application-policy other which just the UsersRolesLoginModule (conf/login-config.xml); this is the default policy, it's already configured.
Add users.properties and roles.properties to your ejb.jar file (top level package): These are used by the UsersRolesLoginModule
For each user, add his name and a (dummy) password to users.properties
Client
Create a callback class which implements a javax.security.auth.callback.CallbackHandler: This callback is used, when the authentication needs the user and the password.
Create a javax.security.auth.login.LoginContext; pass the callback handler as the 2nd argument; call login() on the instance of the LoginContext
Connect normally to the EJB server using an InitialContext
Add -Djava.security.auth.login.config=.../jboss-4/client/auth.conf when you start the client
This way a user ID is passed from the client to the EJB (as part of the standard authentication process). Now, in the EJB methods, you can get the user ID by calling getCallerPrincipal() on the SessionContext instance. I have tested this against JBoss 4.2.3
Additional information: JBoss client authentication
Addendum 1:
Using RMI or HTTP, the password is not transported in a secure way. In this case just use a dummy password, this is OK for auditing.
On the other hand, if you use RMI over SSL or HttpInvoker over HTTPS, you could change to a real and secure authentication quickly.
Addendum 2:
I am not sure, if it works without defining roles. Possibly you have to
Add a line in roles.properties for each user: Add a connect role, for example
Add role definitions in ejb-jar.xml as well: security-role-ref for each EJB, and security-role and method-permission in the assembly-descriptor
Update
As there is already a login module, there might be another possibility:
If you have the source code of the login module, you could possibly use another TextCallback to get additional information from the client (in your case a user ID). The information could be used to create a custom Principal. Within the EJB, the result of getCallerPrincipal() could be cast to the custom principal.
I'm writing, or trying to write, Baby's First MDB on WebSphere 7. I have nearly no hair left, having pulled it all out trying to get the thing to work. It appears that I've got everything set up right, but I get no response when I put a message to the associated queue.
Here's the EAR file setup:
simplemdb.ear
META-INF
Manifest.mf
application.xml
simplemdb.jar
META-INF
Manifest.mf
ejb-jar.xml
com
[ classes go here ]
I can't find any syntax for defining the queue's JNDI name in ejb-jar.xml, so instead I:
Define a WebSphere activation spec. Name SimpleMDBActivationSpec, JNDI name jms/SimpleActivationSpec, Destination jms/SimpleMDBQueue.
Define a WebSphere queue. Name SimpleMDBQueue, JNDI name jms/SimpleMDBQueue, Queue name SIMPLE.MDB.QUEUE.
Define an MQ queue, name SIMPLE.MDB.QUEUE.
Deploy the EAR file. During the deployment, I'm asked to enter binding information. I select Activation Specification, then point the Target Resource JNDI Name and Destination JNDI name at the activation spec and queue, respectively.
(The MDB code has no annotations.) At this point, the app points to the spec and queue, and the spec points to the queue - belt and suspenders. Naturally, I imagine that the app therefore knows about the queue. Full of hope, I put a message on the queue, and ... nothing. The onMessage event is supposed to use System.out to log a message. I see no message.
Clear documentation on this is conspicuous by its absence. Google gives LOTS of results, but none of them details how the configuration all fits together. There's lots of hand-waving about ibm-ejb-jar-bnd.xmi, but examples of the file are arcane, full of opaque numbers with no explanation about how they were generated, or how they relate to other parts of the configuration.
For goodness' sake. All I want to do is deploy an MDB, and have it write "Hello, world" when I put a message to a queue. I'm using vi and ant as my development and build tools. Can anybody out there give me an idea about what I'm missing?
Edit: "zos" tag added.
I found the problem. It's specific to WebSphere running on z/OS. For an activation spec to be fully available in that environment, the Control Region Adjunct (CRA) process must be started. I told WAS to start it up, recycled the app server, and lo! My MDB started responding.
To make the CRA start via the WebSphere Admin Console, go to ...
Application servers > [server name] > Communications > Messaging > WebSphere MQ CRA Settings
... and check the box that says "Start CRA". Hit OK, save it to the master configuration, and to make the CRA actually start, bring the app server down and back up. (This is for WAS 7.0.)
Thanks to everyone for their time and thoughtspace.
have a quick look at this and see if there is anything here that helps you.
http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/topic/com.ibm.iea.wasfpejb/wasfpejb/6.1/DevelopmentTools/WASv61_EJB3FP_MDBLab.pdf
I haven't played with this for the last one year so i am not able to comment straight away but i thought the PDF might be of some assistance to you.
HTH
Manglu