フォーラム

ホーム » Liferay Portal » English » 6. Portal Framework

構造的に表示 平面上に表示 ツリー上に表示
スレッド [ 前へ | 次へ ]
toggle
Hiran Chaudhuri
Liferay SDK and "common" java classes
2011/09/18 13:36
答え

Hiran Chaudhuri

ランク: Regular Member

投稿: 174

参加年月日: 2010/09/01

最近の投稿

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
RE: Liferay SDK and "common" java classes
2011/09/18 22:59
答え

Samuel Kong

LIFERAY STAFF

ランク: Liferay Master

投稿: 935

参加年月日: 2008/03/10

最近の投稿

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
RE: Liferay SDK and "common" java classes
2011/09/19 1:30
答え

Hiran Chaudhuri

ランク: Regular Member

投稿: 174

参加年月日: 2010/09/01

最近の投稿

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
RE: Liferay SDK and "common" java classes
2011/09/19 1:38
答え

Jay Patel

ランク: Regular Member

投稿: 116

参加年月日: 2010/02/23

最近の投稿

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
RE: Liferay SDK and "common" java classes
2011/09/21 13:35
答え

Hiran Chaudhuri

ランク: Regular Member

投稿: 174

参加年月日: 2010/09/01

最近の投稿

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
RE: Liferay SDK and "common" java classes
2012/07/12 8:23
答え

Jay Patel

ランク: Regular Member

投稿: 116

参加年月日: 2010/02/23

最近の投稿

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
RE: Liferay SDK and "common" java classes
2012/07/12 8:30
答え

David H Nebinger

ランク: Liferay Legend

投稿: 6274

参加年月日: 2006/09/01

最近の投稿

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
RE: Liferay SDK and "common" java classes
2012/07/20 13:53
答え

Jay Patel

ランク: Regular Member

投稿: 116

参加年月日: 2010/02/23

最近の投稿

Hi David,

What should be the better way of doing this then?

-Jay.
David H Nebinger
RE: Liferay SDK and "common" java classes
2012/07/20 16:04
答え

David H Nebinger

ランク: Liferay Legend

投稿: 6274

参加年月日: 2006/09/01

最近の投稿

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
RE: Liferay SDK and "common" java classes
2012/07/20 18:42
答え

Hitoshi Ozawa

ランク: Liferay Legend

投稿: 7990

参加年月日: 2010/03/23

最近の投稿

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
RE: Liferay SDK and "common" java classes
2012/07/20 21:39
答え

David H Nebinger

ランク: Liferay Legend

投稿: 6274

参加年月日: 2006/09/01

最近の投稿

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
RE: Liferay SDK and "common" java classes
2012/07/20 22:20
答え

Hitoshi Ozawa

ランク: Liferay Legend

投稿: 7990

参加年月日: 2010/03/23

最近の投稿

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
RE: Liferay SDK and "common" java classes
2012/07/30 12:54
答え

Jay Patel

ランク: Regular Member

投稿: 116

参加年月日: 2010/02/23

最近の投稿

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 /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
RE: Liferay SDK and "common" java classes
2012/07/31 6:21
答え

David H Nebinger

ランク: Liferay Legend

投稿: 6274

参加年月日: 2006/09/01

最近の投稿

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 /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
RE: Liferay SDK and "common" java classes
2012/07/31 7:11
答え

Jay Patel

ランク: Regular Member

投稿: 116

参加年月日: 2010/02/23

最近の投稿

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.