In order to improve the CMS integration on the following points :
1/ more decouple the CMS from the portal
2/ improve the integration of content into portal pages
We should handle content at the portal object level. Today a portal window is implicitely a window that points to a portlet.
It is possible to make the Window agnostic of portlets and introduce to sub interfaces PortletWindow and ContentWindow.
PortletWindow would contain the String reference to the portlet instance and ContentWindow would contain an URI that would point to the CMS content.
This way admins would not have to configure the CMS portlet that points to the appropriate content.
I would like to perform that change for the beta release.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999509#3999509
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999509
"weston.price(a)jboss.com" wrote : In the latest version of the adapter (HEAD), the non-transactional context is handled by the JCA adapter using Local JMS transactions
Ok good, this is what I would expect, and is consistent with how transactional message delivery with MDBs works (convertion of work done outside the global tx into work done inside the global tx).
This means the behaviour expected in http://jira.jboss.com/jira/browse/JBMESSAGING-410 is not going to happen in HEAD anyway.
So I think we are safe to revert the changes in JBMESSAGING-410 and I can get the patch out ASAP.
Everyone agreed?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999506#3999506
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999506
In the latest version of the adapter (HEAD), the non-transactional context is handled by the JCA adapter using Local JMS transactions which was added to support the case where a Bean managed or CMT Not Supported MDB throws a Runtime Exception. Here the JMS and EJB specs differ as to how this should be treated. We had a long thread about this awhile ago when we were trying to address issues with the JBoss beta we were trying to get out the door.
Unfortunately, for this case (and many others) there is no 'correct' behavior as the spec is silent in this regard.
Note the behavior in HEAD is a complete rewrite from the way we originally handled this.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999503#3999503
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999503
"tom.baeyens(a)jboss.com" wrote : david, i don't yet see the point of having a table separation for process definition versions and process definitions. now there is only a process definition version table and the name and version are columns.
Yes, which means that in order to determine the latest version of a process, the generated SQL must select all rows for a process to know what the latest version is.
If we have a separate version table, then only one row from each table need be selected to determine the latest version. This is just one benefit of having normalized database tables. All the tables in jBPM should be normalized unless there is a very good reason not to (which there usually isn't).
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999502#3999502
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3999502