October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1764) Add method to create a thrusted and unthrusted XStream instance on XStreamUtils

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1764?page=com.atlassian.jira.plugi... ] Geoffrey De Smet commented on DROOLS-1764: ------------------------------------------ Submitted an upstream PR on XStream: https://github.com/x-stream/xstream/pull/99 > Add method to create a thrusted and unthrusted XStream instance on XStreamUtils > ------------------------------------------------------------------------------- > > Key: DROOLS-1764 > URL: https://issues.jboss.org/browse/DROOLS-1764 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Geoffrey De Smet > Assignee: Geoffrey De Smet > Priority: Critical > > Each piece of code will need to figure out wether to use the thrusting or unthrusting xstream. > - thrusted: the xml is just like java code. It's basically executable. > - unthrusted: only whitelisted, select packages are allowed. There is no blacklist approach. Root packages are not being whitelisted. > Furthermore, *we want unthursted to allow all XStreamAliassed annotations automatically*, so it works like JAXB and Jackson. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6823) Doesn't work using non-ASCII chars for username and/or password for BASIC authentication.

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFLY-6823?page=com.atlassian.jira.plugin.... ] Jan Kalina edited comment on WFLY-6823 at 10/16/17 7:35 AM: ------------------------------------------------------------ Source for reference: https://github.com/undertow-io/undertow/blob/7a2a32d7d47ca584566b3f7d05a1... -Need to note, when passwords are stored in hashes on the server, there would have to be stored hash for every supported encoding.- -Just note, in Undertow (EAP) is this supported only by BASIC mechanism - not by DIGEST mechanism, so this would be new feature.- Edit: sorry, I have overlooked this is aimed to BASIC - for that one this is possible was (Author: honza889): Source for reference: https://github.com/undertow-io/undertow/blob/7a2a32d7d47ca584566b3f7d05a1... Need to note, when passwords are stored in hashes on the server, there would have to be stored hash for every supported encoding. Just note, in Undertow (EAP) is this supported only by BASIC mechanism - not by DIGEST mechanism, so this would be new feature. > Doesn't work using non-ASCII chars for username and/or password for BASIC authentication. > ----------------------------------------------------------------------------------------- > > Key: WFLY-6823 > URL: https://issues.jboss.org/browse/WFLY-6823 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > > Doesn't work using non-ASCII chars for username and/or password for BASIC authentication. > We noticed it when we looked on JIra issue https://issues.jboss.org/browse/JBEAP-3603. > We JBoss EAP 7 expects encoded UTF-8 strings in code. But we didn't find any information about it in specification. > It works with Chrome and Opera, but it doesn't work with Firefox. > Since there is no documentation for this username/password limitation it can affect customers who want to use non-ASCII credentials. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9439) Datasources are registered as singletons

by Michal Petrov (JIRA)

[ https://issues.jboss.org/browse/WFLY-9439?page=com.atlassian.jira.plugin.... ] Michal Petrov commented on WFLY-9439: ------------------------------------- Well, this makes datasources behave unlike other singletons, since more than one resource is allowed at a time. But if that's ok then the problem is in HAL. Still, are those statistics part of the {{resource-description}}? {{data-source=*:read-resource-description}} returns a list of descriptions for every datasource which seems unnecessary. > Datasources are registered as singletons > ---------------------------------------- > > Key: WFLY-9439 > URL: https://issues.jboss.org/browse/WFLY-9439 > Project: WildFly > Issue Type: Bug > Components: JCA > Reporter: Michal Petrov > Assignee: Stefano Maestri > > {code} > /subsystem=datasources:read-children-types(include-singletons) > {code} > returns this > {code} > { > "outcome" => "success", > "result" => [ > "data-source", > "data-source=ExampleDS", > "jdbc-driver", > "xa-data-source" > ] > } > {code} > This happens for any (xa-)data-source, not just the default one. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBEE-180) Update all spec artifacts to be compatible with JDK9

by Tomaz Cerar (JIRA)

Tomaz Cerar created JBEE-180: -------------------------------- Summary: Update all spec artifacts to be compatible with JDK9 Key: JBEE-180 URL: https://issues.jboss.org/browse/JBEE-180 Project: JBoss JavaEE Spec APIs Issue Type: Task Reporter: Tomaz Cerar Assignee: Tomaz Cerar Currently JBMS fails to create automodule name out of our artifacts as we have version of the spec in the name of the jar. Elegant solution would be to add Automatic-Module-Name manifest entry to the artifacts. Biggest question is what name of the module should be. One of suggestions was that until we have offical EG guidline what module name for such spec jars should be, we could use "beta." prefix to note that this name wont be there to stay. But before we go on and do that, we should make sure that such jars work with jdk9 at all, as there is already known issue with JTA see http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-July/008779.html for more details. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBEE-178) el-api jigsaw auto module naming broken

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/JBEE-178?page=com.atlassian.jira.plugin.s... ] Tomaz Cerar reassigned JBEE-178: -------------------------------- Assignee: Tomaz Cerar (was: Scott Marlow) > el-api jigsaw auto module naming broken > --------------------------------------- > > Key: JBEE-178 > URL: https://issues.jboss.org/browse/JBEE-178 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-el-api > Reporter: Klemen Ferjancic > Assignee: Tomaz Cerar > > /usr/lib/jvm/java-9-openjdk-9.0.0.181-1.fc26.x86_64/bin/jar --file=jboss-el-api_3.0_spec-1.0.10.Final.jar --describe-module > Unable to derive module descriptor for: jboss-el-api_3.0_spec-1.0.10.Final.jar > jboss.el.api.3.0.spec: Invalid module name: '3' is not a Java identifier > Basically identical problem as https://github.com/jboss/jboss-transaction-api_spec/pull/5 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1764) Add method to create a thrusted and unthrusted XStream instance on XStreamUtils

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created DROOLS-1764: ---------------------------------------- Summary: Add method to create a thrusted and unthrusted XStream instance on XStreamUtils Key: DROOLS-1764 URL: https://issues.jboss.org/browse/DROOLS-1764 Project: Drools Issue Type: Enhancement Components: core engine Reporter: Geoffrey De Smet Assignee: Geoffrey De Smet Priority: Critical Each piece of code will need to figure out wether to use the thrusting or unthrusting xstream. - thrusted: the xml is just like java code. It's basically executable. - unthrusted: only whitelisted, select packages are allowed. There is no blacklist approach. Root packages are not being whitelisted. Furthermore, *we want unthursted to allow all XStreamAliassed annotations automatically*, so it works like JAXB and Jackson. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9443) Random deploy error with @Startup @Singleton EJB

by Martin Kouba (JIRA)

[ https://issues.jboss.org/browse/WFLY-9443?page=com.atlassian.jira.plugin.... ] Martin Kouba commented on WFLY-9443: ------------------------------------ Hi Juan, I think this is a packaging/class loading problem. {{wftest-ejb.jar}} is a top-level EJB jar but can be also found in {{wftest-vaadin.war/WEB-INF/lib}}. By default, the classes in war can access the classes belonging to ejb jars (see also [EAR Class Loading|https://docs.jboss.org/author/display/WFLY10/Class+Loading+in+Wil...]) and so when performing injection on {{ar.com.zir.wftest.ejb.config.InitialConfig}} the container does not know which {{ar.com.zir.wftest.ejb.services.MovimientoService}} should be used. I'm not sure about EJB but in CDI this is non-portable and often problematic: _"If a bean class is deployed in two different bean archives, non-portable behavior results. Portable applications must deploy each bean class in no more than one bean archive."_ (see also [12.1. Bean archives|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#bean_archive]) So I think you should either try to change the scope of {{wftest-ejb}} dependency in war pom.xml to {{provided}} or change the {{<ear-subdeployments-isolated>}} value to {{true}}. > Random deploy error with @Startup @Singleton EJB > ------------------------------------------------ > > Key: WFLY-9443 > URL: https://issues.jboss.org/browse/WFLY-9443 > Project: WildFly > Issue Type: Bug > Components: CDI / Weld, Class Loading, EJB > Affects Versions: 11.0.0.CR1 > Environment: Wildfly 11.0CR1 + Vaadin 8.1.4 > Tested on Debian 9.1 and Windows 10 > Reporter: Juan Martin Runge > Assignee: Martin Kouba > Labels: regression > Attachments: error.log, success.log, wftest-ear-0.1.0.ear.tar.gz, wftest.tar.gz > > > Simple EAR project with an EJB Module and a WAR Module. War uses Vaadin (think is not relevant but mention it anyway). On the EJB Module I have a @Singleton @Startup bean which has injected a@LocalBean @Stateless bean via @Inject annotation (tested with @EJB annotation with same results). The UI on the WAR side also calls this @LocalBean @Stateless bean. Randomly, when I deploy, redeploy or restart the server, the EAR refuses to deploy do java.lang.IllegalStateException because it cannot inject the @Stateless bean inside the @Startup bean. > Attached sample app, project, log with error and log with success. > If you check the success log, you will see the @Startup @Singleton bean gets instanciated twice.. Quite strange. > Also, this didnt happened with Wildfly 9 (same app deployed perfectly) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9410) Can't run mvn install against testsuite-shared module twice without an intervening clean

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFLY-9410?page=com.atlassian.jira.plugin.... ] Chao Wang commented on WFLY-9410: --------------------------------- How this was reproduced ? run twice {{mvn install}} from directory wildfly/testsuite/shared ? I have two {{BUILD SUCCESS}} as http://pastebin.test.redhat.com/524699 against current master branch. > Can't run mvn install against testsuite-shared module twice without an intervening clean > ---------------------------------------------------------------------------------------- > > Key: WFLY-9410 > URL: https://issues.jboss.org/browse/WFLY-9410 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Reporter: Brian Stansberry > > Trying to build testsuite/shared twice without a clean results in failure. Really annoying as a standard build of WildFly builds this module. > Failure is: > {code} > [ERROR] Failed to execute goal org.codehaus.mojo:keytool-maven-plugin:1.5:generateKeyPair (gen-server-keystore) on project wildfly-testsuite-shared: Failed executing '/bin/sh -c cd /Users/bstansberry/dev/wildfly/wildfly/testsuite/shared && /Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/../bin/keytool -genkeypair -v -keystore /Users/bstansberry/dev/wildfly/wildfly/testsuite/shared/target/shared-keystores/application.keystore -storepass '*****' -storetype JKS -alias server -dname 'cn=server, ou=organizationUnit, o=organizationName, c=countryCode' -keypass '*****' -validity 365 -keyalg RSA -keysize 2048' - exitcode 1 -> [Help 1] > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1759) Not able to load all the kieModule from classpath

by Chandresh Mishra (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1759?page=com.atlassian.jira.plugi... ] Chandresh Mishra commented on DROOLS-1759: ------------------------------------------ [~mfusco] Hi Mario, Sorry for the late reply. To reproduce the issue please clone the repo " https://github.com/chandresh87/Drools-Issue.git" Steps to reproduce: 1. Import common-rule project in eclipse as a Gradle project. 2. import root project in eclipse as a Gradle project. 3. clean build install common-rule project. 4. clean install build bootRun root project. *OR* run the testng test case for application\src\test\java\com\app\test\StressTesting.java 5. application\src\test\java\com\app\test\StressTesting.java will fail. 6. Please check the log at C:\Logs\drools_app-info 7. It will print only kiebase present in common-rule .It will not print the kiebase present in root\application-rules project. I hope this will help you to reproduce the issue. Please do let me know if you need any other help. > Not able to load all the kieModule from classpath > --------------------------------------------------- > > Key: DROOLS-1759 > URL: https://issues.jboss.org/browse/DROOLS-1759 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.4.0.Final > Reporter: Chandresh Mishra > Assignee: Mario Fusco > > Hi , > I am trying to load a rules from classpath in gradle project. > It is a multi module gradle project.It has following structure. > Application > Application-rule > root > Application has compile project(':application-rule') in build.gradle. > application-rule has external dependency on common-rules . > Now when I am trying to load KieContainer from classpath in Application project. It is loading only kiebase in common-rules.jar .It is not loading kiebase in kmodule.xml present in Application-rule. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2226) Add Protocol.setProperties(Map<String, String>) method to allow programmatic configuration of arbitrary properties

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/JGRP-2226?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated JGRP-2226: ------------------------------- Summary: Add Protocol.setProperties(Map<String, String>) method to allow programmatic configuration of arbitrary properties (was: Add Protocol.setProperties(Map<String, String> method to allow programmatic configuration of arbitrary properties) > Add Protocol.setProperties(Map<String, String>) method to allow programmatic configuration of arbitrary properties > ------------------------------------------------------------------------------------------------------------------ > > Key: JGRP-2226 > URL: https://issues.jboss.org/browse/JGRP-2226 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 4.0.7 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Fix For: 4.0.8 > > > Currently, arbitrary protocol properties can only be configured programmatically via the setValue(String, Object) method. This has the following limitations: > * If these are truly arbitrary properties, we don't necessarily know the types > * This method relies on field names, not @Property names > * This method does not support @Property methods > This new setProperties(Map<String, String>) should throw an IllegalArgumentException if any of the properties are invalid. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 9 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 October 2017