Liferay SDK and "common" java classes

[Hiran Chaudhuri, modificado hace 12 años.]

Is there any mechanism in the Liferay SDK for this use case?

I want to create some classes and compile them into a jar which should then be used as common base for a number of portlets.
Thinking of memory and performance, it would make sense to deploy that into the JBoss lib directory so it is on the classpath for all the portlets.

Now where in the SDK would I have to create such a project and what ant build target would compile/deploy it?
Is that what the ext-Plugins are for?

[Samuel Kong, modificado hace 12 años.]

You shouldn't have to do anything special to compile your plugin. "ant deploy" should work. Just make sure the the "app.server.lib.global.dir" property in build.properties file is pointing to the correct directory.

You should not use an ext plugin for this.

[Hiran Chaudhuri, modificado hace 12 años.]

Samuel Kong:

You shouldn't have to do anything special to compile your plugin. .

When I do not do anything special, my plugin is zipped into a war file and that gets copied into Liferay's deploy directory.

Maybe I need to rephrase my question:
What files will be deployed into ${app.server.lib.global.dir}?

[Jay Patel, modificado hace 12 años.]

Hi Hiran,
You can try following:

-Create your custom classes under ext-service/src.
-Now when you run "Ant" under ext-service, all the classes along with your custom classes will be compiled & the corresponding jar will be copied the global classpath of your application server. e.g. if you are using tomcat then it will be copied under "tomcat-home/lib/ext".

Cheers,
Jay.

[Hiran Chaudhuri, modificado hace 12 años.]

Jay Patel:

-Create your custom classes under ext-service/src.
-Now when you run "Ant" under ext-service, all the classes along with your custom classes will be compiled & the corresponding jar will be copied the global classpath of your application server. e.g. if you are using tomcat then it will be copied under "tomcat-home/lib/ext".

Thank zou, Jay.
I created an ext plugin and saw the deployment runs fine.

[Jay Patel, modificado hace 11 años.]

You are welcome.

Just a note that same way, if you want to expose any services created by your plugin-SDK portlet, you may copy the service jar of it to global class path of your app server. You may write custom ant script for that as well.

-Jay.

[David H Nebinger, modificado hace 11 años.]

This is the old way of sharing service jars and should be avoided since the application server requires manual steps to perform this kind of deployment.

[Jay Patel, modificado hace 11 años.]

Hi David,

What should be the better way of doing this then?

-Jay.

[David H Nebinger, modificado hace 11 años.]

The plugins consuming the service list the portlet providing the service in the required deployment context of the liferay-plugin-package.properties file.

The Liferay IDE will ensure that a copy of the latest service jar (from the local service providing plugin) is copied in.

No server restarts or manual jar relocations required.

[Hitoshi Ozawa, modificado hace 11 años.]

The Liferay IDE will ensure that a copy of the latest service jar

Your suggesting developers to use Liferay IDE here which may be a good idea when doing liferay development.

The plugins consuming the service list the portlet providing the service in the required deployment context of the liferay-plugin-package.properties file.

Have you actually tried this in your production environment and updated the jar file? If you have, you'll find that this isn't a recommended way in production because it requires all portlets using the jar file to be redeployed when the jar file is updated. Tried it and decided not to use it after several jar updates.

[David H Nebinger, modificado hace 11 años.]

We are doing this exclusively in production and have had no problems at all, as long as the existing service method signatures do not change.

The magic is in the CLP classes. If the service jar has code for a method call, Entity getEntity(primaryKey), it doesn't matter if the service jar was not updated when a new method is added or new entites are added.

The only time you get into trouble is when the method signatures change, i.e. Entity getEntity(primaryKey) changes to Entity getEntity(primaryKey, boolean flag), then the CLP fails to find the method to call...

And I really rather this (the copying of the service jar) was a function of the Hot Deployment and not a function of the IDE....

[Hitoshi Ozawa, modificado hace 11 años.]

The only time you get into trouble is when the method signatures change

Some software like liferay where methods aren't depreciated but just dropped? :-)

That said, I was a little bit surprise to see methods marked as being depreciated in Expando utilities. Hope that this will become a norm for other utilites too. :-)

http://docs.liferay.com/portal/6.1/javadocs/com/liferay/portlet/expando/service/ExpandoValueLocalServiceUtil.html

[Jay Patel, modificado hace 11 años.]

David H Nebinger:

The plugins consuming the service list the portlet providing the service in the required deployment context of the liferay-plugin-package.properties file.

The Liferay IDE will ensure that a copy of the latest service jar (from the local service providing plugin) is copied in.

No server restarts or manual jar relocations required.

Hi David,

Looks like good solution, but still have following questions:

1. Service is shared across all the plugins? i.e. if shared by one portlet, will it be accessible from custom hook as well if necessary changes are made to hook's liferay-plugin-package.properties?

2. What happens if I want to expose service classes to any of the extension environment classes? i.e. if I had copied my service jar to [tomcat]/lib/ext, then it will be accessible to ext classes as well, but what happens if I were to use this new feature? Will it be accessible in ext?

3. Is this feature completely dependent on Liferay IDE only? what happens if some developers (e.g. some client's developers can not be enforced to use Liferay IDE) do not use Liferay IDE?

Thanks,
Jay.

[David H Nebinger, modificado hace 11 años.]

Jay Patel:

1. Service is shared across all the plugins? i.e. if shared by one portlet, will it be accessible from custom hook as well if necessary changes are made to hook's liferay-plugin-package.properties?

Hooks (generally) run within the Liferay context so no, it would not be available to them. But you only use hooks for the Liferay entities anyway, no need to use hooks for your own entities, so I don't see this as an issue.

2. What happens if I want to expose service classes to any of the extension environment classes? i.e. if I had copied my service jar to [tomcat]/lib/ext, then it will be accessible to ext classes as well, but what happens if I were to use this new feature? Will it be accessible in ext?

Well EXT plugins have the same liferay-plugin-package.properties file, so I'd guess if you added it as a required deployment context the service jar would get pulled into the EXT plugin and possibly into the ROOT app as well, although I haven't tried any of this.

3. Is this feature completely dependent on Liferay IDE only? what happens if some developers (e.g. some client's developers can not be enforced to use Liferay IDE) do not use Liferay IDE?

That seems to be the case, and it's also the biggest issue, IMHO. I would rather see this as a hot deploy function (so the current service jar is pulled in during deployment rather than during development) or at least a part of the ant build script (so I don't have to constantly keep the service providing plugin open in the IDE even if I'm not the one developing it as in a team situation).

In it's current form it still seems to me to be a better path than the legacy way which required manual jar moving and server restarts, but at the same time I think it would be possible to make it a lot better with just a few minor alterations...

[Jay Patel, modificado hace 11 años.]

Thanks David for your answers, I will try to implement point-2 myself and as far as point-3 is concerned, let's hope that we may have better solution in future like taking care of copying service.jar at deployment time.

-Jay.