June 2014 - gatein-issues - Jboss List Archives

[JBoss JIRA] (GTNPORTAL-3511) BasicHttpFetcher doesn't support IPv6 addresses

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3511?page=com.atlassian.jira.pl... ] RH Bugzilla Integration updated GTNPORTAL-3511: ----------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1106595 > BasicHttpFetcher doesn't support IPv6 addresses > ----------------------------------------------- > > Key: GTNPORTAL-3511 > URL: https://issues.jboss.org/browse/GTNPORTAL-3511 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Shindig > Affects Versions: 3.8.2.Final > Reporter: Lucas Ponce > Assignee: Lucas Ponce > Fix For: 3.9.0.Final > > > BasicHttpFetcher.java cannot process IPv6 with format [::1]. > Some logic like this: > String[] hostparts = StringUtils.splitPreserveAllTokens(uri.getAuthority(),':'); > int port = -1; // default port > if (hostparts.length > 2) { > throw new GadgetException(GadgetException.Code.INVALID_USER_DATA, > "Bad host name in request: " + uri.getAuthority(), > HttpServletResponse.SC_BAD_REQUEST); > } > has to be updated to support IPv4 and IPv6 formats. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3510) Possible memory leaks, consistency issues and concurrency issues in ScriptGraph

by Peter Palaga (JIRA)

Peter Palaga created GTNPORTAL-3510: --------------------------------------- Summary: Possible memory leaks, consistency issues and concurrency issues in ScriptGraph Key: GTNPORTAL-3510 URL: https://issues.jboss.org/browse/GTNPORTAL-3510 Project: GateIn Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Peter Palaga Assignee: Peter Palaga h4. Problems in the Present State (1) Consitency: there are {{IllegalStateException}} s thrown when adding resources from a deployment. Those exceptions can be thrown in the middle of such an adding which can lead to an inconsistent state when resources from a particular deployment are partly there and partly not there in the {{ScriptGraph}}. (2) Consitency: The present resource removal code does not ensure that a removed resource is also removed from dependent resources, closures and load groups. There are also no tests checking that. (3) Possible leaks: closures and load groups are not cleaned upon resource removals which can lead to memory leaks. This is a consequence of (2). (4) Concurrency: add and remove operations manipulate directly with collection instances that can be read (e.g. via {{getResource()}}) concurrently from other threads. h4. Solution proposal \(i) Make {{ScriptGraph}} immutable and always create a new instance (using some kind of builder pattern) when adding or removing resources. This should solve problems (1) and (4). (ii) Improve the resource removal code to the effect that dependencies, closures and load groups are kept consistent upon removals. Add tests. This should solve problems (2) and (3). -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3505) WSRP Producers behind Load Balancers get wrong endpoint URL

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3505?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3505: ---------------------------------------------------- Honza Fnukal <hfnukal(a)redhat.com> changed the Status of [bug 1102733|https://bugzilla.redhat.com/show_bug.cgi?id=1102733] from MODIFIED to ON_QA > WSRP Producers behind Load Balancers get wrong endpoint URL > ----------------------------------------------------------- > > Key: GTNPORTAL-3505 > URL: https://issues.jboss.org/browse/GTNPORTAL-3505 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Juraci Paixão Kröhling > Assignee: Juraci Paixão Kröhling > > When the WSRP producers are behind a cluster, the address generated on the SOAP message is based on the node's address/port, and not the cluster's. BZ 880729 and BZ 1102733. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNWSRP-376) Different Portlet preference for remote portlets added on the same page

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNWSRP-376?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on GTNWSRP-376: ------------------------------------------------- Honza Fnukal <hfnukal(a)redhat.com> changed the Status of [bug 1094772|https://bugzilla.redhat.com/show_bug.cgi?id=1094772] from MODIFIED to ON_QA > Different Portlet preference for remote portlets added on the same page > ----------------------------------------------------------------------- > > Key: GTNWSRP-376 > URL: https://issues.jboss.org/browse/GTNWSRP-376 > Project: GateIn WSRP > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.2.11.Final > Environment: Tested with : > JBoss Portal Platform - 6.1.1 (GateIn Portal 3.6.5) and > GateIn-3.8.0.Beta01 > Reporter: Anurag Debnath > Assignee: Juraci Paixão Kröhling > Attachments: PortletPreferencesPortlet.war.zip > > > When two instances of the same remote portlet is added to the same page, changes made to the preferences of one portlet is picked up by the other portlet as well. > Ideally, portlets should get their own preference/s. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3475) NPE in LinkedList$ListItr.next when iterating over UIGroupMembershipSelect.getListMemberhip()

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3475?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3475: ---------------------------------------------------- Honza Fnukal <hfnukal(a)redhat.com> changed the Status of [bug 1096190|https://bugzilla.redhat.com/show_bug.cgi?id=1096190] from MODIFIED to ON_QA > NPE in LinkedList$ListItr.next when iterating over UIGroupMembershipSelect.getListMemberhip() > --------------------------------------------------------------------------------------------- > > Key: GTNPORTAL-3475 > URL: https://issues.jboss.org/browse/GTNPORTAL-3475 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Peter Palaga > Assignee: Peter Palaga > Fix For: 3.8.2.Final, 3.9.0.Final > > Attachments: GTNPORTAL-3475.log > > > Looks like a concurrent modification of the {{LinkedList}} refered to by {{UIGroupMembershipSelect.listMemberhip}}, because: > i. It is not always reproducible, the NPE occurs roughly once per 10 attempts. > ii. It happens on line {{next = next.next}} of the JRE's {{LinkedList.ListItr}} where it is hard to thing of anything else than concurrent modification as a cause. > Steps to reproduce: > (1) Start clean Portal instance for the first time > (2) Go to Application Registry > (3) Import Applications > Not OK: There is an NPE logged (the whole log is attached): > {code:none} > Caused by: java.lang.NullPointerException > at java.util.LinkedList$ListItr.next(LinkedList.java:891) [rt.jar:1.7.0_55] > at UIGroupMembershipSelector.run(UIGroupMembershipSelector.gtmpl:20) at org.exoplatform.groovyscript.GroovyScript.render(GroovyScript.java:99) [exo.portal.component.scripting-3.8.0.Beta02-SNAPSHOT.jar:3.8.0.Beta02-SNAPSHOT] > at org.exoplatform.groovyscript.GroovyTemplate.render(GroovyTemplate.java:115) [exo.portal.component.scripting-3.8.0.Beta02-SNAPSHOT.jar:3.8.0.Beta02-SNAPSHOT] > {code} > Expected: No NPE -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3497) Portlet in Dashboard is broken for the first access

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3497?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3497: ---------------------------------------------------- Honza Fnukal <hfnukal(a)redhat.com> changed the Status of [bug 1059036|https://bugzilla.redhat.com/show_bug.cgi?id=1059036] from MODIFIED to ON_QA > Portlet in Dashboard is broken for the first access > ---------------------------------------------------- > > Key: GTNPORTAL-3497 > URL: https://issues.jboss.org/browse/GTNPORTAL-3497 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Juraci Paixão Kröhling > Assignee: Juraci Paixão Kröhling > > From BZ 1059036: > If you configure a richfaces portlet in dashboard template, the portlet may break for the first access by a newly created user. > https://bugzilla.redhat.com/show_bug.cgi?id=1059036 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3484) Commit changes for a page before send response

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3484?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3484: ---------------------------------------------------- Honza Fnukal <hfnukal(a)redhat.com> changed the Status of [bug 1080249|https://bugzilla.redhat.com/show_bug.cgi?id=1080249] from MODIFIED to ON_QA > Commit changes for a page before send response > ---------------------------------------------- > > Key: GTNPORTAL-3484 > URL: https://issues.jboss.org/browse/GTNPORTAL-3484 > Project: GateIn Portal > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Lucas Ponce > Assignee: Lucas Ponce > Fix For: 3.8.2.Final, 3.9.0.Final > > > In current design a call to RequestLifeCycle.end() is performed at the end of the request meanwhile a markup can be send it before with portlets ID not yet commited. > This can cause some StaleModelException cases under heavy load or database congestion. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNMOP-54) Tests in WorkspaceTestCase are order dependent

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNMOP-54?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on GTNMOP-54: ----------------------------------------------- Honza Fnukal <hfnukal(a)redhat.com> changed the Status of [bug 1091114|https://bugzilla.redhat.com/show_bug.cgi?id=1091114] from MODIFIED to ON_QA > Tests in WorkspaceTestCase are order dependent > ---------------------------------------------- > > Key: GTNMOP-54 > URL: https://issues.jboss.org/browse/GTNMOP-54 > Project: GateIn Model Object for Portal > Issue Type: Bug > Reporter: Peter Palaga > Assignee: Peter Palaga > > Cloned from https://bugzilla.redhat.com/show_bug.cgi?id=1091114 > Description of problem: > Community MOP Core project (https://github.com/gatein/gatein-mop/tree/1.3.1.Final/core) has test dependency junit-4.10.jar (managed from gatein-dep-1.4.0.Final). > Prod MOP Core (http://git.app.eng.bos.redhat.com/git/gatein/gatein-mop.git/tree/core?id=...) has test dependency junit-4.11-redhat-1.jar. > There are junit 4.11 release notes: https://github.com/junit-team/junit/blob/master/doc/ReleaseNotes4.11.md#t... > Test execution order has changed between junit 4.10 and 4.11. I get test failures in org.gatein.mop.core.api.workspace.WorkspaceTestCase. It depends on order of execution of org.gatein.mop.core.api.workspace.WorkspaceTestCase.testRemoveReferencedTemplate. When the test is runned, all following tests, where a site "portal" is added (.addSite(ObjectType.PORTAL_SITE, "portal")), fails. In junit 4.10 the test is runned in the end of the test file so the tests passed but in 4.11 5 tests fails with ERROR org.chromattic.core.DomainSession - Attempt to insert context EntityContext[state=ObjectStatus[status=TRANSIENT],mapper=EntityMapper[class=class org.gatein.mop.core.api.workspace.PortalSite,typeName=mop:portalsite]] as an existing child with name mop:portal child of node /mop:workspace/mop:portalsites > Version-Release number of selected component (if applicable): > community MOP: 1.3.1.Final with junit 4.10 > prod MOP: 1.3.1.Final-redhat-1 with junit 4.11-redhat-1 > Additional info: > When I declare junit version to 4.11 in community project I get the errors. > When I declare junit version to 4.10-redhat-2 in prod project all tests passed. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNCOMMON-21) Serialization of ParameterMap breaks with JBoss Marshalling

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNCOMMON-21?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on GTNCOMMON-21: -------------------------------------------------- Honza Fnukal <hfnukal(a)redhat.com> changed the Status of [bug 1058216|https://bugzilla.redhat.com/show_bug.cgi?id=1058216] from MODIFIED to ON_QA > Serialization of ParameterMap breaks with JBoss Marshalling > ----------------------------------------------------------- > > Key: GTNCOMMON-21 > URL: https://issues.jboss.org/browse/GTNCOMMON-21 > Project: GateIn Common > Issue Type: Bug > Affects Versions: 2.1.1.Final > Environment: JPP 6.1.0 > Reporter: Martin Weiler > Fix For: 2.2.0.Beta01, 2.1.2.Final > > > Serialization of a ParameterMap instance with JBoss Marshalling (used by Infinispan) breaks with the following exception: > {noformat} > 15:20:33,853 ERROR [org.infinispan.marshall.VersionAwareMarshaller] (transport-thread-11) ISPN000065: Exception while marshalling object: java.io.NotActiveException: Fields were never written > at org.jboss.marshalling.river.RiverObjectOutputStream.finish(RiverObjectOutputStream.java:175) > at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1009) > at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885) > at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063) > at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019) > at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885) > at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(RiverMarshaller.java:1063) > at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializableObject(RiverMarshaller.java:1019) > at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:885) > at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:680) > at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:680) > at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62) > at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119) > at org.jboss.as.clustering.SimpleMarshalledValue.getBytes(SimpleMarshalledValue.java:85) > at org.jboss.as.clustering.SimpleMarshalledValue.writeExternal(SimpleMarshalledValue.java:175) > at org.jboss.as.clustering.infinispan.io.ExternalizableExternalizer.writeObject(ExternalizableExternalizer.java:47) > at org.jboss.as.clustering.infinispan.io.ExternalizableExternalizer.writeObject(ExternalizableExternalizer.java:36) > at org.infinispan.marshall.jboss.ExternalizerTable$ForeignExternalizerAdapter.writeObject(ExternalizerTable.java:459) > at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145) > at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62) > at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119) > at org.infinispan.marshall.MarshallUtil.marshallMap(MarshallUtil.java:59) > at org.infinispan.marshall.exts.MapExternalizer.writeObject(MapExternalizer.java:63) > at org.infinispan.marshall.exts.MapExternalizer.writeObject(MapExternalizer.java:47) > at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410) > at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145) > at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62) > at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119) > at org.infinispan.atomic.AtomicHashMap$Externalizer.writeObject(AtomicHashMap.java:250) > at org.infinispan.atomic.AtomicHashMap$Externalizer.writeObject(AtomicHashMap.java:247) > at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410) > at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145) > at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62) > at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119) > at org.infinispan.container.entries.ImmortalCacheEntry$Externalizer.writeObject(ImmortalCacheEntry.java:154) > at org.infinispan.container.entries.ImmortalCacheEntry$Externalizer.writeObject(ImmortalCacheEntry.java:150) > at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410) > at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145) > at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62) > at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119) > at org.infinispan.marshall.MarshallUtil.marshallCollection(MarshallUtil.java:48) > at org.infinispan.marshall.exts.ArrayListExternalizer.writeObject(ArrayListExternalizer.java:50) > at org.infinispan.marshall.exts.ArrayListExternalizer.writeObject(ArrayListExternalizer.java:45) > at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410) > at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145) > at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62) > at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119) > at org.infinispan.statetransfer.StateChunk$Externalizer.writeObject(StateChunk.java:103) > at org.infinispan.statetransfer.StateChunk$Externalizer.writeObject(StateChunk.java:88) > at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410) > at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145) > at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62) > at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119) > at org.infinispan.marshall.MarshallUtil.marshallCollection(MarshallUtil.java:48) > at org.infinispan.marshall.exts.ArrayListExternalizer.writeObject(ArrayListExternalizer.java:50) > at org.infinispan.marshall.exts.ArrayListExternalizer.writeObject(ArrayListExternalizer.java:45) > at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410) > at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145) > at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62) > at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119) > at org.infinispan.marshall.exts.ReplicableCommandExternalizer.writeCommandParameters(ReplicableCommandExternalizer.java:87) > at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.marshallParameters(CacheRpcCommandExternalizer.java:128) > at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.writeObject(CacheRpcCommandExternalizer.java:112) > at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.writeObject(CacheRpcCommandExternalizer.java:73) > at org.infinispan.marshall.jboss.ExternalizerTable$ExternalizerAdapter.writeObject(ExternalizerTable.java:410) > at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:145) > at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62) > at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119) > at org.infinispan.marshall.jboss.AbstractJBossMarshaller.objectToObjectStream(AbstractJBossMarshaller.java:96) > at org.infinispan.marshall.VersionAwareMarshaller.objectToBuffer(VersionAwareMarshaller.java:92) > at org.infinispan.marshall.AbstractMarshaller.objectToBuffer(AbstractMarshaller.java:64) > at org.infinispan.marshall.AbstractDelegatingMarshaller.objectToBuffer(AbstractDelegatingMarshaller.java:109) > at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectToBuffer(MarshallerAdapter.java:45) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:279) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:300) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:179) > at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:515) > at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:169) > at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:190) > at org.infinispan.statetransfer.OutboundTransferTask.sendEntries(OutboundTransferTask.java:257) > at org.infinispan.statetransfer.OutboundTransferTask.run(OutboundTransferTask.java:187) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51] > at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51] > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_51] > at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51] > Caused by: an exception which occurred: > in field parameters > in field navigationalState > in object java.util.HashMap@7b2c68fe > {noformat} > The NotActiveException is a result of a broken writeObject implementation in org.gatein.common.util.ParameterMap, which does not call out.defaultWriteObject(); -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (GTNPORTAL-3501) Introduce XML schema validation for gatein-resources.xml

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/GTNPORTAL-3501?page=com.atlassian.jira.pl... ] RH Bugzilla Integration commented on GTNPORTAL-3501: ---------------------------------------------------- Honza Fnukal <hfnukal(a)redhat.com> changed the Status of [bug 1103771|https://bugzilla.redhat.com/show_bug.cgi?id=1103771] from MODIFIED to ON_QA > Introduce XML schema validation for gatein-resources.xml > -------------------------------------------------------- > > Key: GTNPORTAL-3501 > URL: https://issues.jboss.org/browse/GTNPORTAL-3501 > Project: GateIn Portal > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Peter Palaga > Assignee: Peter Palaga > Fix For: 3.8.2.Final, 3.9.0.Final > > > There are several lines of code that indicate that {{org.exoplatform.commons.xml.XMLValidator}} was originally designed to check if a given document complies with an XML schema declared in it: > {code:java} > factory.setAttribute("http://java.sun.com/xml/jaxp/properties/schemaLanguage", "http://www.w3.org/2001/XMLSchema"); factory.setAttribute("http://java.sun.com/xml/jaxp/properties/schemaSource", schemas); > factory.setNamespaceAware(true); > factory.setValidating(true); > {code} > However, there were no tests checking if the validation works and indeed, it does not. It is out of the present scope to investigate what is wrong with {{XMLValidator}} and how it can be corrected, because it is too general to be used for validating {{gatein-resources.xml}} at this point. The main problem is that if we have not validated so far, there must be a lot of schema-incompatible {{gatein-resources.xml}} out there in the wild that were silently accepted by the portal in the past. Therefore, we cannot start validating all {{gatein-resources.xml}} files now. > To meet the natural expectation that inputs are properly validated to widest possible extent, I propose to start validating now, but only {{gatein-resources.xml}} documents that use the namespace {{http://www.gatein.org/xml/ns/gatein_resources_1_5}} or newer. {{gatein_resources_1_5.xsd}} will be introduced these days with fixing > GTNPORTAL-3485 and GTNPORTAL-3487. In this way we can stay backwards-compatible and start validating from now on. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

10 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

gatein-issues June 2014