I mean, If I'm using ServiceBuilder and I have a hierarchical entity that would have to be declared like this , I can't create additional portlet-hbm.xml definition, can I ? Moreover it would be impossible due to the other relevant entity relationships declared in service.xml. Then I would have the entity declared in Hibernate, but persistence layer created by serviceBuilder wouldn't be aware of it, because I couldn't declare the entity in service.xml.
I hope it makes sense. I bet that after some time when I read this flow of my mind I'll be embarrassed
I hope it makes sense. I bet that after some time when I read this flow of my mind I'll be embarrassed
Yes, it does make sense.
To be honest, on some projects we decided to drop Service Builder because of its limitations and we use standard Spring Portlet MVC - Hibernate couple. And sometimes we use both
You can definitely create additional portlet-hbm.xml definition. Look into your /META-INF/hibernate-spring.xml file (generated by Service Builder). There is specification of PortletHibernateConfiguration class. This class is responsible of loading the config file:
So just override this spring definition using your own class. I'm sure you now know how to continue
Just keep in mind that everything you write into the hibernate configuration files won't be managed by Service Builder. It's up to you whether this is disadvantage or advantage
-- tom
To be honest, on some projects we decided to drop Service Builder because of its limitations and we use standard Spring Portlet MVC - Hibernate couple. And sometimes we use both
You can definitely create additional portlet-hbm.xml definition. Look into your /META-INF/hibernate-spring.xml file (generated by Service Builder). There is specification of PortletHibernateConfiguration class. This class is responsible of loading the config file:
public class PortletHibernateConfiguration
extends PortalHibernateConfiguration {
protected ClassLoader getConfigurationClassLoader() {
return PortletClassLoaderUtil.getClassLoader();
}
protected String[] getConfigurationResources() {
return new String[] {"META-INF/portlet-hbm.xml"};
}
}So just override this spring definition using your own class. I'm sure you now know how to continue
Just keep in mind that everything you write into the hibernate configuration files won't be managed by Service Builder. It's up to you whether this is disadvantage or advantage
-- tom
Tomáš Polešovský:
You can definitely create additional portlet-hbm.xml definition. Look into your /META-INF/hibernate-spring.xml file (generated by Service Builder). There is specification of PortletHibernateConfiguration class. This class is responsible of loading the config file:public class PortletHibernateConfiguration extends PortalHibernateConfiguration { protected ClassLoader getConfigurationClassLoader() { return PortletClassLoaderUtil.getClassLoader(); } protected String[] getConfigurationResources() { return new String[] {"META-INF/portlet-hbm.xml"}; } }
So just override this spring definition using your own class
...
If I understood correctly, the proposition here is to replace PortletHibernateConfiguration with out own implementation. Right?
If so, I can only assume that this could be done with META-INF/ext-spring.xml, or by replacing the entry right in the META-INF/hibernate-spring.xml (it will be overwritten at subsequent build-service). Anyway let's say we did place our own implementation: what about PortletHibernateConfiguration's and PortalHibernateConfiguration's functionality? From my minimal understanding, I assume it will be lost and therefore something will not work correctly.
On the other hand the statement
Tomáš Polešovský:
So just override this spring definition using your own class.would make perfect sense if we could extend PortletHibernateConfiguration and override etConfigurationResources(), but we can't because it's in portal-impl.jar (Yeah I know, we can use an ext-plugin, I'm trying not to resort to that at the moment
). Finally, there's always the promising definition of META-INF/ext-hbm.xml, in portal.properties, but I'm not sure how exactly I'm going to combine this with spring. From plain-hibernate point of view I'm missing the way to add a mapping of a class. I assume I could use my own hibernate.cfg.xml but I'm afraid there will be ramification on the functionality of 'liferaySessionFactory' bean, defined in META-INF/hibernate-spring.xml.
Having mentioned that by the way, could there be a way to fetch all the configuration values of the PortletHibernateConfiguration, somehow? It would be cool, since it would relieve one from the burden to maintain this info twice, in portal and portlet level (assuming everything else worked haha!) EDIT: Could we use com.liferay.portal.kernel.util.PropsUtil? Is PropsUtil.getProperties("jdbc.default.", true);enough?
Of course that would raise yet another issue, that of controlling the load order of apps in the application server: liferay should load before our portlet so that if there was a way to fetch the configuration, it should be performed after the information would be available. I'm not sure but I think that, in LR 6.0.6 that was taken care in tomcat 6 bundle by setting
<host ... deployxml="false"></host>P.S. I liked your former avatar better
MICHAIL MOUDATSOS:
but we can't because it's in portal-impl.jar (Yeah I know, we can use an ext-plugin, I'm trying not to resort to that at the momentFor anyone that might be interested in this here's a perspective. Not very elegant but works. Concerning my quotes:
...
From plain-hibernate point of view I'm missing the way to add a mapping of a class.
...
P.S. I liked your former avatar better
1) I had to use an ext-plugin to override PortletHibernateConfiguration class in portal-impl project. I essentially added my custom hbm.xml there, let's say META-INF/portlet-ext-hbm.xml. Actually, what I did, was to read from portal-ext.properties a custom property let's say hibernate.configs.portlet where a list of included hbm.xml-like definitions should be listed, in order to make it more elegant and customizable. For example I listed in that property both the original META-INF/portlet-hbm.xml and my custom portlet-ext-hbm.xml (comma separated). If no such property existed I used the default configuration (only META-INF/portlet-hbm.xml).
There! I finally had a way to extend the hibernate entity mappings generated by service builder. As an added bonus I could use any inheritance strategy I wanted and even define multiple levels of inheritance, not to mention inter-entity mapping associations (Oh yeah!)
2)While testing this, I figured out that I didn't even have to explicitly declare this mapping anywhere else (that is, I didn't have to do a mapping such as the one done in session-factory configuration) It just worked!
"OK..." one would say, "How did you figure out that it worked?" Here comes the interesting part...
Since I had my entities defined, I wanted a session to test against. So in a LocalServiceUtil (practically in xxxImpl) I fetched the EntityPersistence and opened a session. That was it! I could do a session.save()! But I got greedy and wanted more! I tried the EntityLocalServiceUtil.update(), merely by passing my extended, hibernate mapped, object and it worked! It saved all its data (both the service builder defined part and my own extended one even in a multi-level inheritance scheme using joined-subclass definitions!) "How cool!" I thought
For the get part I just had to call session.get() and pass the extended Entity's Class along with the identifier. It worked like a charm! I could even make a LocalServiceUtil method where I passed the identifier along with a Class<?> argument. Of course,I had to return the service builder's model interface, whose implementation constituted the base of my inheritance, but that incorporated no problems since my own classes already implemented that interface thanks to inheritance! So the only implication was that I had to typecast the result to the class I already gave as a parameter, but this is nothing unusual, when fetching objects with get() anyway!
The only tricky part was how to get all the entities (or better how to do a [hql] query) using this approach. Iwanted to make a service method to perform this task, such as EntityLocalServiceutil.getEnttiies(), so I browsed through code to see how it was done in the generated code and figured out that an HQL query was done. "OK" I said, "I'm going to do the same!". Alas! "Not so fast pal!". One negligible pitfall here is that in META-INF/portlet-hbm.xml definition there was an auto-import="false" configuration, which I chose to follow in my own mapping file, thus I had to use fully qualified Entity names in HQL queries to avoid the relative errors. But as I said, that was the least of my problems. When it came down to perform the query I tried to use what generated code did, i.e., run
com.liferay.portal.kernel.dao.orm.QueryUtil.list(com.liferay.portal.kernel.dao.orm.Query query, com.liferay.portal.kernel.dao.orm.Dialect dialect, int start, int end)
I provided my query, all pos for start and end, and for the dialect I typed my fetched entityPersistence.get... ...and where is the getDialect() method? It was not defined in the interfaces contract!
I assumed my EntityPersistence interface referrence was actually a EntityPersistenceImpl object but no! Typecasting yielded errors since it was some Proxy... I meticulously browsed through the exposed methods, using reflection and there it was! So I fetched the method using reflection and invoked it on the proxy object, got my dialect and ran my query. I know... "Yaiks...!". It couldn't have been less elegant! But it did the job... If any one knows a more robust and correct way to do that, please share it! Oh, I forgot to say that I was able to return a List<?> as a method result, which is what QueryUtil.list(...) returns too, so I could cast my method's result to any inherited class for which the method was called (Of course I had passed the Class<?> which I was querying against)
All the above pretty much cover the majority of stuff one would want to do with his/her extended entities.
3) Tomáš, put your former avatar back! (I believe I express the sentiments of many community members
) Maybe, it was not that Enterprise-friendly, but it is more fun (and probably more community-friendly )!