I use WebSphere 7 and I've set shared libraries as described in this example http://www-10.lotus.com/ldd/portalwiki.nsf/dx/06062009015816PMWEBP3Y.htm
My application is running with this setting, but I can't deploy it (update). At deploy it can't find the classes in the shared libraries. I don't have the error message right now because I had to revert the changes but maybe somebody knows what's missing from the example.
We edited the setupCmdLine.bat file and appended the path where our jars can be found to the classpath variables but i'm sure this is not the right way to do it :)
I assume that ejbdeploy is the cause of the problem? In an ND environment, ejbdeploy occurs on the dmgr as part of the installation, so using an application server shared library wouldn't make sense. For consistency, the same is true for a standalone server. You'll need to use the -deployejb.classpath option to AdminApp to point to your shared library classpath (in ND, the paths must exist on the dmgr). If you're deploying from the admin console, I believe there's an "extra classpath" field you can populate.
Related
On Jelastic, I created a node for building an application (maven), there are several identical environments (NGINX + Spring Boot), the difference is in binding to its database and configured SSL.
The task is to ensure that after building the application (* .jar), deploy at the same time go to these several environments, how to implement it?
When editing a project, it is possible to specify only one environment, multi-selection is not provided.
it`s allowed to specify just one environment
We suggest creating a few environments using one Repository branch, and run updates by API https://docs.jelastic.com/api/#!/api/environment.Vcs-method-Update pushing whole code to VCS.
It's possible to use CloudScripting technology for attaching custom logic to onAfterBuildProject event and deploying the project to additional environments after build is complete. Please check this JPS as an example of the code syntax. Most likely you will need to use DeployProject API method.
I have deployed applications in Websphere 8.5, and I want to modify web.xml, but it seems not working. What I am supposed to do?
While there are documented ways of updating enterprise application files, those were conceived for multi-server deployments and partly are legacy of the previous decade of monster application servers. They are inconvenient for making changes to local development server and it wastes a lot of time.
Upon application deployment, WAS creates (copies/updates) deployment descriptors in the config directory. Then web.xml is used from that location.
You are probably changing web.xml in the location where original application files are kept, thus no effect. You should change the one in config\cells\<cell_name>\applications\<ear_name>\deployments\<app_name>\<war_name>\WEB-INF.
WebSphere writes a second file named web_merged.xml. If you only update the web.xml and replace it you will not update the runtime file used by the container.
Best result I had was using the single file upload function provided within the Admin console or to use the wsadmin or jacl cmd.
The proper way is to update application via console/script.
But I'm assuming you are editing file directly (very hard to guess from your description, I've asked you to describe your procedure).
You need to restart the application to pick up changes in web.xml. See the Hot deploy in WAR files
Two ways:
Update web.xml with WebSphere Web Console
Update web_merged.xml at the same time, and also update the two files in config\cells\<cell_name>\applications\<ear_name>\deployments\<app_name>\<war_name>\WEB-INF
I have multiple applications that share common jars, so I decided to put them in the shared library and add a reference to all the applications.
Now the problem is that when I make a change in one of the jars and put them back I have to re start the server.
The weird thing is that I have to do that on my local system and not on the shared server, i was trying to find the setting that will allow me to upload the jar and see the effect with out restarting the server.
One of the blogs says it it not possible but on the shared server it happens so I am sure it is definitely possible.
Please advice what can be done here.
thanks
It sounds like you've configured the shared library to be a part of the server's classpath. Any JARs on the server classpath are only loaded once on server startup. Changes to these JARs require a full server restart.
Libraries that are added to the application's classpath can be reloaded dynamically. The application will still need to restart when the JAR gets changed but that's a much lighter operation and WAS will often automatically detect a file system change and restart the affected applications.
Check how you've configured your shared library to make sure it's being loaded on the application classpath.
In order to know which revision number the application is built from, we use to give the ears we deploy to Glassfish names like myapp_2012-01-20_rev22123.ear. Then we can simply login to Glassfish and see what version is deployed in the web interface (as the appname is the name of the ear file). A downside of this approach is that we need to do a manual undeploy/redeploy to update the name...
But I would like to script the undeploy/deploy process, and having each version of an ear get a different name is not very suitable to scripting this redeployment process. Glassfish 2 does not support the "list applications" goal that Glassfish 3 has, which I could have used to retrieve the application name to undeploy.
So is there any good strategy that will easily allow us to see what version is deployed of an application, and that does not suffer from the above fault?
It would be preferable if this meant we did not have to change the existing applications (like add a jsp page or something to show the current scm revision), but a change in a Maven build script would be acceptable.
I faced a similar issue, I finally came around it by using maven-buildnumber-plugin and writing a simple servlet to get build information. You can find the details in the blog post I made.
Why not use the built-in GlassFish Server versioning to assign a version number at deploy time? This will also enable you to rollback to prior versions. For example:
asadmin deploy --name MyApplication:2012-01-20_rev22123 MyApplication.ear
There is more information on application versioning here:
http://docs.oracle.com/cd/E18930_01/html/821-2417/gihzx.html#gkhhv
Hope this helps.
As also described here, I'm trying to determine the best way to initialize and update my application's database. I use EclipseLink-JPA2. I distribute a NetBeans platform application.
Considered options:
use create-tables ddl-generation:
The problem with this is that everytime the application runs it will throw exceptions, failing to create the tables. It will be useful only at setup time. This would be similar to placing checking code in the module restored() method.
include the database with the application distribution: the ddl-generation strategy becomes do nothing. I could still use the JPA (at development time) to generate the database files (embedded Java DB).
The best solution would be for the installer/setup (first-time) to call initializing code that creates the database. This precisely what I do with JWS in here. But I don't know how to do that without JWS. A script/jar executed by the installer?
Distribute your NetBeans Platform application via JWS.
It seems like you already have this problem sorted out with JWS, so just use that solution to deploy your NetBeans platform app.
EDIT
An alternative approach would be to use a Module Installer that checks for the existence of a config file. If the file exists then the application has been run before and the setup is not required. If the file doesn't exist then run your setup steps.
Have a look at this tutorial, they're using a module installer to create a login dialog.