Im working in Liferay 5.2.3 and i need to load data (create page, add portlet in some page, create some structure, add web content in the structure..).
I heard that a way to do that is to use hook to deploy this script (java class which user liferay api to load data), but i think that a hook project liferay must not be use in this way, the data should be load one time and not always, the load data doesn't modify the behavior liferay, just load data...
Do you think Using Hook for this case is a good way ? Or I should use a normal project java to load data which i will launch by a executable file.
Thank you.
Have a look at the sevencogs-hook code: This does exactly what you're asking for (and neatly documents the use of the API)
Careful though: In 5.2.3 it checks if "Bruno" exists in the database (the sevencogs administrator) - if he's not there, it will wipe out the contents and populate it with the sevencogs data. Later versions use an upgrade action that is a lot safer, e.g. running only once.
And - you really want to upgrade to the latest version: 5.2.3 is ancient
Related
I'm trying to use an Updatesite.nsf to deploy jar to a test server. I can see it in this case the jdbc driver plugin at the server console using the http osgi ss command. But when I use it I get a java.lang.ClassNotFoundException com.mysql.jdbc.driver. What I'm missing or doing wrong. Thank you
The immediate answer is that the code that's calling Class.forName will need to have the MySQL driver in its classloader one way or another, which an XPage or in-NSF Java won't have by default.
To expand on it a bit:
If you're trying to call it from an XPage or Java code in an NSF, it would have to be part of an XPages Library from another plugin, which in turn depends on and re-exports the driver plugin.
If you're trying to call it from another plugin, that other plugin should have a Require-Bundle or Import-Package entry to bring it in.
The class will be available to NSFs by default if you plunk it in jvm/lib/ext, though that admittedly gives up the niceties of OSGi-based deployment.
The reason it works for the XPages JDBC support is that the wrapped plugins created by the wizard in Designer include a special extension point to provide the driver class to the ExtLib code that wants it, but they don't make it automatically available to XPages apps themselves.
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 need to share a library (built in-house) between portlets and I prefer to put it in a common place instead of adding it as dependency to every portlet that need it because I want to update the library once. Can I build a hook or ext plugin that the portlets can refer to and access the library? I know that you can add it to the common library directory and add it to liferay-plugin-package.properties for each portlet but the location depends on the application server. I want to know, there is a standard or cleaner way to do this? Thanks in advance.
With the tomcat bundle, the common usage is to put these in the tomcat/lib/ext folder.
There is one big drawback, every modification in this folder will require a server restart.
I'm considering using CouchDB for an upcoming web development project.
What is the best way to keep the CouchDB document repo in sync between various developers who are all running the application locally?
An Example: Suppose Developer A creates a new view or design document in Couch or just simply adds a field to an existing view. They also check in some client-side code that expects that field to be on the CouchDB view. Developer B comes in and updates to the latest source code, pulling down Developer A's client-side changes. How does Developer B get the Couch changes that accompany the client-side code?
In a typical RDBMS, this would be accomplished by checking a set of SQL files or database migrations into the SCM system. After Developer B updates his code he would run the new SQL or migration scripts to upgrade his database schema.
Perhaps in Couch there is a way to export/import design docs and view definitions and check those into an SCM system? Perhaps I just need my RDBMS background brainwashing to be deprogrammed.
I've typically kept .js files of my views' map and reduce functions, and stored those in my code repository. A common pattern is to have a folder for each view, and a separate .js file for each view function (map/reduce). An example:
views/
tags/
map.js
reduce.js
users/
map.js
reduce.js
The content of views/tags/map.js is simply the JavaScript map function, for example:
function(doc) {
if(doc.tags && doc.tags.length) {
for(var index in doc.tags) {
emit(doc.tags[index], null);
}
}
}
You can then manage your views any way you choose, possibly using CouchApp or something like it to sync everything to a CouchDB instance. Of course, I don't know what the "best practice" is, but this is what I've done and it works well with my team.
Low-tech solution:
Export to file with couchdb-dump
Import from this file with couchdb-load
The export-import file format seems to be kind of JSON, making it not unlike moving SQL files around.
Ryan's suggestions above is a good one. DB::CouchDB::Schema is a perl library that has a script bundled that can export and import your design documents. It might help automate the job for you.