I need to setup a URL resource in WebSphere and is following this tutorial. However, the tutorial requires the modification of WebSphere's web.xml and ibm-web-bnd.xml using WebSphere Studio. I don't have a WebSphere Studio so I need to modify those files manually using a text editor. I tried to "search" for the 2 files but the "search results" are so many that I don't know which one is the right file.
Where can I find the 2 files? Also what value do I need to set for the resource-ref's id? I notice that WebSphere Studio doesn't have any text field for setting the resource-ref's but it has a value on its code view.
Thank you!
web.xml is a standard JavaEE file and its structure is well-documented in the Servlet specification. In web.xml, you declare the URL as it is known within your local JNDI namespace (java:comp/env).
web.xml should be located inside WEB-INF, underneath your WAR project structure. If you are using an IDE (such as Eclipse) to create Web projects, this file should already be created for you (unless you use Servlet Specification 2.5 and up - Servlet Specification 2.5 is included with JavaEE 5.0 - where deployment descriptors are optional).
ibm-web-bnd.xml is a WebSphere-specific file. It contains the binding of declared artifacts (such as a URL definition) into a real artifacts. You should refer to IBM's documentation in order to figure out the format of that file.
The ibm-web-bnd.xml file should be located in the same directory as web.xml.
The id attribute of resource-ref can be set to any value you like, as long as it is cross-referenced by a matching id attribute inside ibm-web-bnd.xml. That's how WebSphere can correlate definitions in ibm-web-bnd.xml to definitions in web.xml. The random string you see in the tutorial are created by RAD or WSAD; you can place any identifier there.
EDIT (added instructions)
In a nutshell, the process is this:
In web.xml, you define the local JNDI name. That would be the name by which your Java code is referring to the URL. For example, myWebsiteUrl. Your code will have to perform a JNDI lookup on java:comp/env/myWebsiteUrl. The definition is along these lines:
<resource-env-ref>
<resource-env-ref-name>myWebsiteUrl</resource-env-ref-name>
<resource-env-ref-type>java.net.URL</resource-env-ref-type>
</resource-env-ref>
In WebSphere itself, add a URL definition. The key there is the JNDI name in WebSphere's JNDI tree by which the URL will be known. You can set any value there, although it is recommended (by convention) that you prefix it with url/. For example: url/test.
In ibm-web-bnd.xml, you need to bind myWebsiteUrl (looked-up by your application) to url/test (which is the JNDI name by which WebSphere knows the URL). The definition will be along the lines of:
<resource-env-ref name="myWebsiteUrl" binding-name="url/test"/>
Step 3 is not required. If ibm-web-bnd.xml doesn't exist at deployment time, then the GUI-based deployment flow (used when you deploy applications through the WAS administration console) will prompt you for the binding values. (If you are deploying using scripting, you can still omit the ibm-web-bnd.xml file as long as you specify the bindings in a different way, but that's beyond the scope of this answer. Read the IBM documentation about strategy files and AdminApp.installApplication)
Note: as long as you use JavaEE 5.0 and up, you don't need the id attribute in the definitions. The article you're reading, by the way, is extremely outdated.
Related
We are looking to move our dev+prod WebSphere full profile app to Liberty.
Currently, we build only once (using Ant scripts) and deploy the same package (i.e. EAR) to our functional, UAT and production environments.
Database and MQ connections (and related sensitive data like usernames and passwords) are directly set via the WAS admin console for each environment, so there is no such data in our EAR.
A few non sensitive settings that change per environment (mail server address etc), are kept in a file suffixed with the (e.g configuration_.properties). All these files are bundled within the EAR. Each WebSphere defines a JVM property to specify the environment they are running (prd, uat, fnc, lab etc). When the application starts, it reads the files that is associated with the environment. That works great.
Now with Liberty, the connection/MQ pools, LDAP users etc are defined in server.xml.
Questions:
how to manage the server.xml file(s) that replace the job done via the WAS console by the authorized admins?
how to define the database name/port/host/user/password needed for those access per environnment? keep one server.xml file per environnement?
is there a way to have a "base" server.xml file and "override" the database name/port/host/user/password etc at startup on runtime?
or maybe there are more clever strategies?
We don't know yet if we will run Liberty in a traditional ND/Cluster way or into a docker infrastructure (this is all very new to us..).
How do you handle this?
Thanks in advance.
You can do the same thing in Liberty, just using different methods.
1) in your server.xml files, use variables wherever needed:
${this.style} for referencing system/bootstrap properties or server.xml defined variables, or ${env.ENV_VAR} for referencing Environment variables
2) add in a per-environment server.env file, or use configDropins/overrides to define environment-specific server.xml snippets (this answers one of your questions: yes, you can have a base server.xml and use environment-specific overrides)
More information here: http://www.ibm.com/support/knowledgecenter/SSD28V_8.5.5/com.ibm.websphere.wlp.core.doc/ae/cwlp_config.html?lang=en
And here (specifically includes and dropins):
http://www.ibm.com/support/knowledgecenter/SSD28V_8.5.5/com.ibm.websphere.wlp.core.doc/ae/twlp_setup_basics.html?lang=en
I am trying to figure out how to deploy a resource-adapter activation in JBoss 7. Basically, I want to be able to package and deploy a full application without having to modify the base server configuration, in part because I want to bootstrap testing using Arquillian but also because I want to be able to deploy my packages into an environments where I may not have the option of modifying the base server's configuration.
Here's where I am right now. I have created an EAR which contains the active-mq rar (which is also configured in the application.xml). This ear by itself builds and deploys perfectly using the maven ear plugin and the jboss-as-maven-plugin.
However, in order to activate the rar, the only way I have been able to figure out is to hack the rar file itself and add an ironjacamar.xml into the rar's META-INF directory. But in order to do this, I had to hack the rar in my maven repo which I don't really want to do.
I tried to get maven to add the ironjacamar.xml during the packaging phase of my maven pom, but that's a bit of hack as well and I couldn't get it work anyways. (Note to self: check on Deployment Overlays)
I also thought about scripting the addition of a connection-factory using jboss-cli, but the docs clearly state that is for creating factories for the built in hornet-mq server which is not my target, and swapping the default JMS implementation in the server requires some major surgery on the server's config.
I looked though all the quickstart projects and observed all sorts of constructs being deployed though -jms.xml and -ds.xml files included in the package, but they're also specific to hornet-mq and JDBC respectively. (I was hoping the deployer might support a -rar.xml or the like).
The only other way I can think of, and I don't know if it is supported, is to define a subsystem deployment in my package. Is there such a thing ?
===== UPDATE =====
I tried adding a cli overlay update (as I would using the maven jboss as plugin) but it had no effect.
deployment-overlay add --name=rarActivation --content=META-INF/ironjacamar.xml=\..\container\src\main\resources\ironjacamar.xml --deployments=activemq-rar.rar --redeploy-affected
Well, in the absence of any other answers, this is the solution I came up with. It's a bit of a hack, but it has worked flawlessly with Active MQ and WebSphere MQ. The premise is that I deploy 2 different RARs per JMS system I want to connect to. One is the untouched xxx.rar file I retrieve from the Maven repository. The second is my "configuration RAR" which contains a copy of the ra.xml from the original rar, and then an ironjacamar.xml configuration file. Both of those are placed in the config rar's META-INF folder.
For each given vendor RAR, the ironjacamar.xml file can be generated using rar-info.sh which is included in the Iron Jacamar 1.1 download. The procedure is described in the section titled 10.1. Resource adapter information tool int the user guide.
Using ActiveMQ 5.8.0 as an example:
The generated ironjacamar.xml is extracted from the full output of the rar-info.sh output. Within the file, it is titled:
Deployment Descriptor:
----------------------
The extracted part of the file that will become ironjacamar.xml starts after that header and ends with </resource-adapters>.
The following edits should be applied:
Remove the opening <resource-adapters> and <resource-adapter> tags and replace with an <ironjacamar.xml> opening tag.
Remove the opening <archive> tag.
Remove the closing </resource-adapter> and </resource-adapters> tags and replace with an </ironjacamar.xml> closing tag.
There are sample definitions for connection factories for each type of connection (Connection, Queue and Topic) which include a JNDI name where JBoss will bind the factories to. Edit these as you see fit. I only needed the Connection factory so I edited the JNDI name and deleted the other two definitions.
There are sample definitions for destination references (which are almost un-necessary with ActiveMQ, but it's helpful for others). One for a queue, one for a topic. Edit these as you see fit.
The maven dependency:
<dependency>
<groupId>org.apache.activemq</groupId>
<artifactId>activemq-rar</artifactId>
<version>5.8.0</version>
<type>rar</type>
</dependency>
The deployable EAR looks like this:
sample.ear
META-INF
application.xml
activemq-rar.rar (file)
activemq-config.rar (directory)
ra.xml (extracted from activemq-rar.rar or generated)
ironjacamar.xml (generated, then edited)
Actually, the ra.xml can be extracted from the "real" rar, but it is also generated in the IronJacamar rar-info.sh output file, so take it from either.
The application.ear then looks like this:
<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/application_6.xsd" version="6">
<display-name>JBoss7Sample Ear</display-name>
<!-- Sample for WebSphereMQ
<module><connector>wmq.jmsra.rar</connector></module>
<module><connector>wmq-config.rar</connector></module>
-->
<module><connector>activemq-rar.rar</connector></module>
<module><connector>amq-config.rar</connector></module>
</application>
To re-emphasize, this (actually quite simple) work around is important to me because any deployment procedure that starts with "Edit the server file called..... or "In the management console....." is a non-starter in the environment I am targeting. I need to assume no access to a vanilla JBoss 7 (EAP 6.1) internal directories, nor access to the console, as one might deploy at the end of a Jenkins build or the like.. (Not to mention which, editing files to add a deployment is a non-starter all by itself).
This workaround and others can be viewed in more detail in this github project which was setup specifically to share some working configurations which I have found are otherwise fairly difficult to come by.
P.S. Since this is the only offered answer, I am awarding the correct answer to myself, but I'll give it up for a better answer.
While working with an EJB application, why do we require an extra deployment descriptor such as jBoss.xml to configure the JNDI name? Can't we do the same in the ejb-jar.xml file itself?
As it seems from your comment you're interested in setting the remote EJB view JNDI name.
The point is - the JNDI name within the server is defined using Java EE 6 portable JNDI names (every container is required to bind EJBs under those names.)
However, the remote (exported) JNDI name is not specified by any document. This is one of the things that confused me some time ago.
It occurs that either you will use ACC (Application Client Container) or obey to container-specific configuration. This means that there is no portable name of telling the container to expose remote EJB view under specified JNDI names.
Further reading:
http://java.net/projects/ejb-spec/lists/users/archive/2012-11/message/13
http://java.net/projects/ejb-spec/lists/users/archive/2013-01/message/41
When I open a Spring configuration files at my application on Intellij IDEA sometimes it says
File Set Not Configured For The File
and gives me a link
Configure File Set
When I click it it says:
MVC dispatcher servlet
Create New File Set
or opens a new window cnd let me check some files.
What happens when I click them and what is this for? I click MVC dispatcher Servlet and check the code but doesn't see any changes.
What it is for?
this is for IDEA to help you out with dependencies between different files.
For example you have "service-spring-config.xml" and "mvc-spring-config.xml", where the MVC config uses some beans from the Service config. If you add these both files to the "File Set", IDEA will know that these two files represent a single application context.
By knowing that, it will help you autocomplete beans in XML + will inform you if something is not resolvable without you having to actually run the app.
I click MVC dispatcher Servlet and check the code but don't see any changes
This is because you only have a single file (for now). Later on, you can add some other configs that use/reference beans from each other => then it'll become REALLY helpful
From IDEA File Sets documentation:
By combining Spring XML configuration files in a file set you tell IntelliJ IDEA that these files are mutually related. In this way you form a common editing context for these configuration files and get all the associated coding assistance.
Spring file sets on IntelliJ are for grouping related files.
IntelliJ could autodetect some of this groups, for example files that are loaded with ContextLoaderListener on web.xml or default files for DispatcherServlet (That seems to be your case)
When IntelliJ asks to configure a File Set for a Spring file, is 'cause IntelliJ couldn't detect a default way to include in a group, for example files that are loaded within the ApplicationContext's constructor Ex:
new ClasspathXmlApplicationContext("somefile.xml","anotherfile.xml");
When file sets are correctly configured IntelliJ could bring many goodies like auto-complete, navigation, validation, dependency graphs and others
What is the best practice to make changes in beans.xml file in production environment?
Lets imagine Hello World application with one Interface and 2 Implementations. After creating jar and running JVM how can we change implementation in beans.xml without opening jar and reassembling it afterwards?
Is it any trick that permits having beans.xml outside the jar, but without knowing the full file-system path?
On top of suggestion made by OrangeDog, I would suggest considering leaving the beans.xml inside your deployed application AND using the PropertyOverrideConfigurer mechanism.
Configure an override configurer to point to some fixed path outside of the application, something like /opt/configuration/something/override.properties would be ideal. If you can't use an absolute path, you can always try to play with file:../../.. style of paths. Then you can list only the changed values within the override.properties file.
Don't have the XML in a JAR. Your application should be deployed in at least a WAR, which the app server will probably "explode". The folder WEB-INF/classes will be added to the classpath. You can make changes to the exploded XML here and the app server should detect this and reload the app.
Edit:
If you are using plain Java SE, you can use a system property to pass the location of the XML file. System.getProperty("property") in code and -Dproperty=value on the command line.