This content has been marked as final. Show 5 replies
Regarding your query:
"Is it possible in this scenario update a shared library and tell the application to take the new version without stopping the application or interrupting the application’s availability to clients?"
You can always deploy a new version of shared library without undeploying the older one. The manifest file of the shared library will have the elements like extension name, specification version and implementation version , which is read by the weblogic server during runtime when your application tries making the reference/call.
The calls will be routed to the shared library which has the highest specification/implementation version or to the recent library.
Important Note: Ensure to maintain unique Spec/Implementation version number for multiple shared libraries.
Hope this answers your questions !
Refer to blog post - http://middlewaresupport.wordpress.com/2013/03/21/production-redeployment-feature-in-weblogic/ for details on Weblogic production redeployment feature. Let me know if you still unclear.
rank if found useful..!
Edited by: Ranjan K on Apr 25, 2013 3:14 AM
I have deployed a new version of my library in a WAR and no problems. Weblogic console shows the different library versions deployed, but the application that uses the library does not change. I wait to expire the page and does not change. I understand that the library and application configuration are well, since if I select the application in the console and click "update" to force it then it really get the changes, but the application's availability is interrupted...I have to do something else?
The MANIFEST file of the library is this. Is the correct way to specify versions?
Thanks for your help in advance.
It is expected that your application gets interrupted when you're updating the application with the new library.
If you don't want existing client connections to be unaffected, you need to do a side by side deployment, but that feature holding good for updating a application with the new versioned application not the shared libaries.
I see that the alternative way for you to address the issue is by building a new application with the new libaries and deploying the same with the new version number so that the existing connections to the old application will be uninterrupted and all the new requests would be routed to the newly deployed application and the old application retires as soon as it services the existing client requests.
Your answer helped me a lot.