Looking for examples of how to configure a Wildfly server to be very simple standalone JNDI namespace server.
I would like to specify value pairs so that our external java applications can access and use the defined resources using JNDI API's.
From the Documentation it is clear that I have to use the XML tag.
Remote JNDI Configuration
The Naming subsystem configuration may be
used to (de)activate the remote JNDI interface, which allows clients
to lookup entries present in a remote WildFly instance.
Only entries within the java:jboss/exported context are accessible
over remote JNDI. In the subsystem's XML configuration, remote JNDI
access bindings are configured through the XML
element:
<remote-naming />
But what isn't clear is HOW to use it, I cant find any examples anywhere.
If I had the following object:
String: MyFirstProperty
How do Insert this into the <remote-naming /> tag so that Wildfly makes it available for me to retrieve?
Related
I would like to create a JMS connection from a Java SE application in a broker-agnostic way.
I'm comparing to JDBC with its URL scheme for database connections. This creates independence from the actual implementation.
For JMS I haven't found something similar. I'm aware that in Java EE the JNDI will fulfill this role, but this is Java SE.
I don't want to tie my code to any particular queue broker as my needs are pretty simple JMS 1.1 send/receive of text messages.
I've looked at Spring Boot too because it is usually good at providing some level of agnosticism. But even with Spring Boot, I do not see such possibility.
JNDI is the way you write your JMS application to connect in a broker-agnostic way. JNDI client classes are part of Java SE. Both Spring and non-Spring Java SE applications use JNDI for this kind of integration.
Any JMS implementation should also provide a JNDI implementation that can be plugged into your application. Typically this is done by placing a file named jndi.properties on your classpath and putting the proper configuration for whatever JNDI implementation you're using into that file. When you create an empty InitialContext the jndi.properties file on your classpath is read automatically. The key=value pairs in jndi.properties are put into the InitialContext so that when you perform a lookup everything works with the implementation you've chosen. You can also configure this programmatically if you like by supplying the implementation specific details to the InitialContext via a constructor.
By using both the JMS and JNDI APIs in your Java SE application and externalizing broker-specific connection details to your jndi.properties file you can effectively isolate your applications from broker-specific code so you can deploy your app and work with different brokers with a few simple changes in a properties file.
The JNDI client implementation will come from whoever is providing the JMS implementation. The JNDI client essentially comes in the form of an javax.naming.spi.InitialContextFactory implementation packaged in a jar and there is usually documentation describing the available properties.
Here are a few examples:
The ActiveMQ 5.x broker provides org.apache.activemq.jndi.ActiveMQInitialContextFactory available in their activemq-client-<version>.jar. Documentation is available here.
The ActiveMQ Artemis broker provides org.apache.activemq.artemis.jndi.ActiveMQInitialContextFactory available in their artemis-jms-client-<version>.jar. Documentation is available here.
To be clear, the JMS specification doesn't require the use of JNDI to look-up admin objects, but it establishes the convention and expectation that JMS providers will do so. Section 4.2 of the JMS 1.1 specification states:
Although the interfaces for administered objects do not explicitly depend on JNDI, JMS establishes the convention that JMS clients find them by looking them up in a namespace using JNDI.
and later it says:
It is expected that JMS providers will provide the tools an administrator needs to create and configure administered objects in a JNDI namespace. JMS
provider implementations of administered objects should be both javax.naming.Referenceable and java.io.Serializable so that they can be stored in all JNDI naming contexts.
In my experience, JMS providers are usually eager to provide a JNDI implementation because they won't be as competitive without it since any alternative solution will not be standards compliant and will force users to implement non-portable code.
If you run into a provider that doesn't provide a JNDI implementation you could implement your own following the same pattern used by ActiveMQ 5.x, ActiveMQ Artemis, and Qpid JMS. These 3 implementations are client-side only and simply instantiate the admin objects based on the configuration provided to the InitialContext. Most of the code is boiler plate, and what isn't is very straight-forward.
I have tested my first sessoin bean using Wildfly 8. I use the following code to obtain a proxy for the bean
InitialContext ctx = new InitialContext();
Object obj = ctx.lookup("java:global/EJBDemo/FirstDemoEJB");
When I print the object out I get the following output
Proxy for remote EJB StatelessEJBLocator{appName='', moduleName='EJBDemo', distinctName='', beanName='FirstDemoEJB', view='interface com.demo.ejb.FirstDemoEJBRemote'}
I can proceed with the RMI with the above lookup and get the desired result.
However, I observed that there are other lookup paths as listed by Wildfly at the time of deployment.
java:global/EJBDemo/FirstDemoEJB!com.demo.ejb.FirstDemoEJBRemote
java:app/EJBDemo/FirstDemoEJB!com.demo.ejb.FirstDemoEJBRemote
java:module/FirstDemoEJB!com.demo.ejb.FirstDemoEJBRemote
java:jboss/exported/EJBDemo/FirstDemoEJB!com.demo.ejb.FirstDemoEJBRemote
When I use the other lookup names names (part before the ! mark), I get the following output
EJBDemo/FirstDemoEJB -- service jboss.naming.context.java.app.TestEJB.EJBDemo.FirstDemoEJB
But I cannot RMI and get the desired result as in the java:global lookup.
My question is what does these other lookup paths listed by Wildfly mean? and can they be used for JNDI lookup as well? If so how to do it?
Before Java EE 6 every application server (Weblogic, JBoss, Glassfish, etc) had their own naming convention for JNDI then the applications weren't portables across servers.
In Java EE 6 the specification has standardized the JNDI address.
From https://docs.oracle.com/cd/E19798-01/821-1841/girgn/index.html :
Three JNDI namespaces are used for portable JNDI lookups: java:global,
java:module, and java:app.
The java:global JNDI namespace is the portable way of finding remote
enterprise beans using JNDI lookups. JNDI addresses are of the
following form:
java:global[/application name]/module name/enterprise bean
name[/interface name] Application name and module name default to the
name of the application and module minus the file extension.
Application names are required only if the application is packaged
within an EAR. The interface name is required only if the enterprise
bean implements more than one business interface.
The java:module namespace is used to look up local enterprise beans
within the same module. JNDI addresses using the java:module namespace
are of the following form:
java:module/enterprise bean name/[interface name] The interface name
is required only if the enterprise bean implements more than one
business interface.
The java:app namespace is used to look up local enterprise beans
packaged within the same application. That is, the enterprise bean is
packaged within an EAR file containing multiple Java EE modules. JNDI
addresses using the java:app namespace are of the following form:
java:app[/module name]/enterprise bean name[/interface name] The
module name is optional. The interface name is required only if the
enterprise bean implements more than one business interface.
For example, if an enterprise bean, MyBean, is packaged within the web
application archive myApp.war, the module name is myApp. The portable
JNDI name is java:module/MyBean An equivalent JNDI name using the
java:global namespace is java:global/myApp/MyBean.
As part of my application requirement, I have to configure a attribute called "ORBInitRef.NameService=corbaloc:iiop:ABCDE012:14888/NameService" in Websphere 8.5.5. Earlier i have used Jboss for my applciation deployment but now have to use WAS. In, WAS where should i have to configure this attribute in admin console? Is there any way to do it through orb.properties file in WAS root folder. Please let me know to approach??
Please follow the below steps to configurable Corba Name service in WAS 8.5.5 in admin console.
--> Environment --> Name Space Bindings --> New --> Provide your corba details here.
Example:
1) corba URL : corbaloc:iiop:ABCDE012:14888/NameService
2) provide Lookup name. using this, u will get a RootContext by lookup like JNDI.
Code Example :
InitialContext context = new InitialContext();
org.omg.CosNaming.NamingContext rootContext=(NamingContext)context.lookup("testing");
using the rootContext, you can fetch the server stubs and preform the operation required.
I'm novice guy in JCA and JMS parts of Java EE stack, and now I'm struggling with JMS bridge configuration between two JMS providers (ActiveMQ 5.9.1 -> Weblogic 11g 10.3.5), and I need some help to understand all the moving parts and required configuration elements.
What I've done already:
JMS server configured on Weblogic 11g node
Configured Foreign Server - AMQ connection factory, and source queue objects bound to the local JNDI (OK: conn. factory and queue objects visible in server jndi tree)
Create JMS Bridge with default props (OK - I think)
Created the Bridge Destination for target destination (Weblogic) with default configuration - where possible (OK: Resource Adapter deployed)
Created the Bridge Destination for source destination (AMQ) - JNDI properties, default props where possible (FAIL - Cannot connect to the source destination)
And there is the question:
By default there are two resource adapters (XA, non-XA), do I need install the AMQ specific resource adapter?
I've assumed that yes, so I've downloaded rar file on Weblogic machine, then tried to install with Weblogic Console (Deployment -> Install), but.. another trouble - no way to achive Running state in Deployments view. I've read that all jars from rar need to be placed in Weblogic CLASSPATH, so I've copied them to Weblogic lib directory. But, with no success so far.
So, what I did wrong, where is the gap or an error in this configuration?
I have studied the Oracle documentation, but I feel still didn't get the complete understanding of the bridge config :((
Any explanatory replies very appreciated!!!
Ok, problem solved. I've used wrong JNDI names of connection factory and queue - local names defined in Foreign Server configuration instead of names on remove JMS server.
Actually, no additional configuration like Foreign Server, or Resource Adapter is needed here.
I would like to have optionally supplied information available to my webapp when deployed to Websphere (we are using 8.5) via the application's JNDI context.
I know that I can put a resource-ref or resource-env-ref in my web.xml but when I do that WAS will require me to supply a binding for it and deployment time.
My application will look in JNDI for certain values and adjust its behavior if found, but will function fine with default behaviour if it does not find values in JNDI. How, in WAS, do I supply a binding (just for a string or a URL) for my webapp without declaring a dependency on it in a resource-ref or resource-env-ref in my web.xml.
I know how to do this in Tomcat, I just put a Environment entry in the context.xml, like this:
<Environment
name="com.myorg.config"
value="http://localhost:8081/suff"
type="java.lang.String"/>
You can use an #Resource String lookupName; to accomplish the same in a portable manner. You will be prompted for a value at deployment time, but you can specify nothing, which will cause no value to be injected.