Weblogic caching problems - caching

I'm writing a WLST script to deploy an application with WebLogic 11g. The problem is that when I deploy an application (version A), undeploy it, then deploy version B, it deploys version A.
If I try to solve this by deleting the tmp/_WL_user/appname/ folder, it then won't deploy A or B because it looks in the tmp folder for the application (and fails because I cleared it out). I'm using the nostage option, so I don't understand why it's caching anything.
Any help you can offer would be greatly appreciated. Thanks!

Probably the undeploy of Version A was not successful and Version B was never deployed.
Not sure what you have in the WLST script, could you try with the following:
# let's say the appName is testApp
# can move all of these properties to a props file
appName='testApp'
appPath='/scratch/user/testApp.war'
appTarget='AdminServer'
username='weblogic'
password='weblogic1'
adminURL='t3://hostname:adminport'
# start deploy/undeploy code
connect (username, password, adminURL)
for app in cmo.getAppDeployments():
currAppName = app.getName()
if currAppName == appName :
print('Application' + appName + ' already exists, undeploying...')
undeploy(appName)
# sleep is just to make sure that we don't attempt deploy immediately i.e before server is finished with undeploying
# more like a safe side one, may not be required also
java.lang.Thread.sleep(60000)
print('Now deploying ' + appName)
deploy(appName, appPath, appTarget)
disconnect()

Related

Websphere deployment - MapModulesToServers

Apologies if this has been asked previously but I have the following code in my Props file.
#
# Properties
#
taskName=MapModulesToServers
row0={module uri server ModuleVersion moduletype moduletypeDisplay} # readonly
row1={"MyApplication" MyApplication.war,WEB-INF/web.xml WebSphere:cell=!{cellName},node=!{nodeName},server=!{webserverName}
+ WebSphere:cell=!{cellName},node=!{nodeName},server=!{httpserverName} 23 moduletype.web "Web Module"}
Now I am trying to get the WAR file mapped to both the WebServer and the HTTPServer, both of which are up and running. At present the process only maps to the Web server and we are forced to map to both manually after deployment, which defeats the aim of auto deployment a little.
Can any tell me what is wrong in the script segment please.
thanks in advance
Kev

Deployment with Deployment manager

I am trying to auto-deploy an application to a newly installed Websphere ND with Deployment Manager.
This is what I just did:
Install WebSphere
manageProfiles create, profile name="deployer", template = management, profile type = DEPLOYMENT_MANAGER, cell="ndcell", node="ndnode"
manageProfiles create, profile name="app", template = default, cell = knowncell, node = knownnode
AppServer/profiles/deployer/bin/startManager.sh
AppServer/profiles/app/bin/addNode.sh hostname (this all happens on one same host "hostname")
AppServer/bin/wsadmin -c '$AdminConfig modify [$AdminConfig showAttribute [$AdminConfig getid /Cell:ndcell] monitoredDirectoryDeployment] {{enabled true}}' - turn on monitored directory deployment
AppServer/bin/wsadmin -c '$AdminConfig save'
AppServer/profiles/deployer/bin/stopManager.sh, then startManager.sh
All right, at this point admin console shows one server "server1" which is not started, and there exists the directory AppServer/profiles/deployer/monitoredDeployableApps, that's the good part. The bad part is the directory is empty! There is no "server1" dir there, as it should be, to put my EAR into.
What am I missing?
You have to do a full synchronize in order to Dmgr deem changes to take effect

How to change bundle start level in glassfish 3.1.2 equinox?

I want to change the start level for a bundle in my glassfish. I used equinox as osgi runtime.
I changed the configuration file glassfish\config\osgi.properties and add the folowing line:
osgi.bundles=bundlesymbolicname#5:start
When I connect via telnet and search the bundle with "lb bundleid" I see in the level column 1 instead of 5.
Can anyone help me? What is the problem with my configuration?
Thanks Marco.
You can change in in ${GF_HONE}/glassfish/config/osgi.properties, by update the below item:
# What should be the initial start level of framework.
# For performance reason, initially we set the start level to 1 so that no optional
# bundles can get activated while server is still starting. Once server is started,
# the framework's start level is set to whatever is configured in glassfish.osgi.start.level.final property.
org.osgi.framework.startlevel.beginning=1
# Set bundle start level to be same or less than that of framework,
# otherwise HK2 installed bundles won't be activated.
# See issue #5934
felix.startlevel.bundle=1

Job handler serialization incorrect when running delayed_job in production with Thin or Unicorn

I recently brought delayed_job into my Rails 3.1.3 app. In development
everything is fine. I even staged my DJ release on the same VPS as my
production app using the same production application server (Thin),
and everything was fine. Once I released to production, however, all
hell broke loose: none of the jobs were entered into the jobs table
correctly, and I started seeing the following in the logs for all
processed jobs:
2012-02-18T14:41:51-0600: [Worker(delayed_job host:hope pid:12965)]
NilClass# completed after 0.0151
2012-02-18T14:41:51-0600: [Worker(delayed_job host:hope pid:12965)] 1
jobs processed at 15.9666 j/s, 0 failed ...
NilClass and no method name? Certainly not correct. So I looked at the
serialized handler on the job in the DB and saw:
"--- !ruby/object:Delayed::PerformableMethod\nattributes:\n id: 13\n
event_id: 26\n name: memememe\n api_key: !!null \n"
No indication of a class or method name. And when I load the YAML into
an object and call #object on the resulting PerformableMethod I get
nil. For kicks I then fired up the console on the broken production
app and delayed the same job. This time the handler looked like:
"--- !ruby/object:Delayed::PerformableMethod\nobject: !ruby/
ActiveRecord:Domain\n attributes:\n id: 13\n event_id: 26\n
name: memememe\n api_key: !!null \nmethod_name: :create_a\nargs: []
\n"
And sure enough, that job runs fine. Puzzled, I then recalled reading
something about DJ not playing nice with Thin. So, I tried Unicorn and
was sad to see the same result. Hours of research later and I think
this has something to do with how the app server is loading the YAML
libraries Psych and Syck and DJ's interaction with them. I cannot,
however, pin down exactly what is wrong.
Note that I'm running delayed_job 3.0.1 official, but have tried upgrading to
the master branch and have even tried downgrading to 2.1.4.
Here are some notable differences between my stage and production
setups:
In stage I run 1 Thin server on a TCP port -- no web proxy in front
In production I run 2+ Thin servers and proxy to them with Nginx.
They talk over a UNIX socket
When I tried unicorn it was 1 app server proxied to by Nginx over a
UNIX socket
Could the web proxying/Nginx have something to do with it? Please, any insight is greatly appreciated. I've spent a lot of time
integrating delayed_job and would hate to have to shelve the work or, worse,
toss it. Thanks for reading.
I fixed this by not using #delay. Instead I replaced all of my "model.delay.method" code with custom jobs. Doing so works like a charm, and is ultimately more flexible. This fix works fine with Thin. I haven't tested with Unicorn.
I'm running into a similar problem with rails 3.0.10 and dj 2.1.4, it's most certainly a different yaml library being loaded when running from console vs from the app server; thin, unicorn, nginx. I'll share any solution I come up with
Ok so removing these lines from config/boot.rb fixed this issue for me.
require 'yaml'
YAML::ENGINE.yamler = 'syck'
This had been placed there to fix an YAML parsing error, forcing YAML to use 'syck'. Removing this required me to fix the underlying issues with the .yml files. More on this here
Now my delayed job record handlers match between those created via the server (unicorn in my case) and the console. Both my server and delayed job workers are kicked off within bundler
Unicorn
cd #{rails_root} && bundle exec unicorn_rails -c #{rails_root}/config/unicorn.rb -E #{rails_env} -D"
DJ
export LANG=en_US.utf8; export GEM_HOME=/data/reception/current/vendor/bundle/ruby/1.9.1; cd #{rail
s_root}; /usr/bin/ruby1.9.1 /data/reception/current/script/delayed_job start staging

Embedded Glassfish v3: deploying sun-resources.xml programmatically fails

I would like to be able to package my jpa-ejb-web project as a standalone application, by using Glassfish embedded API.
To use the JPA layer, I need to deploy the sun-resource.xml configuration, which should be possible with the asadmin command add-resources path\to\sun-resources.xml. I've this code to do it:
String command = "add-resources";
ParameterMap params = new ParameterMap();
params.add("", "...\sun-resources.xml" );
CommandRunner runner = server.getHabitat().getComponent(CommandRunner.class);
ActionReport report = server.getHabitat().getComponent(ActionReport.class);
runner.getCommandInvocation(command, report).parameters(params).execute();
but Glassfish refuses it with:
15-Jul-2010 16:34:12 org.glassfish.admin.cli.resources.AddResources execute
SEVERE: Something went wrong in add-resources
java.lang.Exception: ...\gfembed6930201441546233570tmp\lib\dtds\sun-resources_1_4.dtd (The system cannot find the path specified)
at org.glassfish.admin.cli.resources.ResourcesXMLParser.initProperties(ResourcesXMLParser.java:163)
at org.glassfish.admin.cli.resources.ResourcesXMLParser.<init>(ResourcesXMLParser.java:109)
at org.glassfish.admin.cli.resources.ResourcesManager.createResources(ResourcesManager.java:67)
at org.glassfish.admin.cli.resources.AddResources.execute(AddResources.java:106)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$1.execute(CommandRunnerImpl.java:305)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:320)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.doCommand(CommandRunnerImpl.java:1176)
at com.sun.enterprise.v3.admin.CommandRunnerImpl.access$900(CommandRunnerImpl.java:83)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1235)
at com.sun.enterprise.v3.admin.CommandRunnerImpl$ExecutionContext.execute(CommandRunnerImpl.java:1224)
at javaapplication4.Main.main(Main.java:55)
and indeed, there is no lib directory on the indicated path ...
is there something wrong in my code? (I use glassfish-embedded-all-3.0.1.jar)
Thanks
I solved it by specifying an Embedded File System for the embedded Glassfish, and prepopulated the /path/to/my/glassfish/lib/dtds folder with the files which were missing.
EmbeddedFileSystem.Builder efsb = new EmbeddedFileSystem.Builder();
efsb.autoDelete(false);
efsb.installRoot(new File("/path/to/my/glassfish"), true);
EmbeddedFileSystem efs = efsb.build();
Server.Builder builder = new Server.Builder("test");
builder.embeddedFileSystem(efs);
builder.logger(true);
Server server = builder.build();
server.addContainer(ContainerBuilder.Type.all);
server.start();
and asking Glassfish not to delete the folder at the end of the execution.
I'm not sure this is possible, Running asadmin Commands Using the Sun GlassFish Embedded Server API doesn't mention such a use case (passing a sun-resources.xml).
But I would use a preconfigured domain.xml instead of trying to deploy a sun-resource.xml file, the result should be similar. From the Sun GlassFish Enterprise Server v3 Embedded Server Guide:
Using an Existing domain.xml File
Using an existing domain.xml file
avoids the need to configure embedded
Enterprise Server programmatically in
your application. Your application
obtains domain configuration data from
an existing domain.xml file. You can
create this file by using the
administrative interfaces of an
installation of nonembedded Enterprise
Server. To specify an existing
domain.xml file, invoke the
installRoot, instanceRoot, or
configurationFile method of the
EmbeddedFileSystem.Builder class or
a combination of these methods.
The documentation provides code samples showing how to do this (should be pretty straightforward).

Resources