With Tomcat I moved service builder jar to tomcat\lib\ext. Where in JBoss?

[Gerald Rubin, geändert vor 11 Jahren.]

Where (or do I) move it to in the JBoss bundle (JBoss AS 7.0.1 or 2)?

My guess is C:\jboss\liferay-portal-6.1.0-ce-ga1\jboss-7.0.2\standalone\lib\ext.

But the rest of the Liferay jars that are in Tomcat\lib\ext are in C:\jboss\liferay-portal-6.1.0-ce-ga1\jboss-7.0.2\modules\com\liferay\portal\main, so that's a possibility.

Also, why do I have to move it at all (in either server)? Why can't the build path for my other portlets (in the same war), specify the path to the jar in its original location in webapps\DB-portlet\WEB_INF\lib? I've never done it this way, but I was just wondering?

Thanks.

[David H Nebinger, geändert vor 11 Jahren.]

This was the old way of doing it, and should be deprecated. Updating the service jar in this fashion typically requires filesystem access, moving jars around, and an application server restart. All bad things, IMHO.

Instead the service jar should be included in your portlet in the WEB-INF/lib folder.

The IDE can help with this if you specify the portlet providing the service as a required deployment context in the liferay-plugin-package.properties file. The IDE will ensure that changes in the service jar from the service providing plugin are copied to the service consuming plugins.

[Gerald Rubin, geändert vor 11 Jahren.]

David H Nebinger:

This was the old way of doing it, and should be deprecated. Updating the service jar in this fashion typically requires filesystem access, moving jars around, and an application server restart. All bad things, IMHO.

Instead the service jar should be included in your portlet in the WEB-INF/lib folder.

The IDE can help with this if you specify the portlet providing the service as a required deployment context in the liferay-plugin-package.properties file. The IDE will ensure that changes in the service jar from the service providing plugin are copied to the service consuming plugins.

David, I hope this reply gets to you.

I hate to reject this solution, since it was almost so perfect. I've now been running in dev with the changes you recommended. Boy, did they make things easier. But then I started to see an anomaly that made me think I was going crazy.

Buttons (I use ICEfaces) that used to work no longer do so. I traced it down to one problem: updateXXX.

Background: I have 20 or so entities in my service.xml that I've written what you could call DTOs for. My data structure forms a naturally hierarchical and well-formed tree. The top level is called Household. The DTO is called CompleteHousehold. Its class extends HouseholdClp and is constructed with a reference to my bean (as this) and the Household directly as it comes from the database. I set CompleteHousehold completeHousehold = new CompleteHousehold(this, household). This constructor sets its own fields from the household parameter (I would use super if it were available), but then it builds Lists of the other entities that are in a CompleteHousehold. These in turn build themselves and their sub-lists, etc. So in the bean the one CompleteHousehold holds the entire data structure applicable to the Household of the logged in user.

The CompleteXXX classes know how to add, update and delete themselves from the database. First they do themselves, then the entities in their sublists are asked to handle themselves (all based on a status field).

Update of entities in these sub-lists is what stopped working with your suggested change. (Sorry, I don't have a stack trace, because I've reverted to the deprecated--but working--method.) The exception would happen in the same place no matter which inner sub-list. It would occur in the xxxClp class when invoking a method called something like Methodnn--if that's any help. At the top of the stack trace would be an exception saying updateXXX couldn't be found. It was usually (always?) the update of a Double. The second region of the stack trace would start with an invalid argument type exception (or somehing similar).

I tried everything. Finally, I realized that all this happened after I had taken your suggestion. If you'd like me to switch back to your seggested way in order to see the stack trace exactly, I am willing to do so. I've never added a bug to the bug list, but this certainly is one.

Regards,

Jerry

[Subhash Shah, geändert vor 11 Jahren.]

David H Nebinger:

Instead the service jar should be included in your portlet in the WEB-INF/lib folder.

The IDE can help with this if you specify the portlet providing the service as a required deployment context in the liferay-plugin-package.properties file. The IDE will ensure that changes in the service jar from the service providing plugin are copied to the service consuming plugins.

We had tried this way and found many class loading issues because of the duplication of the same jar as we were using custom POJO classes across portlet plugins which reside in service jars. So finally we had to stick to the older way of placing the service jars.

[David H Nebinger, geändert vor 11 Jahren.]

Subhash Shah:

David H Nebinger:

Instead the service jar should be included in your portlet in the WEB-INF/lib folder.

The IDE can help with this if you specify the portlet providing the service as a required deployment context in the liferay-plugin-package.properties file. The IDE will ensure that changes in the service jar from the service providing plugin are copied to the service consuming plugins.

We had tried this way and found many class loading issues because of the duplication of the same jar as we were using custom POJO classes across portlet plugins which reside in service jars. So finally we had to stick to the older way of placing the service jars.

As long as you're using pure SB-generated code, this method is the appropriate path.

When using custom POJOs, you must create separate interfaces that the POJOs implement. The SB methods should return the interfaces and not the implementations. Depending upon the complexity of your custom POJOs, you may also need to implement the class loader proxies for them (see any of the *Clp.java classes generated by SB to see how to do this).

[Subhash Shah, geändert vor 11 Jahren.]

David H Nebinger:

As long as you're using pure SB-generated code, this method is the appropriate path.

When using custom POJOs, you must create separate interfaces that the POJOs implement. The SB methods should return the interfaces and not the implementations. Depending upon the complexity of your custom POJOs, you may also need to implement the class loader proxies for them (see any of the *Clp.java classes generated by SB to see how to do this).

The POJO classes, I am talking about were value objects and view helpers which combined properties from various SB-generated Model classes. Also, we didn't dig it to that level of creating interfaces for value objects and implementing CLP. Thanks for your comments.

[Subhash Shah, geändert vor 11 Jahren.]

I think the location to place service jars is jboss/common/lib.