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
Related
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.
Might be a stupid question, but in my current maven project i do not have a web.xml in my /web-app/WEB-INF folder.
There is no web-xml in my project and never has been, im trying to add it but my application is non-responsive to anything written in the web.xml. What am i missing?, iv tried specifying the path to it through the config.groovy like:
grails.project.web.xml="web-app/WEB-INF/web.xml"
Am i missing something? Do i need to specify the web.xml in some other config file in order to make my project utilize it ?
Run
grails install-templates
to copy templates that Grails uses for all code generation activities (including "web.xml").
"web.xml" file will be created in "src/templates/war" directory.
You may be able to get away with something similar to this https://stackoverflow.com/a/5891646/107847. It doesn't install separate web.xml but does allow you add what ever content you need or edit any of the generated content.
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.
In WebSphere Application Server 6.1, is it necessary to redeploy the application (WAR/EAR) every time a change is made to a web.xml descriptor file?
Depends on what you refer to by "a change is made to a web.xml descriptor file".
If you made a change to the web.xml file inside your IDE, then obviously this change has to somehow make it to the application server's world. Repackage your WAR file and deploy to WebSphere, for changes to take effect.
If you made a change to the web.xml file inside WebSphere's internal directories (the installedApps directory somewhere underneath the profile) - a practice I'd advise against - then a server restart would be sufficient for the changes to take effect. It goes without saying though, that your changes will disappear next time the application is deployed.
I have problem with deploying JSR168 portlet using xmlaccess. I have no problem with deploy and join to conrete page but I would like to add shared library reference automatically. Is it possible?? I added shared library named 'libshared' using IBM WS console. Can I add this reference in input xml using by xmlaccess?
I don't think you can do this in xmlaccess. But you may try putting a reference to the library under the Manifest.MF file of the META-INF directory of your portlet's war file.
Or could just put the shared jar file under your /shared/ext directory. Or you could put it inside your wps.ear file. Mind you, either of these two solutions would share your library with the entire portal installation, rather than just select portlets.
You can deploy the application using wsadmin or similar and use that to update the classpath (i.e. for the shared library), you can then use xmlaccess to deploy the portlets and reference the previously deployed application - although I think this may only work in WebSphere Portal 6.1.
Give me a shout if you need further details.
I encountered this as well, a while ago... and researched it to the max, including spending some time chatting with IBM's support in various levels.
The XMLAccess protocol doesn't provide for such "system-level" configuration alongside Portlet application deployment; it can only be used to install, customize and uninstall Portlet applications and related artifacts.
If your deployment strategy involves deploying WAR files directly through XMLAccess, then you will have to manually add the shared-library to the application through the WAS admin console; this will have to be done manually because, when deploying WAR files through XMLAccess, an EAR with some random name is being created by WebSphere Portal to "host" your WAR file; hence you can't script the attachment of a shared library.
(alternatively, you may wish to add the shared library to the server's (WebSphere_Portal) classpath)
If your deployment strategy, instead, involves deploying Portlet applications packaged as EARs, then you're in a better position; you could automate the shared-library attachment as part of your EAR deployment process, then use XMLAccess to inform WebSphere Portal about the location, in the EAR, of your Portlet applications (which is what Michael mentioned above; it works in WebSphere Portal 6.0 as well).
Good luck.