March 2012 - jboss-jira - Jboss List Archives

[JBoss JIRA] (AS7-3898) Improve the processing time of a request with a large number of parameters on JBossAS7.1.

by Toshio Oya (JIRA)

Toshio Oya created AS7-3898: ------------------------------- Summary: Improve the processing time of a request with a large number of parameters on JBossAS7.1. Key: AS7-3898 URL: https://issues.jboss.org/browse/AS7-3898 Project: Application Server 7 Issue Type: Enhancement Components: Web Affects Versions: 7.1.0.Final Reporter: Toshio Oya Assignee: Remy Maucherat Attachments: modified-7.1.0.Final.zip JBAS-9472 which is reported as an enhancement request for JBossAS 5.1.0.GA, is reproduced on JBossAS 7.1.0.Final. So, we have created a patch for JBossAS 7.1.0.Final. We want to incorporate this patch in JBoss AS 7.x. Please see JBAS-9472. -- 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

12 years, 2 months

2
5
0 / 0

[JBoss JIRA] (JBRULES-3407) Error generating invokers using a declaration having a primitive type

by Mario Fusco (JIRA)

Mario Fusco created JBRULES-3407: ------------------------------------ Summary: Error generating invokers using a declaration having a primitive type Key: JBRULES-3407 URL: https://issues.jboss.org/browse/JBRULES-3407 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco When the value type of a declaration is primitive, the invokers created via mvel templating using that declaration cannot be compiled because they try to do an invalid cast from an Object to a primitive type, generating an error as it follows: java.lang.AssertionError: Unable to generate rule invoker. : [Accumulate: input=[AND [[Pattern: id=null; objectType=MyObj]] ]] org/drools/Rule_foo_3191b39fd6ce40eaac55301df07acc19AccumulateExpression0Invoker.java (19:754) : Cannot cast from Object to long -- 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

12 years, 2 months

1
1
0 / 0

[JBoss JIRA] (JBRULES-3408) excludeUninitializedPlanningEntity should support specific uninitialized planning variables too

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created JBRULES-3408: ----------------------------------------- Summary: excludeUninitializedPlanningEntity should support specific uninitialized planning variables too Key: JBRULES-3408 URL: https://issues.jboss.org/browse/JBRULES-3408 Project: Drools Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-planner Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet partial initialization (only 1 variable, not all of them) can be needed in some optimization algorithms. See section in the manual. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-4008) Don't enable remote access to JMX by default in domain mode

by Darran Lofthouse (JIRA)

Darran Lofthouse created AS7-4008: ------------------------------------- Summary: Don't enable remote access to JMX by default in domain mode Key: AS7-4008 URL: https://issues.jboss.org/browse/AS7-4008 Project: Application Server 7 Issue Type: Task Components: JMX Reporter: Darran Lofthouse Assignee: Darran Lofthouse Priority: Critical Fix For: 7.1.1.Final In domain mode this is exposed using the remoting subsystem connector which is the same connector as is secured by the application users not the management users so by default we should not enable remote JMX access over this connection. -- 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

12 years, 2 months

2
2
0 / 0

[JBoss JIRA] (AS7-4001) Bad reference to XSL transformation files in module jboss-as-testsuite-benchmark and jboss-as-testsuite-stress

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/AS7-4001?page=com.atlassian.jira.plugin.s... ] Ondrej Zizka updated AS7-4001: ------------------------------ Fix Version/s: 7.1.1.Final > Bad reference to XSL transformation files in module jboss-as-testsuite-benchmark and jboss-as-testsuite-stress > -------------------------------------------------------------------------------------------------------------- > > Key: AS7-4001 > URL: https://issues.jboss.org/browse/AS7-4001 > Project: Application Server 7 > Issue Type: Bug > Components: Test Suite > Affects Versions: 7.1.1.Final > Reporter: Pavel Janousek > Assignee: Ondrej Zizka > Priority: Critical > Fix For: 7.1.1.Final > > > Transformation procedure is invoked, but it seems like bad configuration path or not correctly done clean-up in previous step. I caught this problem via warning: > {code} > [INFO] --- xml-maven-plugin:1.0:transform (ts.config-as.ip) @ jboss-as-testsuite-stress --- > [WARNING] The directory /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/target/jbossas/standalone/configuration, which is a base directory of a ValidationSet or TransformationSet, does not exist. > [WARNING] No files found for transformation by stylesheet /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/../integration/src/test/xslt/changeIPAddresses.xsl > [WARNING] The directory /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/target/jbossas/standalone/configuration, which is a base directory of a ValidationSet or TransformationSet, does not exist. > [WARNING] No files found for transformation by stylesheet /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/../integration/src/test/xslt/addJmsDestinations.xsl > {code} > Further investigation says /build/target/... isn't copied to these modules at all. > You can see this problem [there|https://hudson.qa.jboss.com/hudson/job/AS7-TS-linux-ipv6-experiment...]. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-4001) Bad reference to XSL transformation files in module jboss-as-testsuite-benchmark and jboss-as-testsuite-stress

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/AS7-4001?page=com.atlassian.jira.plugin.s... ] Ondrej Zizka resolved AS7-4001. ------------------------------- Resolution: Duplicate Issue JBPAPP-8312 > Bad reference to XSL transformation files in module jboss-as-testsuite-benchmark and jboss-as-testsuite-stress > -------------------------------------------------------------------------------------------------------------- > > Key: AS7-4001 > URL: https://issues.jboss.org/browse/AS7-4001 > Project: Application Server 7 > Issue Type: Bug > Components: Test Suite > Affects Versions: 7.1.1.Final > Reporter: Pavel Janousek > Assignee: Ondrej Zizka > Priority: Critical > > Transformation procedure is invoked, but it seems like bad configuration path or not correctly done clean-up in previous step. I caught this problem via warning: > {code} > [INFO] --- xml-maven-plugin:1.0:transform (ts.config-as.ip) @ jboss-as-testsuite-stress --- > [WARNING] The directory /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/target/jbossas/standalone/configuration, which is a base directory of a ValidationSet or TransformationSet, does not exist. > [WARNING] No files found for transformation by stylesheet /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/../integration/src/test/xslt/changeIPAddresses.xsl > [WARNING] The directory /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/target/jbossas/standalone/configuration, which is a base directory of a ValidationSet or TransformationSet, does not exist. > [WARNING] No files found for transformation by stylesheet /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/../integration/src/test/xslt/addJmsDestinations.xsl > {code} > Further investigation says /build/target/... isn't copied to these modules at all. > You can see this problem [there|https://hudson.qa.jboss.com/hudson/job/AS7-TS-linux-ipv6-experiment...]. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-4001) Bad reference to XSL transformation files in module jboss-as-testsuite-benchmark and jboss-as-testsuite-stress

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/AS7-4001?page=com.atlassian.jira.plugin.s... ] Ondrej Zizka updated AS7-4001: ------------------------------ Priority: Critical (was: Blocker) > Bad reference to XSL transformation files in module jboss-as-testsuite-benchmark and jboss-as-testsuite-stress > -------------------------------------------------------------------------------------------------------------- > > Key: AS7-4001 > URL: https://issues.jboss.org/browse/AS7-4001 > Project: Application Server 7 > Issue Type: Bug > Components: Test Suite > Affects Versions: 7.1.1.Final > Reporter: Pavel Janousek > Assignee: Ondrej Zizka > Priority: Critical > > Transformation procedure is invoked, but it seems like bad configuration path or not correctly done clean-up in previous step. I caught this problem via warning: > {code} > [INFO] --- xml-maven-plugin:1.0:transform (ts.config-as.ip) @ jboss-as-testsuite-stress --- > [WARNING] The directory /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/target/jbossas/standalone/configuration, which is a base directory of a ValidationSet or TransformationSet, does not exist. > [WARNING] No files found for transformation by stylesheet /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/../integration/src/test/xslt/changeIPAddresses.xsl > [WARNING] The directory /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/target/jbossas/standalone/configuration, which is a base directory of a ValidationSet or TransformationSet, does not exist. > [WARNING] No files found for transformation by stylesheet /mnt/hudson_workspace/workspace/AS7-TS-linux-ipv6-experiments/testsuite/stress/../integration/src/test/xslt/addJmsDestinations.xsl > {code} > Further investigation says /build/target/... isn't copied to these modules at all. > You can see this problem [there|https://hudson.qa.jboss.com/hudson/job/AS7-TS-linux-ipv6-experiment...]. -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-4011) TS: Bad approach used as fallback mechanism for gathering IP address

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/AS7-4011?page=com.atlassian.jira.plugin.s... ] Ondrej Zizka commented on AS7-4011: ----------------------------------- Stuart: {quote} The fallbacks are there for cases when no other stack is specified. As of today the test suite should honour all setting specified by the node0 and node1 addresses. If you are running under another network stack and have configured the build properly then these fallbacks should never be hit, they will only be used in the normal mvn install case with not other addresses set. To be honest this sort of fallback should probably be implemented in the pom, so that the system properties are always defined. Feel free to volunteer to fix it. {quote} > TS: Bad approach used as fallback mechanism for gathering IP address > -------------------------------------------------------------------- > > Key: AS7-4011 > URL: https://issues.jboss.org/browse/AS7-4011 > Project: Application Server 7 > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 7.1.1.Final > Reporter: Pavel Janousek > Assignee: Ondrej Zizka > Priority: Minor > > There are several places in TS where we can see similar code like this: > {code} > static final String someIPproperty = System.getProperty("<some key>", "localhost"); > {code} > or > {code} > static final String someIPproperty = System.getProperty("<some key>", "127.0.0.1"); > {code} > As you can see above, this fallback mechanism is bound in this case (key value isn't found) to IPv4 only IP address at all. This approach is bad because we can run in other network stack - IPv6 is presented in these days - and in this case the such testcase fails with some strange error due to this issue. > I think we have two option how to resolve this issue: > # Don't use fallback mechanism at all and fix (= remove) them in present testcases > # Create auxiliary class which return 127.0.0.1 or ::1 string (but not string "localhost" because we can't be sure how it is translated (*)) > (*) common setup in Linux is to translate localhost -> 127.0.0.1 and localhost6 -> ::1 > Ad 1) I prefer this option because some forget/miss setting is very easy to catch > Ad 2) This auxiliary class should need to make some magic decision in which IP network stack mode we are now running and return IPv4 or IPv6 lookpack address accordingly. > I've been asking for decision in jboss-as7-dev mailing list [[1|http://lists.jboss.org/pipermail/jboss-as7-dev/2012-March/005449.html]] and we should wait for feedback from developers for final decision how to fix this issue. > [1] http://lists.jboss.org/pipermail/jboss-as7-dev/2012-March/005449.html -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-4011) TS: Bad approach used as fallback mechanism for gathering IP address

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/AS7-4011?page=com.atlassian.jira.plugin.s... ] Ondrej Zizka commented on AS7-4011: ----------------------------------- Kabir: {quote} > Ad 1) I prefer this option because some forget/miss setting is very easy to catch I don't like this one - having to remember to set all the addresses while developing will be annoying :-) {quote} > TS: Bad approach used as fallback mechanism for gathering IP address > -------------------------------------------------------------------- > > Key: AS7-4011 > URL: https://issues.jboss.org/browse/AS7-4011 > Project: Application Server 7 > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 7.1.1.Final > Reporter: Pavel Janousek > Assignee: Ondrej Zizka > Priority: Minor > > There are several places in TS where we can see similar code like this: > {code} > static final String someIPproperty = System.getProperty("<some key>", "localhost"); > {code} > or > {code} > static final String someIPproperty = System.getProperty("<some key>", "127.0.0.1"); > {code} > As you can see above, this fallback mechanism is bound in this case (key value isn't found) to IPv4 only IP address at all. This approach is bad because we can run in other network stack - IPv6 is presented in these days - and in this case the such testcase fails with some strange error due to this issue. > I think we have two option how to resolve this issue: > # Don't use fallback mechanism at all and fix (= remove) them in present testcases > # Create auxiliary class which return 127.0.0.1 or ::1 string (but not string "localhost" because we can't be sure how it is translated (*)) > (*) common setup in Linux is to translate localhost -> 127.0.0.1 and localhost6 -> ::1 > Ad 1) I prefer this option because some forget/miss setting is very easy to catch > Ad 2) This auxiliary class should need to make some magic decision in which IP network stack mode we are now running and return IPv4 or IPv6 lookpack address accordingly. > I've been asking for decision in jboss-as7-dev mailing list [[1|http://lists.jboss.org/pipermail/jboss-as7-dev/2012-March/005449.html]] and we should wait for feedback from developers for final decision how to fix this issue. > [1] http://lists.jboss.org/pipermail/jboss-as7-dev/2012-March/005449.html -- 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

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (AS7-4011) TS: Bad approach used as fallback mechanism for gathering IP address

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/AS7-4011?page=com.atlassian.jira.plugin.s... ] Ondrej Zizka updated AS7-4011: ------------------------------ Issue Type: Feature Request (was: Bug) Priority: Minor (was: Blocker) > TS: Bad approach used as fallback mechanism for gathering IP address > -------------------------------------------------------------------- > > Key: AS7-4011 > URL: https://issues.jboss.org/browse/AS7-4011 > Project: Application Server 7 > Issue Type: Feature Request > Components: Test Suite > Affects Versions: 7.1.1.Final > Reporter: Pavel Janousek > Assignee: Ondrej Zizka > Priority: Minor > > There are several places in TS where we can see similar code like this: > {code} > static final String someIPproperty = System.getProperty("<some key>", "localhost"); > {code} > or > {code} > static final String someIPproperty = System.getProperty("<some key>", "127.0.0.1"); > {code} > As you can see above, this fallback mechanism is bound in this case (key value isn't found) to IPv4 only IP address at all. This approach is bad because we can run in other network stack - IPv6 is presented in these days - and in this case the such testcase fails with some strange error due to this issue. > I think we have two option how to resolve this issue: > # Don't use fallback mechanism at all and fix (= remove) them in present testcases > # Create auxiliary class which return 127.0.0.1 or ::1 string (but not string "localhost" because we can't be sure how it is translated (*)) > (*) common setup in Linux is to translate localhost -> 127.0.0.1 and localhost6 -> ::1 > Ad 1) I prefer this option because some forget/miss setting is very easy to catch > Ad 2) This auxiliary class should need to make some magic decision in which IP network stack mode we are now running and return IPv4 or IPv6 lookpack address accordingly. > I've been asking for decision in jboss-as7-dev mailing list [[1|http://lists.jboss.org/pipermail/jboss-as7-dev/2012-March/005449.html]] and we should wait for feedback from developers for final decision how to fix this issue. > [1] http://lists.jboss.org/pipermail/jboss-as7-dev/2012-March/005449.html -- 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

12 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2012