JSF portlet + EJB in Tomcat Bundle

[8年前 に Nikos Kritikos によって更新されました。]

Hello everyone,
i would like to know if i can develop a jsf-portlet with my own ejb's and custom jpql or Hibernate in Liferay Tomcat Bundle.
I know that is possible to bypass service builder and use custom jpql or to use ejb in MVC porltets.
But is it possible with JSF portlets iin Liferay Tomcat Bundle?

[8年前 に Philip White によって更新されました。]

Hello Nikos,

We recommend that you please read this thread with the advice given by David Nebinger.

Hope this helps answers your question!

Phil

[8年前 に Nikos Kritikos によって更新されました。]

Thank you Philip,

but this thread is about spring.I want to use EJB.
Is it possible?
If not in Tomcat Bundle, maybe with an application server, like Wildfly?

[8年前 に Philip White によって更新されました。]

You're partly right that the thread discusses Spring, but it also discusses hibernate (for accessing the database).

Basically, Liferay recommends using ServiceBuilder to access the database. David Nebinger also discusses the benefits of ServiceBuilder in other threads, like this one.

Hope this helps!

Phil

[8年前 に Nikos Kritikos によって更新されました。]

David's answer was very useful to help me clarify and express what i want to do in a better way.
I do not want to access liferay's database with hibernate or spring, or use EJB for this.I do not want to access the same tables from multiple portlets also.
What i want to do is have a separate database with a few tables(or some dedicated tablles in the smae db) which only ONE portlet will have access to.
And those tables would be custom created/manipulated from hibernate code and EJB's.
I already know that custom Hibernate and Spring can be used without problems with jsf and MVC portlets in Liferay, i;ve seen many posts on that subject,many people have used hibernate and Spring in their liferay portlets successfully,isn't that right?
I want to know if EJB can be used also.

[8年前 に David H Nebinger によって更新されました。]

Hey, Nikos, wanted to jump in...

First it's important to note that vanilla tomcat does not offer EJB support; you'd have to use a regular JEE server such as glassfish or a TomEE (tomcat + EE functions).

Perhaps you're just considering Hibernate + Spring then, regardless the same concerns get in the way. Any two isolated "apps" (whether EARs or WARs) have class loader boundaries enforced by the containers to ensure there is no bleeding of code/data between them. This also means separate caches (likely dirty), transaction concerns, etc.

And yes, I'm sure you're planning on only one portlet accessing the data. Trust me, I've heard that one before, and rarely does it remain that way.

You're much better off just planning for the future and building out the SB infrastructure. It will save you a lot of time in future rework, will save you a lot of time building and testing your own EJB or Hibernate layer, and it will save you a lot of time by coding up the data access layer yourself.

SB is truly the best choice when it comes to building out a data access layer for the portal, and when it comes to Liferay 7 building on SB now should make your transition to LR7 much easier.

[8年前 に Nikos Kritikos によって更新されました。]

Thanks David,
i understand what you;re saying,
but what if i am sure it is going to be only one?

And what about this article :


https://www.liferay.com/web/matti/blog/-/blogs/using-spring-data-jpa-with-a-liferay-portlet

it is on the official Liferay Site, written 2 months before, saying exaclty the opposite.

[8年前 に David H Nebinger によって更新されました。]

Matti is a great guy and I have a lot of respect for him, and basically what he proposes will work. I too have created Hibernate-based portlets in the past, I know that it works too.

The problem is that we can never be sure that there is going to be only one consumer. We can think that today, but before too long someone wants to integrate the functionality in a JSP hook so it can be exposed in one of the OOTB portlets or someone wants an admin portlet in the control panel to manage key data or a requirement comes up to support reporting or a view-only perspective and someone else wants a dashboard...

I know where you're at, you feel in total control of the source and the project and you know hibernate/jpa/EJB (not SB ) so it doesn't seem worth it to learn and leverage SB. Every time I've been in this position, it has never stayed there.

I say this with all due respect - as an architect or developer you may be spot on with electing to use Hibernate or EJB for other web applications, but if you're going to develop for the Liferay space you will be better served by implementing your data access layer in SB.

[8年前 に David H Nebinger によって更新されました。]

Here's another example, Nikos: https://www.liferay.com/community/forums/-/message_boards/message/69503336.

In that thread (a brand new thread just opened today), the guy started out with what he thought was a simple hibernate implementation to support a portlet. Now he needs to add a hook, probably as some sort of action handler, to do something at portal startup. Because of how the portal actually instantiates the action classes, his class cannot access the spring layer in his portlet, cannot access his hibernate-based data access layer and now basically he's stuck.

If he's smart, he'll ditch the hibernate stuff now and generate a SB layer to be able to expose the data access layer portal-wide.

If he doesn't make the change (either because he can't or won't or ...), he's going to be left trying to hack something together that blows holes in the class loader boundaries or duplicates his hibernate layers between the portal and his portlets or any number of other really, really bad ideas that will be prone to error and maintenance difficulties.

When we recommend staying with SB, we're not doing it lightly. I don't push SB because I'm in love with it or get kickbacks from everyone who buys in or because I have it in for hibernate/jpa/ejb, ... I highly recommend using SB because it is the absolute best fit for building a data access layer in the portal, that it deals with issues that average servlet developers never have to consider and leaves the door open for portal-wide access in the future.

[8年前 に Nikos Kritikos によって更新されました。]

Assuming there is a need for another plugin to access data in the first hibernate/ejb portlet,
why not add the jars to the second one too?
Or access ejb data by using rest services or another service?

[8年前 に David H Nebinger によって更新されました。]

The first problem you hit is dirty caches (entities retrieved from the DB are cached to reduce future hits, but if on app updates the data the other is not aware of it and continues to use a dirty (out of date) copy of the data).

The next issue is resource consumption - the more separate data consumers you have, the more separate DB connections, the more memory you will consume instantiating the support infrastructure, etc.

You may also run into issues with transaction management, data loss (two separate instances try to update same data at same time, either one update outright fails or both succeed but 2nd update overwrites data from the first), ...

Choosing to use REST or some other web service cannot be made lightly. Unlike Liferay's method of leveraging reflection, etc for crossing the class loader boundary, using REST or SOAP or JSON or ... involves adding layers of data marshaling, security, monitoring and more complexity into your system. You must be willing to pay this extra price and must be conscious of the fact that you will be paying for something that you'd get for free by using Service Builder.

Sometimes this level of complexity may seem necessary (an existing service layer that must be leveraged, need to expose data layer to an external system), but since SB will generate these services automatically and expose the same internal services you can use directly within the app container, the choice is still clear.

SB is still the best way to go to implement a data layer within the portal. Period.

[8年前 に Kyle Joseph Stiemann によって更新されました。]

Related post on StackOverflow.