I'm trying to overwrite a jsp from a LR 7 module, in the bnd.bnd file of the fragment module you have to provide the version:
Fragment-Host: com.liferay.announcements.web;bundle-version="1.0.6"
Let's assume this version is only supported for example in CE GA3, so what will happen if on CE GA2 or GA4 the bundle-version needs to be different to make it work or should i create multiple fragments modules projects in order to support different original module version ?
If I understand you correctly, you're asking if you can override more than one version of a bundle with the same fragment? I don't think you can, but even if you could, you shouldn't.
From the Liferay Docs on overriding a module's JSPs:
Supplying a specific host module version is important. If that version
of the module isn’t present, your fragment won’t attach itself to a
host, and that’s a good thing. A new version of the host module might
have changed its JSPs, so if your now-incompatible version of the JSP
is applied to the host module, you’ll break the functionality of the
host. It’s better to detach your fragment and leave it lonely in the
OSGi runtime than it is to break the functionality of an entire
application.
Related
I want to use kentico's polls module but I need to add a "tooltip field" and add some extra HTML. Is there a way to clone the module with the same functionality and let me to edit/add fields to the module classes.
I was trying to edit the module but it shows a message saying Classes cannot be created or deleted in installed modules.
Are you trying to modify the class in the module and it's giving that error? Or modify the module info itself?
Some module classes allow edits and additions. If this is not the case for the polling, you have two options.
1: clone or recreate the module and clone the web parts that use it to use your new module. This is the safest but longest task and may require some digging into Kentico drivers using a decompiler like just decompile to find any other code pieces you need to clone and modify.
2: open the database in SQL management studio, and edit the cms_class on that class and manually change the bool values that allow it to be edited. This comes with the risk that on future upgrades it may break it, but it's a small risk.
Is that possible to refresh some dependencies when a node.js application is running ?
For instance, I'm using a specific version of lodash, a new version is released, can I trigger the refresh directly from my app, or I'll add necessariliy to edit package.json and rebuild the app manually?
Just to get a few facts straight:
Once a module is loaded, the operative code lives in memory in the JS interpreter. Changing the file on disk has no affect at all.
Once a module is loaded and other modules have a reference to it, there is no systematic way to replace that module reference with a new one. You could conceivably delete the prior module from the module cache, load a new module, get a new module handle and manually tell every piece of code that was using the prior module that they should switch over to using the new module handle, but that's a lot of custom code and there are likely some caveats to making that work properly in some circumstances.
node.js does not have any built-in way to replace code with a new version of the code.
The usual way to "upgrade" your code is to replace the code with the updated code and then restart your app so it will load the new version of the code.
Is that possible to refresh some dependencies when a node.js application is running ?
So, it is technically feasible to manually delete a module from the module cache, then manually load an update version of the module and then manually tell everyone who was using the old module handle that they should switch over to the new module handle. But, this all assumes that there's no state in the original module that needs to be preserved and assumes that you have some way of giving every user of the module a new module handle. It's a big hand coded project with a lot of limitations (e.g. only works in very limited circumstances).
For instance, I'm using a specific version of lodash, a new version is released, can I trigger the refresh directly from my app or I'll add necessariliy to edit package.json and rebuild the app manually?
Replace code with updated code, restart your app. That's the usual way.
I deployed a portlet in liferay 7 and it got deployed successfully and was available for use. I want to replace the jsp file, in earlier version I could see my application in tomcat/webapps folder and replace it quickly.
Now I am unable to locate the exploded war in liferay 7. I can only see the war in osgi/war folder.
Can someone help me with that.
Thanks in advance.
While I mostly agree with what Olaf wrote, I do understand the need to be able to make changes in JSP files and try them quickly during development. I'm afraid I don't have the solution for that yet.
However, let me answer the question you asked:
where is war exploded in Liferay 7 tomcat after getting copied in osgi folder
It is NOT (at least not the way it was done by application servers)! When you deploy a WAR file in Liferay 7, it will automatically (on the fly) convert it into OSGi bundle and install it in OSGi runtime. This way now Liferay is fully in charge of deploying plugins and does not need to rely on various application servers.
PLEASE NOTE: Every bundle has it's own state folder. In Liferay those are in <LIFERAY_HOME>/osgi/state. If you know the bundle ID you can easily find it. It may be (I haven't checked) that you'll find some JSP files there. The reason I'm writing this is to warn you (in case you figured it yourself) to NEVER modify bundle's state folder manually. Doing so may brake the whole environment. In worse case scenario you may have to redeploy everything in clean environment.
You should not rely on behavior like this. In previous versions it was the task of the application server to compile changed JSPs at runtime. However, this is bad practice in production systems and totally screws up your maintainability. If you need to update some UI code frequently, I'm suggesting you change your implementation to utilize ADT (Application Display Templates), e.g. through Freemarker or Velocity. Those are meant to be updated at runtime, where the JSP updates were a side effect of Tomcat's default (development friendly, production hostile) configuration
I have a XPage application where I use JavaMail in one of my managed beans. Currently I have added the jar-file C:\Programme\IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jarto the build-path of the manged bean. This works well. But now I want to use a newer version of JavaMail as the Domino server uses version 1.3 but I need version 1.4.x.
I have downloaded the new JavaMail jar-files from Oracle. In Domino Designer (version 9) I add this jar-file to the new design element "Code / Jars" and remove the old jar-files from the build path.
My managed bean is still compiling and running as desired, but if I check the version the bean is using it reports still version 1.3. To check the version number I use the debug property of JavaMail and it's reporting version 1.3 to the domino server console.
Is there a way to tell the domino server to use the jar-files in the application (i.e. the nsf) and not his own? Is there another approach to update the JavaMail version?
The reason I want to use a newer version of JavaMail is as follows: I want to read mails from an imap server with ssl. To avoid the problem of importing ssl-certificates I simply want to trust all hosts. This can be be done via MailSSLSocketFactory, but this is only available since version 1.4.2. Therefore I want to use a newer version of JavaMail.
Another reason I want to use a newer version is as follows: the method "getSortedMessages" of "IMAPFolder" is only available since version 1.4.4. (and so are some other features of JavaMail).
This may be a little too late for you... I think the right approach may be to include the jar file as an OSGi plugin.
I have spent some time to figure out how to do that - and recently succeeded :-) I have described the steps to perform to make this work in two articles. The first is about wrapping a JAR into a plug-in: http://www.dalsgaard-data.eu/blog/wrap-an-existing-jar-file-into-a-plug-in/ - the second is about deployment (and there is a link in the first one).
/John
You can solve the problem by creating an OSGi plug-in that supersedes the one that sports the JavaMail library: com.ibm.designer.lib.javamail.
In order to do that do the following:
Create an OSGi plugin whose id is com.ibm.designer.lib.javamail (Dalsgaard's tutorial on how to do it)
Set its version to a higher number than the one the Domino server is shipped with (to know the version type tell http osgi ss com.ibm.designer.lib.javamail). As of now using 9.0.1.qualifier should be fine
Deploy the plugin either through an update site or by directly copying it under the domino\workspace\applications\eclipse\plugins folder.
Restart the HTTP service. The higher version - the one you created - will now be used
I've got the same problem here, but found a solution. Be warned, this is not the best answer but it will work. Simply download the latest javamail jar here and rename the jar file to 'mail.jar'. Just replace the current file in IBM\Notes\framework\shared\eclipse\plugins\com.ibm.designer.lib.javamail_9.0.0.20130301-1431\lib\mail.jar with this file. Quit the http task and restart it. The code will now work with the latest version.
I have implemented following code to upgrade application
platformrequest("URL TO JAR FILE");
I am checking if the jad file residing on server has more value in the custom field Application-Version than the current one then the platformRequest will get called.
every thing fine
but only one problem I have installed my app in memory card and if I updateusing above mentioned technique.
I am having new version installed saperately..
instead of this I want my older version application to be upgraded [replaced by newer]
in jad file ony I change the Application-Version Field rest every thing are same as the local installed appliction..
and I want my app to be replaced in memory card only.
what phone are we talking about?
In essence it should not matter where the app is located, it should update.
Make sure the platform request should point to the jad of course
I don't think you should be using a custom field/attribute for this.
Are you using the MIDlet-Version attribute in your application's manifest/JAD file? This attribute is used by a device's AMS (application management software) to determine if your pointing to a newer version.
See here for a description of the standard MIDlet attributes.