[JBoss JIRA] (SEAMFACES-234) UnsupportedOperationException when calling .size() in EL from a Composite Component
by Lincoln Baxter III (JIRA)
Lincoln Baxter III created SEAMFACES-234:
--------------------------------------------
Summary: UnsupportedOperationException when calling .size() in EL from a Composite Component
Key: SEAMFACES-234
URL: https://issues.jboss.org/browse/SEAMFACES-234
Project: Seam Faces
Issue Type: Bug
Affects Versions: 3.1.0.Final
Environment: JBoss AS 7.0.2.Final
Reporter: Lincoln Baxter III
I'm not exactly sure why this happens, but the following exception is thrown
{code}16:38:54,065 SEVERE [javax.enterprise.resource.webcontainer.jsf.application] (http--127.0.0.1-8080-5) Error Rendering View[/pages/home.xhtml
]: javax.faces.FacesException: java.lang.UnsupportedOperationException
at javax.faces.component.UIComponentBase$AttributesMap.get(UIComponentBase.java:2346) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at com.sun.faces.renderkit.RenderKitUtils.getImageSource(RenderKitUtils.java:1303) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
at com.sun.faces.renderkit.html_basic.ImageRenderer.encodeEnd(ImageRenderer.java:96) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
at javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:875) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:312) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.
3-SNAPSHOT]
at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:105) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHO
T]
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:304) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.
3-SNAPSHOT]
at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:105) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHO
T]
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1756) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at com.sun.faces.renderkit.html_basic.CompositeRenderer.encodeChildren(CompositeRenderer.java:78) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-
SNAPSHOT]
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1756) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at javax.faces.render.Renderer.encodeChildren(Renderer.java:168) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:304) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.
3-SNAPSHOT]
at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:105) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHO
T]
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:845) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1756) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1759) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1759) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:401) [jsf-impl-2.1.3-b02-jbossorg
-2.jar:2.1.3-SNAPSHOT]
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:131) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:288) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at com.ocpsoft.rewrite.faces.RewriteViewHandler.renderView(RewriteViewHandler.java:151) [rewrite-integration-faces-1.0.0-SNAPSHOT.jar:]
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:288) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:121) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at com.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:175) [rewrite-servlet-1.0.0-SNAPSHOT.jar:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at com.ocpsoft.socialpm.web.filter.ResponseTimeLoggingFilter.doFilter(ResponseTimeLoggingFilter.java:50) [classes:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:734) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:541) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:479) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:407) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at com.ocpsoft.rewrite.servlet.RewriteFilter.rewrite(RewriteFilter.java:226) [rewrite-servlet-1.0.0-SNAPSHOT.jar:]
at com.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:171) [rewrite-servlet-1.0.0-SNAPSHOT.jar:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at com.ocpsoft.socialpm.web.filter.ResponseTimeLoggingFilter.doFilter(ResponseTimeLoggingFilter.java:43) [classes:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at com.ocpsoft.socialpm.web.filter.TransactionFilter.doFilter(TransactionFilter.java:67) [classes:]
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:139) [jboss-as-web-7.0.2.Final.jar
:7.0.2.Final]
at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.2.Final.jar:7.0.2.Final]
at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:49) [jboss-as-jpa-7.0.2.Final.jar:7.0.2.Final]
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
Caused by: java.lang.UnsupportedOperationException
at com.sun.faces.el.CompositeComponentAttributesELResolver$ExpressionEvalMap.size(CompositeComponentAttributesELResolver.java:327) [jsf-imp
l-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
at org.jboss.seam.faces.el.CollectionsELResolver.resolveInMap(CollectionsELResolver.java:101) [seam-faces-3.1.0.Final.jar:]
at org.jboss.seam.faces.el.CollectionsELResolver.getValue(CollectionsELResolver.java:55) [seam-faces-3.1.0.Final.jar:]
at com.sun.faces.el.DemuxCompositeELResolver._getValue(DemuxCompositeELResolver.java:176) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT
]
at com.sun.faces.el.DemuxCompositeELResolver.getValue(DemuxCompositeELResolver.java:203) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
at org.apache.el.parser.AstValue.getValue(AstValue.java:134) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.el.parser.AstDotSuffix.getParameters(AstDotSuffix.java:44) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.el.parser.AstValue.getValue(AstValue.java:127) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.apache.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:187) [jbossweb-7.0.1.Final.jar:7.0.2.Final]
at org.jboss.weld.el.WeldValueExpression.getValue(WeldValueExpression.java:55) [weld-core-1.1.2.Final.jar:2011-07-26 15:02]
at com.sun.faces.facelets.el.ContextualCompositeValueExpression.getValue(ContextualCompositeValueExpression.java:156) [jsf-impl-2.1.3-b02-j
bossorg-2.jar:2.1.3-SNAPSHOT]
at com.sun.faces.facelets.el.TagValueExpression.getValue(TagValueExpression.java:109) [jsf-impl-2.1.3-b02-jbossorg-2.jar:2.1.3-SNAPSHOT]
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:194) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at javax.faces.component.ComponentStateHelper.eval(ComponentStateHelper.java:182) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at javax.faces.component.UIGraphic.getValue(UIGraphic.java:150) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_24]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_24]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_24]
at java.lang.reflect.Method.invoke(Method.java:597) [:1.6.0_24]
at javax.faces.component.UIComponentBase$AttributesMap.get(UIComponentBase.java:2338) [jboss-jsf-api_2.1_spec-2.0.0.Beta1.jar:2.0.0.Beta1]
... 65 more{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (SOLDER-315) Seam catch eats all exceptions silently
by Mike Mosiewicz (Created) (JIRA)
Seam catch eats all exceptions silently
---------------------------------------
Key: SOLDER-315
URL: https://issues.jboss.org/browse/SOLDER-315
Project: Solder
Issue Type: Bug
Components: Exception Handling
Affects Versions: 3.1.0.CR1
Environment: ANY
Reporter: Mike Mosiewicz
I observed that seam catch eats all exceptions silently. Specifically it make my development stop for a few hours becouse we didn't know there was model update exception. Here is what I investigated:
1. Every exception in CatchExceptionFilter appear to be handled (ie. catchEvent.isHandled() returned always true)
2. It was becouse it is marked handled in ExceptionHandlerDispatch.executeHandlers switch statement. I.e. here:
...
switch (breadthFirstEvent.getFlow()) {
case HANDLED:
eventException.setHandled(true);
return;
case MARK_HANDLED:
eventException.setHandled(true); <<<<<<<<<<<<<<<<<<
....
3. breadthFirstEvent.getFlow() is MARK_HANDLED becouse it's the default value.
The result is that it's enough there is a matching exception handler to mark the caught exception as handled and stop any exception display. And it's highly probable that you have seam-transaction in your library, so you have org.jboss.seam.transaction.SimpleTransactionExceptionHandler.markTransactionRollback handler active. That handler is intended to mark all the exceptional transactions to roll back. However it is irrelevant for this handler what kind of exception it handles. I wouldn't say that it actually handles exceptions. It just wants to know of all the exception that may cause transaction to be invalid and to rollback the transaction. But it definitely should be no mean to stop further processing of exception and it was probably not intended to hide exceptions.
I think there should be (at least) two kind of handlers. Those that just listen to exceptions and do some actions but they are not supposed to be a final destination for exceptions. These could be transaction related handlers, logging handlers, etc. And there should also be handlers that are able to deal with specific exceptions ultimately.
Right now there is a notion that exception is handled if there is a handler for the exception. If so - SimpleTransactionExceptionHandler should not be a handler.
I think it would be better if MARK_HANDLED was renamed to UNHANDLED and wouldn't cause eventException.setHandled(true). I would then use some annotation to add to those handler that are ultimate and definite, or set handled property programatically. The whole difference between HANDLED and MARK_HANDLED states is artificial. It feels like there should be a difference when some handler says that it really handled the situation or did not.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (SEAMSECURITY-142) Support JPA identity store user and group config separately (without requiring a common identity type table)
by Karsten Wutzke (JIRA)
Karsten Wutzke created SEAMSECURITY-142:
-------------------------------------------
Summary: Support JPA identity store user and group config separately (without requiring a common identity type table)
Key: SEAMSECURITY-142
URL: https://issues.jboss.org/browse/SEAMSECURITY-142
Project: Seam Security
Issue Type: Feature Request
Reporter: Karsten Wutzke
Priority: Blocker
Currently the JpaIdentityStore has a common configuration for Users and Groups. However, there are some problems with this:
Seam 3 Security requires a common entity for users and groups, which doesn't generally make sense. In some DBs users and groups have been split up into separate tables, which makes Seam 3 Security kind of intrusive to the data model, which might not be changable at all.
It would be very useful to be able to configure the users and groups table independently/separately, e.g. via an option
{code}
<plidm:JpaIdentityStoreConfiguration>
<plidm:userClass>com.company.project.model.???</plidm:userClass>
<plidm:groupClass>com.company.project.model.???</plidm:groupClass>
...
{code}
This is a blocker for most of my webapps, because I often cannot change the data model.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (SEAMFACES-235) EAR deployment failed on JBoss 6.1
by Jarek Gilewski (JIRA)
Jarek Gilewski created SEAMFACES-235:
----------------------------------------
Summary: EAR deployment failed on JBoss 6.1
Key: SEAMFACES-235
URL: https://issues.jboss.org/browse/SEAMFACES-235
Project: Seam Faces
Issue Type: Bug
Affects Versions: 3.1.0.Final
Environment: JBoss 6.1, Seam 3.1.Final
Reporter: Jarek Gilewski
Deploying simple Seam 3.1.Finall application on JBoss 6.1 give us exception:
20:53:12,544 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Start: name=vfs://
/D:/sdk/jboss-6.1.0.Final/server/default/deploy/sandbox-ear.ear_WeldBootstrapBean state=Create: org.jboss.weld.exception
s.DeploymentException: WELD-001408 Unsatisfied dependencies for type [FormValidationTypeOverrideExtension] with qualifie
rs [@Default] at injection point [[field] @Inject private org.jboss.seam.faces.util.BeanManagerUtils.classExtension]
at org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:270) [:6.1.0.Final]
at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:106) [:6.1.0.Final]
at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:129) [:6.1.0.Final]
at org.jboss.weld.bootstrap.Validator.validateBeans(Validator.java:351) [:6.1.0.Final]
at org.jboss.weld.bootstrap.Validator.validateDeployment(Validator.java:336) [:6.1.0.Final]
at org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:404) [:6.1.0.Final]
at org.jboss.weld.integration.deployer.env.helpers.BootstrapBean.boot(BootstrapBean.java:92) [:6.1.0.Final]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_29]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [:1.6.0_29]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [:1.6.0_29]
The Issue is well describe on the [Seam 3 Forum|http://www.seamframework.org/Community/Seam3InEAR]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] (JBSEAM-4854) countQuery not correcly generated when group by is used
by Serkan Eskici (Created) (JIRA)
countQuery not correcly generated when group by is used
-------------------------------------------------------
Key: JBSEAM-4854
URL: https://issues.jboss.org/browse/JBSEAM-4854
Project: Seam 2
Issue Type: Bug
Components: Framework
Affects Versions: 2.3.0.ALPHA
Reporter: Serkan Eskici
When an EntityQuery contains a group-by, then the select statement of the count-query is not correctly generated.
Example query for reproducing the problem:
select min(e.receivedDate), count(*)
from Entity e
where ...
groupby date_trunc('year', e.receivedDate), date_trunc('quarter', e.receivedDate)
The count-query becomes as follows (which generates an exception when run):
select distinct date_trunc('year', l.receivedDate), date_trunc('quarter', e.receivedDate)
from etc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months
[JBoss JIRA] Created: (SEAM-89) Call to associateGroups(head, branch) does not persist the group relationship
by Bill Elliot (JIRA)
Call to associateGroups(head, branch) does not persist the group relationship
-----------------------------------------------------------------------------
Key: SEAM-89
URL: https://issues.jboss.org/browse/SEAM-89
Project: Seam 3 Distribution
Issue Type: Bug
Affects Versions: 3.0.0.Final
Environment: Windows 7 x64, MySQL 5.1
Reporter: Bill Elliot
This is using MySQL 5.1 and it appears the association is not being persisted. If I manually enter the table row the association is detected correctly. But, the call to associateGroups is not persisting the relationship. I have used the following code to test out this:
package org.jboss.seam.security.examples.idmconsole.tests;
import javax.inject.Inject;
import org.picketlink.idm.api.Group;
import org.picketlink.idm.api.IdentitySession;
import org.picketlink.idm.api.PersistenceManager;
import org.picketlink.idm.api.RelationshipManager;
import org.picketlink.idm.common.exception.IdentityException;
public class TestSecurity {
@Inject IdentitySession identitySession;
public String testAction() throws IdentityException {
PersistenceManager pm = identitySession.getPersistenceManager();
RelationshipManager rm = identitySession.getRelationshipManager();
Group head = pm.findGroup("Head Office", "ORGANIZATION_UNIT");
Group branch = pm.findGroup("Branch Office", "ORGANIZATION_UNIT");
if( ! rm.isAssociated(head, branch) ) {
rm.associateGroups(head, branch);
}
boolean isAssociated = rm.isAssociated(head, branch);
return null;
}
}
The 2 groups in the test code exist in my test DB when I run the above code. I single step through the code to verify the situation after each line and everything is as expected, except that the call to rm.associateGroups(head, branch); does not persist the association.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 11 months