You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Randy Watler (JIRA)" <je...@portals.apache.org> on 2009/05/16 06:06:45 UTC
[jira] Created: (JS2-1015) Unattached portlet definitions left in
DB after registry unit tests run
Unattached portlet definitions left in DB after registry unit tests run
-----------------------------------------------------------------------
Key: JS2-1015
URL: https://issues.apache.org/jira/browse/JS2-1015
Project: Jetspeed 2
Issue Type: Bug
Components: Portlet Registry, Testing
Affects Versions: 2.2.0
Environment: J2 2.2 trunk
JDK6/Linux/x86_64
Reporter: Randy Watler
Assignee: Randy Watler
Portlet definition clone tests fail to properly clean up after cloned portlet definition is removed in unit tests. On the next unit test case invocation w/o clearing the database, queries for all portlet definitions fail when orphaned portlet definitions w/o a portlet applications are added to the registry cache and fail.
Preliminary investigation indicates that the registry OM is not utilizing removal aware collections for persistent collections, but the test cases are trying to remove persistent members using operations on the transient collection implementations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Updated: (JS2-1015) Unattached portlet definitions left in
DB after registry unit tests run
Posted by "Randy Watler (JIRA)" <je...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/JS2-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Randy Watler updated JS2-1015:
------------------------------
Attachment: page-manager-ojb-collections.patch
registry-ojb-collections.patch
Resolved this issue with attached registry-ojb-collections.patch: replaced all OM persistent collections and lists with removal aware versions as done with DBPM component. Note, however, that these collections are not synchronized, (the DBPM uses synchronized collections to protect against concurrent modification exceptions). This patch contains the ability to switch implementations if desired in the future.
The attached page-manager-ojb-collections.patch contains changes necessary to implement synchronized collections that are also removal aware. This related problem was discovered while debugging modifications for the registry component. The patch also upgrades the synchronization of page manager OM collections to include collections loaded from the database, (only new collections were synchronized previously). If this is not desired, omit the changes to page-manager-repository.xml when applying patch.
> Unattached portlet definitions left in DB after registry unit tests run
> -----------------------------------------------------------------------
>
> Key: JS2-1015
> URL: https://issues.apache.org/jira/browse/JS2-1015
> Project: Jetspeed 2
> Issue Type: Bug
> Components: Portlet Registry, Testing
> Affects Versions: 2.2.0
> Environment: J2 2.2 trunk
> JDK6/Linux/x86_64
> Reporter: Randy Watler
> Assignee: Randy Watler
> Fix For: 2.2.1
>
> Attachments: page-manager-ojb-collections.patch, registry-ojb-collections.patch
>
>
> Portlet definition clone tests fail to properly clean up after cloned portlet definition is removed in unit tests. On the next unit test case invocation w/o clearing the database, queries for all portlet definitions fail when orphaned portlet definitions w/o a portlet applications are added to the registry cache and fail.
> Preliminary investigation indicates that the registry OM is not utilizing removal aware collections for persistent collections, but the test cases are trying to remove persistent members using operations on the transient collection implementations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-1015) Unattached portlet definitions left in
DB after registry unit tests run
Posted by "Randy Watler (JIRA)" <je...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/JS2-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710581#action_12710581 ]
Randy Watler commented on JS2-1015:
-----------------------------------
The change to PersistenceBrokerPortletRegistry.java is not strictly necessary, but it is more in line with the existing PA and PD APIs. I had originally made this change to ensure that construction of the cloned PD followed existing PD creation paradigms while debugging. We can remove it if desired.
> Unattached portlet definitions left in DB after registry unit tests run
> -----------------------------------------------------------------------
>
> Key: JS2-1015
> URL: https://issues.apache.org/jira/browse/JS2-1015
> Project: Jetspeed 2
> Issue Type: Bug
> Components: Portlet Registry, Testing
> Affects Versions: 2.2.0
> Environment: J2 2.2 trunk
> JDK6/Linux/x86_64
> Reporter: Randy Watler
> Assignee: Randy Watler
> Fix For: 2.2.1
>
> Attachments: page-manager-ojb-collections.patch, registry-ojb-collections.patch
>
>
> Portlet definition clone tests fail to properly clean up after cloned portlet definition is removed in unit tests. On the next unit test case invocation w/o clearing the database, queries for all portlet definitions fail when orphaned portlet definitions w/o a portlet applications are added to the registry cache and fail.
> Preliminary investigation indicates that the registry OM is not utilizing removal aware collections for persistent collections, but the test cases are trying to remove persistent members using operations on the transient collection implementations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-1015) Unattached portlet definitions left in
DB after registry unit tests run
Posted by "Randy Watler (JIRA)" <je...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/JS2-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710068#action_12710068 ]
Randy Watler commented on JS2-1015:
-----------------------------------
For future reference, here is the exception that is generated on subsequent portlet definition queries:
Running org.apache.jetspeed.components.portletregistry.TestRegistryCache
##### platform = MySQL
java.lang.IllegalStateException: Cannot generate a unique portlet name until the application and portlet name have been set
at org.apache.jetspeed.om.portlet.impl.PortletDefinitionImpl.getUniqueName(PortletDefinitionImpl.java:253)
at org.apache.jetspeed.components.portletregistry.RegistryPortletCache.cacheAdd(RegistryPortletCache.java:84)
at org.apache.jetspeed.components.portletregistry.RegistryPortletCache.cache(RegistryPortletCache.java:75)
at org.apache.ojb.broker.cache.CacheDistributor$ObjectCacheInternalWrapper.cache(CacheDistributor.java:396)
at org.apache.ojb.broker.cache.CacheDistributor$ObjectCacheInternalWrapper.doInternalCache(CacheDistributor.java:381)
at org.apache.ojb.broker.cache.CacheDistributor.doInternalCache(CacheDistributor.java:147)
at org.apache.ojb.broker.cache.MaterializationCache.pushObjects(MaterializationCache.java:198)
at org.apache.ojb.broker.cache.MaterializationCache.disableMaterializationCache(MaterializationCache.java:93)
at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:178)
at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:251)
at org.apache.ojb.broker.core.QueryReferenceBroker.getCollectionByQuery(QueryReferenceBroker.java:271)
at org.apache.ojb.broker.core.PersistenceBrokerImpl.getCollectionByQuery(PersistenceBrokerImpl.java:1367)
at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:338)
at org.apache.ojb.broker.core.DelegatingPersistenceBroker.getCollectionByQuery(DelegatingPersistenceBroker.java:338)
at org.springframework.orm.ojb.PersistenceBrokerTemplate$3.doInPersistenceBroker(PersistenceBrokerTemplate.java:192)
at org.springframework.orm.ojb.PersistenceBrokerTemplate.execute(PersistenceBrokerTemplate.java:138)
at org.springframework.orm.ojb.PersistenceBrokerTemplate.executeFind(PersistenceBrokerTemplate.java:159)
at org.springframework.orm.ojb.PersistenceBrokerTemplate.getCollectionByQuery(PersistenceBrokerTemplate.java:190)
at org.apache.jetspeed.components.portletregistry.PersistenceBrokerPortletRegistry.getAllPortletDefinitions(PersistenceBrokerPortletRegistry.java:108)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy21.getAllPortletDefinitions(Unknown Source)
at org.apache.jetspeed.components.portletregistry.TestRegistryCache.testCache(TestRegistryCache.java:93)
> Unattached portlet definitions left in DB after registry unit tests run
> -----------------------------------------------------------------------
>
> Key: JS2-1015
> URL: https://issues.apache.org/jira/browse/JS2-1015
> Project: Jetspeed 2
> Issue Type: Bug
> Components: Portlet Registry, Testing
> Affects Versions: 2.2.0
> Environment: J2 2.2 trunk
> JDK6/Linux/x86_64
> Reporter: Randy Watler
> Assignee: Randy Watler
>
> Portlet definition clone tests fail to properly clean up after cloned portlet definition is removed in unit tests. On the next unit test case invocation w/o clearing the database, queries for all portlet definitions fail when orphaned portlet definitions w/o a portlet applications are added to the registry cache and fail.
> Preliminary investigation indicates that the registry OM is not utilizing removal aware collections for persistent collections, but the test cases are trying to remove persistent members using operations on the transient collection implementations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Commented: (JS2-1015) Unattached portlet definitions left in
DB after registry unit tests run
Posted by "David Sean Taylor (JIRA)" <je...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/JS2-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710518#action_12710518 ]
David Sean Taylor commented on JS2-1015:
----------------------------------------
I am OK with the Page Manager patch. The registry patch has a lot of these:
CollectionUtils.createCollection();
which seem to be safe as well.
This modification, if I understand correctly, is necessary too for the clone api to function correctly?:
+ // create new portlet in source portlet application
+ PortletDefinition copy = source.getApplication().addPortlet(newPortletName);
- PortletDefinitionImpl copy = new PortletDefinitionImpl();
> Unattached portlet definitions left in DB after registry unit tests run
> -----------------------------------------------------------------------
>
> Key: JS2-1015
> URL: https://issues.apache.org/jira/browse/JS2-1015
> Project: Jetspeed 2
> Issue Type: Bug
> Components: Portlet Registry, Testing
> Affects Versions: 2.2.0
> Environment: J2 2.2 trunk
> JDK6/Linux/x86_64
> Reporter: Randy Watler
> Assignee: Randy Watler
> Fix For: 2.2.1
>
> Attachments: page-manager-ojb-collections.patch, registry-ojb-collections.patch
>
>
> Portlet definition clone tests fail to properly clean up after cloned portlet definition is removed in unit tests. On the next unit test case invocation w/o clearing the database, queries for all portlet definitions fail when orphaned portlet definitions w/o a portlet applications are added to the registry cache and fail.
> Preliminary investigation indicates that the registry OM is not utilizing removal aware collections for persistent collections, but the test cases are trying to remove persistent members using operations on the transient collection implementations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Updated: (JS2-1015) Unattached portlet definitions left in
DB after registry unit tests run
Posted by "Randy Watler (JIRA)" <je...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/JS2-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Randy Watler updated JS2-1015:
------------------------------
Fix Version/s: 2.2.1
> Unattached portlet definitions left in DB after registry unit tests run
> -----------------------------------------------------------------------
>
> Key: JS2-1015
> URL: https://issues.apache.org/jira/browse/JS2-1015
> Project: Jetspeed 2
> Issue Type: Bug
> Components: Portlet Registry, Testing
> Affects Versions: 2.2.0
> Environment: J2 2.2 trunk
> JDK6/Linux/x86_64
> Reporter: Randy Watler
> Assignee: Randy Watler
> Fix For: 2.2.1
>
>
> Portlet definition clone tests fail to properly clean up after cloned portlet definition is removed in unit tests. On the next unit test case invocation w/o clearing the database, queries for all portlet definitions fail when orphaned portlet definitions w/o a portlet applications are added to the registry cache and fail.
> Preliminary investigation indicates that the registry OM is not utilizing removal aware collections for persistent collections, but the test cases are trying to remove persistent members using operations on the transient collection implementations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
[jira] Resolved: (JS2-1015) Unattached portlet definitions left in
DB after registry unit tests run
Posted by "Randy Watler (JIRA)" <je...@portals.apache.org>.
[ https://issues.apache.org/jira/browse/JS2-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Randy Watler resolved JS2-1015.
-------------------------------
Resolution: Fixed
SVN commit: 785910
> Unattached portlet definitions left in DB after registry unit tests run
> -----------------------------------------------------------------------
>
> Key: JS2-1015
> URL: https://issues.apache.org/jira/browse/JS2-1015
> Project: Jetspeed 2
> Issue Type: Bug
> Components: Portlet Registry, Testing
> Affects Versions: 2.2.0
> Environment: J2 2.2 trunk
> JDK6/Linux/x86_64
> Reporter: Randy Watler
> Assignee: Randy Watler
> Fix For: 2.2.1
>
> Attachments: page-manager-ojb-collections.patch, registry-ojb-collections.patch
>
>
> Portlet definition clone tests fail to properly clean up after cloned portlet definition is removed in unit tests. On the next unit test case invocation w/o clearing the database, queries for all portlet definitions fail when orphaned portlet definitions w/o a portlet applications are added to the registry cache and fail.
> Preliminary investigation indicates that the registry OM is not utilizing removal aware collections for persistent collections, but the test cases are trying to remove persistent members using operations on the transient collection implementations.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org