We have a WebSphere Application Server 6.1. Session management is configured with replication and timeout etc... (the obvious).
An new project needs some other settings for session management (longer timeout, no replication necessary). There is a check box in the WebSphere Admin Console:
Enterprise Application > appname > Session management > Override Session management
Then the settings in the deployment descriptor are the valid ones. Only proplem is, that is not checked by default and there is no option during deployment to give that information to WebSphere. So our scripted deployment fails to check that and a human has to do it.
Is there another way to do this? Maybe via something in the deployment descriptor?
OK, took me sometime but here is the solution in Jython:
deployedApplication = AdminConfig.getid('/Deployment:<appname>/')
deployedObject = AdminConfig.showAttribute(deployedApplication, 'deployedObject')
sessionMgrAttrs = [['sessionManagement', [['enable', 'true']]]]
AdminConfig.create('ApplicationConfig', deployedObject, sessionMgrAttrs)
AdminConfig.save()
That checks the check box I mentioned via a script (Don't forget to sync to the nodes after that).
Anything you can do through the console can be scripted using wsadmin. So I think you'll neeed to have your script install the the app and then do some additional steps in wsadmin.
Info Centre starting point
Have you looked at Websphere Installation Factory ? You can create customized installation packages where you can add the product and all the fixes and create a bundle out of it so it will be one straight install. While creating these packages you can add pre-install and post-install scripts. I believe you can change the settings by running a script after the install. Try that and let us know if that works.
Here is a link to the page which talks about customizing the install.
Installation Factory
Related
How can I check this in the deployment.xml in Websphere. So when I deploy my application this is already checked.
The name of the XML attribute is "backgroundApplication" (it's not in there by default, as it defaults to "false"); however, deployment.xml is generated by WebSphere at deployment time, so you can't specify this setting prior to deployment.
If you script your application install through wsadmin, you could update your script to add a call to update the setting after the call to install the app. That will get the setting modified right away as part of your deployment process.
I'm using Visual Studio Online's build tools to deploy web applications from a single solution. I've occasionally been running into file locking issues.
Error: Web Deploy cannot modify the file 'Microsoft.CodeAnalysis.CSharp.dll' on the destination because it is locked by an external process.
After some Googling, I believe the "fix" is to stop the web applications before deployment on Azure and start it back up after. Sounds legit.
However, there does not seem to be a straight forward way to do this directly on VSO's build definitions. I've created an "Azure Powershell" build task, but it wants a PS1 file from the repository. It doesn't seem to let me just run Azure Powershell commands (e.g. Stop-AzureWebsite) from here. My team has created a work-around where we have a "run.ps1" that just executes the command you pass as a parameter, but none of us are satisfied by that.
What are we missing? There has got to be an easier way to do this without having a PS1 script checked into source control.
I solved this by installing Azure App Services - Start and Stop extension from Visual Studio Marketplace.
When installed, it will allow you to wrap the Deploy Website to Azure task in your Release definition with Azure AppServices Stop and Azure AppServices Start tasks, effectively eliminating the lock issues.
Check if you are using "/" on the "Web Deploy Package" path for folder separators instead of "\".
i.e. change
$(System.DefaultWorkingDirectory)/My Project/drop/MyFolder/MyFile.zip
for
$(System.DefaultWorkingDirectory)\My Project\drop\MyFolder\MyFile.zip
I noticed that was the only difference between the one I was getting the error and the others (the Restart step I added was not helping). Once I modified the path, I got it working.
Sounds crappy, but fixed my issue.
Did you use the Build Deployment Template that sets the correct msbuild parameters for you for your package? You can see how here. I would create a build using that template and see if you have the same issues. If so ping me on Twitter #DonovanBrown and I will see if I can figure what is going on.
As a rule it is good practice to have any scripts or commands required to deploy your software to be checked into source control as part of your build. They can then be easily run repeatedly with little configuration at the build level. This provides consistency and transparency.
Even better is to have deployment scripts output as part of the build and use a Release Management tool to control the actual deployment.
Regardless having configuration as code is a mantra that all Dev and Ops teams should live by.
I have a Websphere Application Server v8.0, and my job requires me to change the location of my JDBC data source to different values to test in different environments. I traditionally would do this via the admin console and change the settings via the Resources > JDBC > Data sources section, but I'd like to write a script to change these settings. When I run the admin console, where do the settings get stored? I can run the console vis-a-vis the Servers tab in Eclipse (Rational Application Developer) or by navigating to localhost:9044, but I don't know where the settings are stored - which I'd need to write said script.
Can anybody help me out?
From what I remember of WebSphere Application Server, the settings are ultimately persisted to the file system - however you shouldn't be changing them this way because application server config is a messy and complicated business and by directly changing settings you risk destroying your app server.
I'd recommend checking out this redbook, particularly Chapter 8 which describes how you can configure your app server with scripts. Also I seem to recall plans to display the equivalent scripting commands in the admin console.
If it helps, I had a quick look locally and found a reference to my JDBC data source in "resources.xml" located within the websphere directory at...
<server profile root>\config\cells\<aNodeCell>\nodes\<aNode>\servers\<aServer>
In the past I've used xml config to read values for convenience, but not often to update. Instead I have made use of some of the jython script options available and can echo Jim's response to check out the options there in case there is something that would be a viable alternative.
Edit:
There is another link that may be of interest Configuring data access with wsadmin scripting. I've not used this particular feature of wsadmin myself but it does appear to show promise at first glance.
If you want to write a script, then rather than looking at file system write a proper jython script, which will do your modifications in the similar way as you would do it via console.
To make writing script easier you can use:
Command assistance in the console - the Help portlet on the right shows last invoked command in jython
Script library, which already provides some scripts - Automating data access resource configuration using wsadmin scripting
And basic scripting commands - Configuring data access with wsadmin scripting
I was wondering if anyone could help me out. I recently installed Liferay 6.1.2 on our JBoss 7.2.0. No problems with setting up the environment. Documentation was really helpful. But now I'm not making any progress with deploying themes and portlets.
Control Panel > Server > Plugin Installations is not providing any upload functions. Only lists of portlets, themes ans templates respectivly and a hint that Liferay marketplace will take over some day.
Letting the JBoss take care of the deployments doesn't work either. This would be my favored solution, but portlet deployments failed because some liferay classes are missing. Tried to deploy a theme afterwards, which didn't result in errors, but this theme was not available for pages in Liferay. Is letting the JBoss take care of the deployments an option anyway? After all portlets cannot run outside of a portal-environment.
My last try so far was using an auto deploy directory. But since our JBoss is running in domain mode instead of standalone, it seems this is not an option. JBoss log states that the deployment-scanner subsystem can only be installed in standalone mode, not in domain mode.
Has anyone extirienced similar problems and can provide a solution or some helpful tips? Or maybe there is an other solution that I haven't tought of so far. Anyway, I looking forward to hearing from you ;-) Thanks in advance.
Regards
Sebastian
Liferay's "Hot Deploy" process ensures that plugins use the correct versions of Liferay libraries, matching the currently installed portal. If your server does not support hot-deployment, there's another, recommended way to inject these settings and libraries. Look at these properties:
#
# Set this to true to enable auto deploy of layout templates, portlets, and
# themes.
#
auto.deploy.enabled=true
#
# Set the directory to scan for layout templates, portlets, and themes to
# auto deploy.
#
auto.deploy.deploy.dir=${liferay.home}/deploy
#
# Set the directory where auto deployed WARs are copied to. The application
# server or servlet container must know to listen on that directory.
# Different containers have different hot deploy paths. For example, Tomcat
# listens on "${catalina.base}/webapps" whereas JBoss listens on
# "${jboss.home.dir}/deploy". Set a blank directory to automatically use the
# application server specific directory.
#
auto.deploy.dest.dir=
auto.deploy.default.dest.dir=../webapps
auto.deploy.geronimo.dest.dir=${org.apache.geronimo.home.dir}/deploy
auto.deploy.glassfish.dest.dir=${com.sun.aas.instanceRoot}/autodeploy
auto.deploy.jboss.dest.dir=${jboss.home.dir}/standalone/deployments
auto.deploy.jetty.dest.dir=${jetty.home}/webapps
auto.deploy.jonas.dest.dir=${jonas.base}/deploy
auto.deploy.resin.dest.dir=${resin.home}/webapps
auto.deploy.tomcat.dest.dir=${catalina.base}/webapps
auto.deploy.weblogic.dest.dir=${env.DOMAIN_HOME}/autodeploy
auto.deploy.websphere.dest.dir=${env.USER_INSTALL_ROOT}/wsadmin-deploy
You can override these in portal-ext.properties. Configure your JBoss to listen to any directory, here ${liferay.home}/deploy, and configure its dest dir to somewhere else: auto.deploy.jboss.dest.dir=${liferay.home}/for-installation-on-jboss. Then package the resulting content of the dest.dir as *.war or *.ear file and deploy this as usual on your JBoss server. This one will contain all settings and libraries required.
Make sure that ${liferay.home}/for-installation-on-jboss exists before you try to "deploy" to it.
I had a bundle deployed in an Apache Felix (Sling, in fact) host. The bundle contained some configurable elements, and its version was 2.0.
I have updated the bundle to v2.0.1 for some small code changes, and now the bundle will not pick up its configuration correctly - it remains at the defaults set in code rather than picking up the values configured in the Felix Web Console.
There is an error message in the log: "[Configuration Updater] org.apache.felix.scr Cannot use configuration pid=com.mypackage.MyClass for bundle inputstream:my-bundle-2.0.1.jar because it belongs to bundle inputstream:my-bundle-1.0.jar" which sounds like the cause of the issue.
However:
I can't edit the inputstream value through the web interface - only by stopping the server, editing the config file manually, and restarting. Surely when I update the bundle, the config should be updated too?
Although the inputstream specifies v1.0, the bundle did not have a problem when it was upgraded to v2.0. What's made the difference here?
I have done the same thing (though perhaps not exactly!) on two servers, and one server seems to have the config specify inputstream=v2.0 (and the bundle at v2.0.1) and it works fine. What caused inputstream version to update on this server? (Presumably the same as the answer to 2 - I imagine it'll depend exactly which steps in the process have been executed and in what order.)
Any advice gratefully received - I haven't been able to find any documentation that gives instructions or troubleshooting suggestions for administering bundles through the Felix Web Console.
If at all possible, I would simply stop and remove the bundle altogether and install it using Sling , e.g. with the maven-sling-plugin or dropping it in the /apps/myapp/install folder using WebDAV .
I find it easiest to be consistent this way and the installation is nicely automated and it handles bundle upgrades properly.