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
Related
I'm looking for a way to customize the Web application name (so to change the Web context accordingly) in Thorntail. I assume that it can be done through the thorntail's maven plugin but I cannot find which is the property to set for it.
Thanks
By default, the context is /, which should be what you want most of the time. To customize it, you can use one of the following options:
1) Pass the thorntail.context.path system property when starting the uberjar: java -jar my-app-thorntail.jar -Dthorntail.context.path=my-context.
2) If you use project-defaults.yml, you can configure it there:
thorntail:
context:
path: my-context
3) Create a file WEB-INF/jboss-web.xml with this content:
<jboss-web>
<context-root>my-context</context-root>
</jboss-web>
(Under the hood, options 1 and 2 are actually transformed to 3, but you don't have to care.)
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
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
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()
I am using "dev:watch *" in a karaf container to simplify my testing.
At the moment I deploy all my bundles as "xyz.SNAPSHOT" - and they are picked up correctly.
Question: If I make released bundles (without this ".SNAPSHOT" - will this dev:watch work too?
It won't work with this command:
karaf#root> dev:watch *
From the help of this command:
It will actually monitor all bundles that have a location matching
mvn:* that have '-SNAPSHOT' in their url.
So you need to pass the bundle IDs or urls to the watch command, instead of *. Then Karaf will start watching this non "snapshot" bundles.
Short answer: yes!
The dev:* commands are really useful (dynamic-import is another good one). If you see wiring errors when using dev:watch (i.e. starts referring to two versions of the same bundle, eg. bundle 37.0 and 37.1) then it's a good hint that packages from the original bundle are still being used - this indicates that references aren't being released properly.