I have an enhanced ear with ibm-application-bnd.xml defined as
<?xml version="1.0" encoding="UTF-8"?>
<application-bnd xmlns="http://websphere.ibm.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-application-bnd_1_0.xsd"
version="1.0">
<security-role name="myRole">
<special-subject type="ALL_AUTHENTICATED_USERS" />
</security-role>
This myRoleis also defined in the WAR web.xml. The mapping between the role and ALL_AUTHENTICATED_USERS worked fine in WAS6.1, but in WAS8 after I deploy de EAR I can see in "Security role to user/group mapping" that myRole Special Subjects mapped as none. I have to manually map the special subjects to "All Authenticated...".
I've tried creating an ibm-application-bnd.xmi instead, but I'm currently not using RAD and have no idea if it's possible to do it in eclipse, since it has these generated ids like ApplicationBinding_1332889227228 that I don't know how to fill!
Basically it may be a good idea to (1) deploy your EAR manually and set up all missing config data during this process as needed, and (2) have a look on the descriptor files generated by WAS8 afterwards. At least when moving from 4 to 5 and later on to 6 we used this "technique" to figure out how ready-to-go vendor-specific descriptors should look like. It may be necessary to strip off all pre-prepared vender-specific descriptors before executing this step.
2 Additional hints:
(a) WAS8 documentation says that WAS8 supports all previous J(2)EE standards, but generally XMI files are deprecated and should be replaced by XML files. But the "id problem" remains, since WAS8 also refers from vendor-specific files to standards compliant files by element IDs used in URL-like references. Thus any deployment of un-prepared EARs will create IDs inside the Java EE standard descriptors.
(b) It may be useful to do some research about the "new" name of your special subject: It looks like this name has simply changed from 6.1 to 8.x. For this purpose you also should take a closer look at the generated descriptor files after a successful manual EAR deployment.
Related
While using Websphere 7, I had in my EAR a nice little file called deployment.xml which told my WAS server to configure the deployment to PARENT_LAST. I had this file at
/MyEAR/META-INF/ibmconfig/cells/defaultCell/applications/defaultApp/deployments/defaultApp/deployment.xml
When moving to Websphere 9, it appears it is no longer honoring this directive. I go to the admin console and can see it thinks the EAR is deployed with PARENT_FIRST under "Class loading and update detection"
here is the text of the xml
<?xml version="1.0" encoding="UTF-8"?>
<appdeployment:Deployment xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:appdeployment="http://www.ibm.com/websphere/appserver/schemas/5.0/appdeployment.xmi">
<deployedObject startingWeight="10" warClassLoaderPolicy="SINGLE" xmi:type="appdeployment:ApplicationDeployment">
<modules startingWeight="10000" uri="Provider_lfcPractice_ImplWeb.war" classloaderMode="PARENT_LAST" xmi:type="appdeployment:WebModuleDeployment"/>
<classloader mode="PARENT_LAST"/>
</deployedObject>
</appdeployment:Deployment>
Is there still a way to configure the EAR to deploy the war with PARENT_LAST in websphere 9?
This should still work. Check this Select installation options settings, it talks about the deployment.xml
Process embedded configuration
Specifies whether the embedded configuration should be processed. An
embedded configuration consists of files such as resource.xml,
variables.xml, and deployment.xml.
So make sure that that checkbox is selected, as it is off by default. Also if you are deploying via wsadmin script, make sure that you are using that option.
The other way, would be to select all the options after installation that you require, export that ear and compare it to the one that you are installing.
With Gas's comment it was clear it should work. What happened to me is that I had added maven nature to the EAR at one point. Bad idea. Even though I had already removed the maven nature, it corrupted the file
org.eclipse.wst.common.component
It was missing the line
<wb-resource deploy-path="/" source-path="/"/>
When I added that line back, my deployment.xml file began working as expected
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.
So i got some critical Servlets in my webapplication which shall not reach prod but are used for testing. The path is secured with special rights, but as the rights have to be configured on every server correctly, there could be a security leak. My idea was to alter the deployment descriptor so only the web.xml for dev has the necessary configurations.
Therefore i created variables in my web.xml file to inject my servlets in dev environment. I got 2 filter files, 1 which replaces the constants with an empty string and the other for the servlet configuration.
I got 2 executions (1 default and 1 with classifier dev) which point to the right filter files. I use filteringDeploymentDescriptors and the path to the filter.
This works perfectly fine.
But now I need to also create a default and a dev war file for my 2 overlay projects. Unfortunatly it seems as if the web.xml is already filtered in the step when packing the overlay projects.
I welcome any ideas of how to solve this problem.
Thanks in advance!
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.
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.