September 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-531) KieServices.Factory.get().getKieClasspathContainer() doesn't discover KieModules in a non-Maven project

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-531?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-531: ------------------------------------------------ Ryan Zhang <rzhang(a)redhat.com> changed the Status of [bug 1117114|https://bugzilla.redhat.com/show_bug.cgi?id=1117114] from MODIFIED to ON_QA > KieServices.Factory.get().getKieClasspathContainer() doesn't discover KieModules in a non-Maven project > ------------------------------------------------------------------------------------------------------- > > Key: DROOLS-531 > URL: https://issues.jboss.org/browse/DROOLS-531 > Project: Drools > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 6.1.0.CR1 > Reporter: Michael Anstis > Assignee: Mario Fusco > Labels: backport-to-6.0.x > Fix For: 6.1.0.Final > > > If you try to use a ClassPath Container KieContainerImpl uses a ClasspathKieProject that scans the classpath for pom.xml or pom.properties files. If the consuming project is not a Maven project (and hence lacks either a pom.xml or pom.properties file) no KBases/KSessions defined in the consuming project's kmodule.xml and /resources folder are discovered. > This also manifests as a problem when running Maven WebApp projects in IDEA (other IDE's and project types may be similarly affected). IDEA copies the JARs sources and resources to the target folder at runtime; which excludes the module's pom.xml and pom.properties files. > Consequentially ClasspathKieProject fails to determine a ReleaseId for any KieModules defined in the module and hence fails to discover any KBases/KSessions too. > See https://github.com/ederign/uf-social-activities/blob/master/uberfire-soci... where we try to use a named KSession. > This is defined in https://github.com/ederign/uf-social-activities/blob/master/uberfire-soci... > Rules being in https://github.com/ederign/uf-social-activities/tree/master/uberfire-soci... > Workaround is to include a dummy pom.properties; as we did here https://github.com/ederign/uf-social-activities/blob/master/uberfire-soci... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1877) System.nanoTime() may be in the future

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1877?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1877: -------------------------------- You mean set the interrupt bit in the current thread again in the catch clause ? > System.nanoTime() may be in the future > -------------------------------------- > > Key: JGRP-1877 > URL: https://issues.jboss.org/browse/JGRP-1877 > Project: JGroups > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.1, 3.6 > > > According to the javadoc, {{System.nanoTime()}} should only be used to measure _elapsed time_, but not compute a _target time in the future_, as {{nanoTime()}} might return a a time in the future. > Code like the one below might fail: > {code:title=Responses.waitFor()|borderStyle=solid} > public boolean waitFor(long timeout) { > long wait_time; > final long target_time=System.nanoTime() + TimeUnit.NANOSECONDS.convert(timeout, TimeUnit.MILLISECONDS); // ns > lock.lock(); > try { > while(!done && (wait_time=target_time - System.nanoTime()) > 0) { > try { > cond.await(wait_time,TimeUnit.NANOSECONDS); > } > catch(InterruptedException e) { > } > } > return done; > } > finally { > lock.unlock(); > } > } > {code} > Investigate all occurrences where we use {{nanoTime()}} to compute a time in the future, and see what impact a future value value could have. Possibly replace with {{System.currentTimeMillis()}} or the _time service_. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated JGRP-1878: --------------------------------- Priority: Minor (was: Blocker) > Multicast discovery does not work on JDK8 > ----------------------------------------- > > Key: JGRP-1878 > URL: https://issues.jboss.org/browse/JGRP-1878 > Project: JGroups > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.2.12, 3.5 > Environment: OpenJDK8, OracleJDK8u40 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Minor > Fix For: 3.2.14, 3.6 > > Attachments: mcast.java > > > Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8. > Steps to reproduce with draw, switch to JDK8: > {noformat} > export IP_ADDR=127.0.0.1 > ./draw.sh > export IP_ADDR=192.168.1.10 > ./draw.sh > {noformat} > Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug.. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on JGRP-1878: -------------------------------------- I may have tracked down the JDK8 changes that are responsible for the behavior change we are observing: Issues: https://bugs.openjdk.java.net/browse/JDK-8014499 http://bugs.java.com/view_bug.do?bug_id=8014499 http://bugs.java.com/view_bug.do?bug_id=8014377 Commits http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/bf2bacf934d1 http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/rev/cd06fc069152 What this is esentially doing, they are now setting IP_MULTICAST_ALL=0 for DatagramChannels on Linux which is supported since kernel version 2.6.31 (http://man7.org/linux/man-pages/man7/ip.7.html). With JDK8 binding to different addresses on the same machine, the processes are not going to receive each other's messages. Some further reading: https://bugzilla.redhat.com/show_bug.cgi?id=231899 http://marc.info/?l=linux-netdev&m=121579002105636&w=2 > Multicast discovery does not work on JDK8 > ----------------------------------------- > > Key: JGRP-1878 > URL: https://issues.jboss.org/browse/JGRP-1878 > Project: JGroups > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 3.2.12, 3.5 > Environment: OpenJDK8, OracleJDK8u40 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Blocker > Fix For: 3.2.14, 3.6 > > Attachments: mcast.java > > > Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8. > Steps to reproduce with draw, switch to JDK8: > {noformat} > export IP_ADDR=127.0.0.1 > ./draw.sh > export IP_ADDR=192.168.1.10 > ./draw.sh > {noformat} > Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug.. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGMGR-106) Fix possible Level leak for OpenJDK

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-106?page=com.atlassian.jira.plugin... ] James Perkins commented on LOGMGR-106: -------------------------------------- Actual commit was different the original PR, https://github.com/jamezp/jboss-logmanager/commit/5290038a4a847543b5a9026... > Fix possible Level leak for OpenJDK > ----------------------------------- > > Key: LOGMGR-106 > URL: https://issues.jboss.org/browse/LOGMGR-106 > Project: JBoss Log Manager > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: James Perkins > Assignee: James Perkins > Fix For: 1.5.3.Final, 2.0.0.Beta1 > > > Currently {{org.jboss.logmanager.LogManager}} has a hack to get around the {{java.util.logging.Level}} storing levels in a static map. OpenJDK uses an inner-class to do the same thing. A hack is needed to also check the OpenJDK static level mapping. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-85) Remove non socket-binding attributes from management interfaces

by Tomaz Cerar (JIRA)

Tomaz Cerar created WFCORE-85: --------------------------------- Summary: Remove non socket-binding attributes from management interfaces Key: WFCORE-85 URL: https://issues.jboss.org/browse/WFCORE-85 Project: WildFly Core Issue Type: Task Components: Domain Management Reporter: Tomaz Cerar Assignee: Brian Stansberry Remove HttpManagementResourceDefinition#http-port, https-port, interface, secure-interface as this ware replaced by socket-binding and secure-socket-binding around 7.0 time frame. Given that it only adds complexity and no real added value they should be removed as disscussed. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-84) The /core-service=module-loading does not get initialised on the host controller

by Kabir Khan (JIRA)

Kabir Khan created WFCORE-84: -------------------------------- Summary: The /core-service=module-loading does not get initialised on the host controller Key: WFCORE-84 URL: https://issues.jboss.org/browse/WFCORE-84 Project: WildFly Core Issue Type: Feature Request Affects Versions: 1.0.0.Alpha5 Reporter: Kabir Khan Assignee: Kabir Khan Fix For: 1.0.0.Alpha6 HostResourceDefinition adds the resource definition, but HostModelRegistrationHandler does not add the placeholder resource as ServerService.initModel() does -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-82) Defining a HTTP management interface with secure-port or https socket binding but not security realm causes NullPointerException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-82?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFCORE-82: ----------------------------------------------- Darran Lofthouse <darran.lofthouse(a)redhat.com> changed the Status of [bug 908236|https://bugzilla.redhat.com/show_bug.cgi?id=908236] from ASSIGNED to POST > Defining a HTTP management interface with secure-port or https socket binding but not security realm causes NullPointerException > -------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-82 > URL: https://issues.jboss.org/browse/WFCORE-82 > Project: WildFly Core > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 1.0.0.Alpha5 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.0.0.Alpha6 > > > There are actually two checks that need to be performed: - > 1 - If a secure port is required then a security realm must be associated with the interface. > 2 - That security realm must supply an SSLContext > For #1 that can at least be validated in the model at the end of stage MODEL. This will need to be validated for both standalone mode and domain mode - each of these use independent resource definitions. > #2 will have to wait until RUNTIME where we have the opportunity to check that the injected realm does supply a SSLContext. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3814) Hostname in krb5.conf domain_realm section must not contain square brackets

by Josef Cacek (JIRA)

Josef Cacek created WFLY-3814: --------------------------------- Summary: Hostname in krb5.conf domain_realm section must not contain square brackets Key: WFLY-3814 URL: https://issues.jboss.org/browse/WFLY-3814 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Josef Cacek Assignee: Josef Cacek The SAML2AttributeMappingTestCase in testsuite/integration/basic uses a wrong hostname value in the generated krb5.conf file in case of IPv6 address. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-3660) allow easy creation of executable war

by jieryn jieryn (JIRA)

[ https://issues.jboss.org/browse/WFLY-3660?page=com.atlassian.jira.plugin.... ] jieryn jieryn commented on WFLY-3660: ------------------------------------- Awesome! I think that the final artifact produced ought to be completely contained however. I'd rather the builder of the executable war download everything and produce a fat application at build time rather than assume an external network connection is available to the environment which is running the application. > allow easy creation of executable war > ------------------------------------- > > Key: WFLY-3660 > URL: https://issues.jboss.org/browse/WFLY-3660 > Project: WildFly > Issue Type: Feature Request > Components: Server > Affects Versions: 8.1.0.Final > Reporter: jieryn jieryn > Assignee: James Perkins > Priority: Minor > > Other popular Servlet Containers and Application Servers support the building of an executable war bundle, via Apache Maven. This will allow you to easily bundle your WAR/EAR into an executable war which will unpack and launch the WAR/EAR, via java -jar myapp.war. > http://tomcat.apache.org/maven-plugin-2.0/tomcat7-maven-plugin/exec-war-m... > http://rmannibucau.wordpress.com/2014/03/11/executable-jar-with-tomee-and... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

10 years, 1 month

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 September 2014