November 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (SECURITY-928) Redundant security-related XML schema files

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/SECURITY-928?page=com.atlassian.jira.plug... ] Peter Skopek commented on SECURITY-928: --------------------------------------- https://github.com/picketbox/picketbox/pull/54 > Redundant security-related XML schema files > ------------------------------------------- > > Key: SECURITY-928 > URL: https://issues.jboss.org/browse/SECURITY-928 > Project: PicketBox > Issue Type: Bug > Components: JBossSX > Reporter: Peter Skopek > Assignee: Peter Skopek > > There are several XML schemas in server's docs/schemas that are in my opinion redundant and should be removed: > picketbox-security-domain-configuration_4_0.xsd - duplicates subsystem configuration in jboss-as-security_1_2.xsd > security-config_*.xsd - 3 schemas for old deployable security configuration descriptor. These kinds of deployments are afaik not supported in EAP 7. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-928) Redundant security-related XML schema files

by Peter Skopek (JIRA)

Peter Skopek created SECURITY-928: ------------------------------------- Summary: Redundant security-related XML schema files Key: SECURITY-928 URL: https://issues.jboss.org/browse/SECURITY-928 Project: PicketBox Issue Type: Bug Components: JBossSX Reporter: Peter Skopek Assignee: Peter Skopek There are several XML schemas in server's docs/schemas that are in my opinion redundant and should be removed: picketbox-security-domain-configuration_4_0.xsd - duplicates subsystem configuration in jboss-as-security_1_2.xsd security-config_*.xsd - 3 schemas for old deployable security configuration descriptor. These kinds of deployments are afaik not supported in EAP 7. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5667) [Migration operation] Provide warning that HornetQ connector/acceptor parameters can not be migrated to the new messaging-subsystem

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-5667?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-5667: ------------------------------ Description: The parameters used by remote/http connector/acceptors in HornetQ might not be supported by Artemis. During migration, the operation should check if the parameters to migrate are allowed by the Artemis resources. If that's not the case, they will be removed from the migrated resources and warnings will be added to the :migrate operation outcome. was: Based on information in JBEAP-1652 - OIO connectors/acceptors are always migrated as NIO connector/acceptor. We should provide warning during migration that this is happening. > [Migration operation] Provide warning that HornetQ connector/acceptor parameters can not be migrated to the new messaging-subsystem > ----------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5667 > URL: https://issues.jboss.org/browse/WFLY-5667 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.CR4 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > The parameters used by remote/http connector/acceptors in HornetQ might not be supported by Artemis. > During migration, the operation should check if the parameters to migrate are allowed by the Artemis resources. > If that's not the case, they will be removed from the migrated resources and warnings will be added to the :migrate operation outcome. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-980) KieBase.getFactType should only be used to retrieve declared beans.

by Alejo Jara (JIRA)

Alejo Jara created DROOLS-980: --------------------------------- Summary: KieBase.getFactType should only be used to retrieve declared beans. Key: DROOLS-980 URL: https://issues.jboss.org/browse/DROOLS-980 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.3.0.Final Reporter: Alejo Jara Assignee: Mario Fusco Attachments: my_rules-1.jar Error inesperado en la ejecucion del artefacto java.lang.UnsupportedOperationException: KieBase.getFactType should only be used to retrieve declared beans. Class com.example.types.Person exists outside DRL at org.drools.core.definitions.impl.KnowledgePackageImpl.getFactType(KnowledgePackageImpl.java:635) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5667) [Migration operation] Provide warning that HornetQ connector/acceptor parameters can not be migrated to the new messaging-subsystem

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-5667?page=com.atlassian.jira.plugin.... ] Jeff Mesnil moved JBEAP-1891 to WFLY-5667: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-5667 (was: JBEAP-1891) Workflow: GIT Pull Request workflow (was: CDW v1) Component/s: JMS (was: JMS) (was: Migration) Target Release: (was: 7.0.0.GA) Affects Version/s: 10.0.0.CR4 (was: 7.0.0.DR13 (Alpha)) > [Migration operation] Provide warning that HornetQ connector/acceptor parameters can not be migrated to the new messaging-subsystem > ----------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5667 > URL: https://issues.jboss.org/browse/WFLY-5667 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.CR4 > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > > Based on information in JBEAP-1652 - OIO connectors/acceptors are always migrated as NIO connector/acceptor. > We should provide warning during migration that this is happening. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5668) wildfly-singleton_1_0.xsd has the wrong cardinality for singleton-policy

by Kabir Khan (JIRA)

[ https://issues.jboss.org/browse/WFLY-5668?page=com.atlassian.jira.plugin.... ] Kabir Khan moved JBEAP-1889 to WFLY-5668: ----------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-5668 (was: JBEAP-1889) Workflow: GIT Pull Request workflow (was: CDW v1) Component/s: Clustering (was: Clustering) Target Release: (was: 7.0.0.GA) > wildfly-singleton_1_0.xsd has the wrong cardinality for singleton-policy > ------------------------------------------------------------------------ > > Key: WFLY-5668 > URL: https://issues.jboss.org/browse/WFLY-5668 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Kabir Khan > Assignee: Paul Ferraro > > Noticed while working on https://issues.jboss.org/browse/WFLY-5658, the fix is: > {code} > diff --git a/clustering/singleton/extension/src/main/resources/schema/wildfly-singleton_1_0.xsd b/clustering/singleton/extension/src/main/resources/schema/wildfly-singleton_1_0.xsd > index b591c6c..1b02079 100644 > --- a/clustering/singleton/extension/src/main/resources/schema/wildfly-singleton_1_0.xsd > +++ b/clustering/singleton/extension/src/main/resources/schema/wildfly-singleton_1_0.xsd > @@ -20,7 +20,7 @@ > > <xs:complexType name="singleton-policies"> > <xs:sequence> > - <xs:element name="singleton-policy" type="tns:singleton-policy"> > + <xs:element name="singleton-policy" type="tns:singleton-policy" maxOccurs="unbounded"> > <xs:annotation> > <xs:documentation>Defines a singleton policy</xs:documentation> > </xs:annotation> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-979) the cache fact affect execution result

by Kevin Xu (JIRA)

Kevin Xu created DROOLS-979: ------------------------------- Summary: the cache fact affect execution result Key: DROOLS-979 URL: https://issues.jboss.org/browse/DROOLS-979 Project: Drools Issue Type: Bug Components: kie server Affects Versions: 6.3.0.Final Environment: TOMCAT 7 kie server 6.3 Reporter: Kevin Xu Assignee: Edson Tirelli i use the demo data to run the code,the demo data is :demo / uf-playground / mortgages/; there is a Underage.rdrl rule,the code is below: package org.mortgages; import org.mortgages.LoanApplication; import org.mortgages.Applicant; rule "Underage" salience 10 dialect "mvel" when application : LoanApplication( ) Applicant( age < "21" ) then application.setApproved( false ); application.setExplanation( "Underage" ); retract( application ); end and i use java client to insert fact and execute the rules the first time ,i set age is 18,then the return is: <result identifier="loanApplication3"> <org.mortgages.LoanApplication> <amount>131001</amount> <approved>false</approved> <deposit>2000</deposit> <explanation>Underage</explanation> <lengthYears>30</lengthYears> </org.mortgages.LoanApplication> </result> but when i modify the age to 30,the return is the same,the approved is {color:red}false {color}too,but the approved need to be true。 is when i restart the kie server ,then i execute the client code, the server will return the correct value : <approved>true</approved> why when i restart the kieserver ,and then i can get the correct result？ this is a bug or there is a api to control this? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1297) Verify if a SQLException is fatal in all methods

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1297?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1297: ------------------------------------------------ Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1271806|https://bugzilla.redhat.com/show_bug.cgi?id=1271806] from ON_QA to VERIFIED > Verify if a SQLException is fatal in all methods > ------------------------------------------------ > > Key: JBJCA-1297 > URL: https://issues.jboss.org/browse/JBJCA-1297 > Project: IronJacamar > Issue Type: Bug > Components: JDBC > Affects Versions: WildFly/IronJacamar 1.3.1.Final, 1.2.6.Final > Reporter: Jesper Pedersen > Assignee: Jesper Pedersen > Fix For: WildFly/IronJacamar 1.3.2.Final, 1.2.7.Final > > > WrappedConnection: > * setTransactionIsolation > * commit > * rollback > * setClientInfo -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1276) Prefill race condition in flush

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1276?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1276: ------------------------------------------------ Jan Martiska <jmartisk(a)redhat.com> changed the Status of [bug 1231658|https://bugzilla.redhat.com/show_bug.cgi?id=1231658] from ON_QA to VERIFIED > Prefill race condition in flush > ------------------------------- > > Key: JBJCA-1276 > URL: https://issues.jboss.org/browse/JBJCA-1276 > Project: IronJacamar > Issue Type: Bug > Affects Versions: 1.0.31.Final, 1.1.9.Final > Reporter: Takayoshi Kimura > Assignee: Jesper Pedersen > Fix For: 1.0.33.Final > > Attachments: server.log > > > There is a race condition between AbstractPool and SemaphoreArrayListManagedConnectionPool. > https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.0.31.Final/... > https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1.0.31.Final/... > AbstractPool flushes the mcp, mcp invokes PoolFiller which works in a separate thread. However AbstractPool is going to unregister the empty mcp and this mcp is no longer used. Then the dead mcp is prefilled in a separate thread by PoolFiller. > At next getConnection(), the mcp is re-initialized and prefilled. > I've attached logs, prefill enabled and min-size is 10. Boot server, invoke flush-all-connection-in-pool, getConnection() then killed. The prefill is done 3 times where it should be twice. > {noformat} > 16:26:04,254 DEBUG [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 1) ExampleDS: flush(true) > 16:26:04,255 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 1) Destroying flushed connection org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@1d298ed8[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@4ae26a1b connection handles=0 lastUse=1434353148384 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@56a43905 pool internal context=SemaphoreArrayListManagedConnectionPool@5cbd770e[pool=ExampleDS] xaResource=LocalXAResourceImpl@379ba3b3[connectionListener=1d298ed8 connectionManager=4b18594a warned=false currentXid=null productName=H2 productVersion=@PROJECT_VERSION@ (2012-07-13) jndiName=java:jboss/datasources/ExampleDS] txSync=null] > (repeat 10 times) > 16:02:20,666 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (management-handler-thread - 7) Shutdown - Pool: ExampleDS MCP: 2f5a2102 > 16:02:20,666 TRACE [org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory] (JCA PoolFiller) Using properties: {user=sa, password=--hidden--} > 16:02:20,666 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (management-handler-thread - 7) Unregister pool: SemaphoreArrayListManagedConnectionPool@2f5a2102[pool=ExampleDS] > 16:26:04,259 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (JCA PoolFiller) Filling pool cl=org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@34f0bb27[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@288f1898 connection handles=0 lastUse=1434353164259 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@56a43905 pool internal context=SemaphoreArrayListManagedConnectionPool@5cbd770e[pool=ExampleDS] xaResource=LocalXAResourceImpl@4a97b7f5[connectionListener=34f0bb27 connectionManager=4b18594a warned=false currentXid=null productName=H2 productVersion=@PROJECT_VERSION@ (2012-07-13) jndiName=java:jboss/datasources/ExampleDS] txSync=null] > (repeat 10 times) > 16:26:11,342 TRACE [org.jboss.jca.core.connectionmanager.TxConnectionManager] (http-/127.0.0.1:8080-1) getManagedConnection interleaving=false , tx=null > 16:26:11,343 DEBUG [org.jboss.jca.core.connectionmanager.pool.idle.IdleRemover] (http-/127.0.0.1:8080-1) Register pool: SemaphoreArrayListManagedConnectionPool@1d4ae61f[pool=ExampleDS] (interval=1800000) > 16:26:11,344 TRACE [org.jboss.jca.core.connectionmanager.pool.strategy.OnePool] (JCA PoolFiller) Filling pool cl=org.jboss.jca.core.connectionmanager.listener.TxConnectionListener@1c706b4d[state=NORMAL managed connection=org.jboss.jca.adapters.jdbc.local.LocalManagedConnection@18949ad1 connection handles=0 lastUse=1434353171343 trackByTx=false pool=org.jboss.jca.core.connectionmanager.pool.strategy.OnePool@56a43905 pool internal context=SemaphoreArrayListManagedConnectionPool@1d4ae61f[pool=ExampleDS] xaResource=LocalXAResourceImpl@44401bf2[connectionListener=1c706b4d connectionManager=4b18594a warned=false currentXid=null productName=H2 productVersion=@PROJECT_VERSION@ (2012-07-13) jndiName=java:jboss/datasources/ExampleDS] txSync=null] > (repeat 10 times) > {noformat} > In 1.0.31.Final: > > if (mcp.isEmpty()) > > clearMcpPools.add(mcp); > In 1.2 branch it looks like already fixed within commit 956af09c8494d4187db24a253e7e37b5ba5d9779 for JBJCA-1135: > > if (mcp.isEmpty() && !isPrefill() && size > 1) > > clearMcpPools.add(mcp); > We probably need to backport "!isPrefill()" to the 1.0/1.1 branch. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1120) Launcher sets "-Djava.net.preferIPv4Stack=true" also with IPv6 profile

by Marek Kopecký (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1120?page=com.atlassian.jira.plugi... ] Marek Kopecký commented on WFCORE-1120: --------------------------------------- [~jamezp]: Thank you for you fix, it seems to be useful for java.net.preferIPv4Stack property. But is your patch useful also for java memory properties like [-Xms64m or -Xmx512m|https://github.com/wildfly/wildfly-core/blob/master/launcher/src/main/java/org/wildfly/core/launcher/AbstractCommandBuilder.java#L48]? If arquillian.xml defines -Xms1024m, default value should be replaced. This allows memory tuning of java memory during TS runs, it could be useful on slower machines ... > Launcher sets "-Djava.net.preferIPv4Stack=true" also with IPv6 profile > ---------------------------------------------------------------------- > > Key: WFCORE-1120 > URL: https://issues.jboss.org/browse/WFCORE-1120 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Affects Versions: 2.0.1.Final > Reporter: Marek Kopecký > Assignee: James Perkins > > *Description of problem:* > Domain tests "-Djava.net.preferIPv4Stack=true" also with IPv6 profile. This property is set in AbstractCommandBuilder of WildFly-Core: > https://github.com/wildfly/wildfly-core/blob/master/launcher/src/main/jav... > There should be option for disable of this option in arquillian.xml file. And testsuite should use this option with IPv6 profile. > *How reproducible:* > Always > *Steps to Reproduce:* > # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIPV6_1 -Dnode1=$MYTESTIPV6_2 -Dipv6 -Dts.manualmode -Dtest=OutboundLdapConnectionTestCase -DtestLogToFile=false -Djboss.dist=$JBOSS_DIST -Dts.noSmoke > *Actual results:* > {noformat} > 07:04:26,054 INFO [org.jboss.as.arquillian.container.managed.ManagedDeployableContainer] (main) Starting container with: [/qa/tools/opt/jdk1.8.0_last/bin/java, > ... > -Djava.net.preferIPv4Stack=true, -Djava.net.preferIPv4Stack=false > ... > {noformat} > *Expected results:* > EAP is not started with "-Djava.net.preferIPv4Stack=true" property with IPv6 profile > *Additional info:* > Jenkins reproducer job: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-AS-T... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2015