December 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3448) Maven plugin loads spurious resources, classes from the classpath in full downstream build

by Edoardo Vacchi (Jira)

Edoardo Vacchi created DROOLS-3448: -------------------------------------- Summary: Maven plugin loads spurious resources, classes from the classpath in full downstream build Key: DROOLS-3448 URL: https://issues.jboss.org/browse/DROOLS-3448 Project: Drools Issue Type: Bug Reporter: Edoardo Vacchi Assignee: Mario Fusco Found out about this bug today, while trying to fix a full downstream build. {{KieServerPolicyDroolsIntegrationTest}} broke with a ClassCastException. tl;dr: there is a problem with ClassLoader delegates AND the way Service Discovery look for {{kie.conf}} on the classpath. As part of DROOLS-3355, DROOLS-3307 I have moved CMMN package-building phase to the Assembler API. This highlighted an issue in the way the Maven plugin is tested (and/or the Service discovery mechanism, depending on how you want to see it) This is what I have understood: - CMMNAssemblerService is in its own package, which depends on jBPM. - the Maven plugin injects its own ClassLoader, - then it calls {{KieServices.Factory.get()}}, - this causes the Service discovery to start, and all the services found in the {{kie.conf}}s that are on the current classpath Please notice that the classpath in the Full Downstream Build includes all the packages, so every kie.conf found in every project jar In the test that broke {{KieServerPolicyDroolsIntegrationTest}}: - Maven instance is created; It is created a new class loader (@ BuildMojo#buildDrl() ) with the jars on which Maven plugin depends. Before my fix, this *DID not* include the dependency on CMMN - *however* kie.conf for CMMNAssemblerService is in the class path of full downstream build! - because it is not a direct Maven dependency, it is *not* in the class loader of the Maven build - CMMNAssemblerService is therefore loaded from the *root classloader* - when KieAssemblerServices are processed, all assembler services *except CMMN* are found in the maven classpath, so they are loaded from that class loader - ClassCastException is raised when CMMNAssemblerService is used because it is not an instance of KieAssemblerService (really, it is: but the class KieAssemblerService has now been loaded from the maven class loader, while CMMNAssemblerService has been loaded from the root classloader) The problem is that the chain of classloaders AND the service discovery mechanism: - The classloader delegates to the root classloader, which loads from the full downstream classpath, which includes everything and loads a service that should not be found; this in turn causes the ClassCastException - the service discovery mechanism loads {{kie.conf}} from the full downstream classpath, which includes jars that should not be processed (as they would not be in the maven plugin classpath) -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11539) Upgrade Infinispan to 9.4.6.Final

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-11539?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-11539: ---------------------------------- Description: Unfortunately, the required changes did not get into 9.4.5.Final. Changelog: https://issues.jboss.org/projects/ISPN/versions/12340282 was:Unfortunately, the required changes did not get into 9.4.5.Final. > Upgrade Infinispan to 9.4.6.Final > --------------------------------- > > Key: WFLY-11539 > URL: https://issues.jboss.org/browse/WFLY-11539 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 15.0.0.Final > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Priority: Major > > Unfortunately, the required changes did not get into 9.4.5.Final. > Changelog: https://issues.jboss.org/projects/ISPN/versions/12340282 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4336) Cannot run testsuite if an application holds port 8080 open

by Fedor Gavrilov (Jira)

[ https://issues.jboss.org/browse/WFLY-4336?page=com.atlassian.jira.plugin.... ] Fedor Gavrilov updated WFLY-4336: --------------------------------- Attachment: 11861.patch > Cannot run testsuite if an application holds port 8080 open > ----------------------------------------------------------- > > Key: WFLY-4336 > URL: https://issues.jboss.org/browse/WFLY-4336 > Project: WildFly > Issue Type: Enhancement > Components: Test Suite > Affects Versions: 9.0.0.Alpha1 > Reporter: Michael Musgrove > Assignee: Fedor Gavrilov > Priority: Optional > Fix For: Awaiting Volunteers > > Attachments: 11861.patch > > > We run jobs on a Jenkins cluster where the master is also a slave. The master runs the web front end gui on port 8080. The default wildfly web profile uses the same port. I tried starting undertow on a different port but the testsuite has some hardcoded references to port 8080, for example: > testsuite/integration/src/test/xslt/changeIPAddresses.xsl > testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/wsat/client/ATClient.java > testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/wsba/coordinatorcompletion/client/BACoordinatorCompletionClient.java > testsuite/integration/xts/src/test/java/org/jboss/as/test/xts/wsba/participantcompletion/client/BAParticipantCompletionClient.java > The particular command I tried was: > {code} > ./tools/maven/bin/mvn -s tools/maven/conf/settings.xml test '-f' './testsuite/integration/xts/pom.xml' '-Pxts.integration.tests.profile' -Djboss.http.port=xxx > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11539) Upgrade Infinispan to 9.4.6.Final

by Radoslav Husar (Jira)

Radoslav Husar created WFLY-11539: ------------------------------------- Summary: Upgrade Infinispan to 9.4.6.Final Key: WFLY-11539 URL: https://issues.jboss.org/browse/WFLY-11539 Project: WildFly Issue Type: Component Upgrade Reporter: Radoslav Husar Assignee: Jason Greene Unfortunately, the required changes did not get into 9.4.5.Final. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11539) Upgrade Infinispan to 9.4.6.Final

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-11539?page=com.atlassian.jira.plugin... ] Radoslav Husar reassigned WFLY-11539: ------------------------------------- Assignee: Paul Ferraro (was: Jason Greene) > Upgrade Infinispan to 9.4.6.Final > --------------------------------- > > Key: WFLY-11539 > URL: https://issues.jboss.org/browse/WFLY-11539 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 15.0.0.Final > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Priority: Major > > Unfortunately, the required changes did not get into 9.4.5.Final. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11539) Upgrade Infinispan to 9.4.6.Final

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-11539?page=com.atlassian.jira.plugin... ] Radoslav Husar updated WFLY-11539: ---------------------------------- Component/s: Clustering Affects Version/s: 15.0.0.Final > Upgrade Infinispan to 9.4.6.Final > --------------------------------- > > Key: WFLY-11539 > URL: https://issues.jboss.org/browse/WFLY-11539 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 15.0.0.Final > Reporter: Radoslav Husar > Assignee: Jason Greene > Priority: Major > > Unfortunately, the required changes did not get into 9.4.5.Final. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11538) Opentracing - SmallRye - IllegalStateException

by Alessandro Moscatelli (Jira)

Alessandro Moscatelli created WFLY-11538: -------------------------------------------- Summary: Opentracing - SmallRye - IllegalStateException Key: WFLY-11538 URL: https://issues.jboss.org/browse/WFLY-11538 Project: WildFly Issue Type: Bug Components: MP OpenTracing Affects Versions: 15.0.0.Final Reporter: Alessandro Moscatelli Fix For: 16.0.0.Beta1 Caused by: org.jboss.weld.exceptions.IllegalStateException: WELD-000713: Unable to inject ServletContext. None is associated with ModuleClassLoader for Module The problem is the interaction between these two: https://github.com/wildfly/wildfly/blob/master/microprofile/opentracing-s... https://github.com/smallrye/smallrye-opentracing/blob/1.1.1/implementatio... Those are delivered with Wildfly 15 out of the box in: smallrye-opentracing-1.1.1.jar wildfly-microprofile-opentracing-smallrye-15.0.0.Final.jar I have an EAR with a EJB jar, WAR and a common JAR library. To reproduce the issue I created a Stateless EJB in the EJB jar and then I injected a Traced ApplicationScoped bean from the JAR library in the Stateless EJB. SmallRyeTracingCDIInterceptor triggers and it requires an Injected Tracer. TracerProducer triggers and it has no active ServletContext and this leads to the error above. My suggestion: I don't think the ServletContext is a really good place to store the Tracer. I think that the Tracer created by Wildfly should be registered into the GlobalTracer. This should be done by: https://github.com/wildfly/wildfly/blob/master/microprofile/opentracing-s... If you don't want Wildfly to register automatically its Tracer in the GlobalTracer, this behavior could be disabled in the subsystem. Also please be aware that SmallRyeTracingCDIInterceptor is dismissed in the last versions of the library and SmallRye states (https://github.com/smallrye/smallrye-opentracing) it has been replaced with: https://github.com/opentracing-contrib/java-interceptors/blob/master/src/... Also be aware that what I am suggesting is similar to the same behavior adopted in opentracing java-cdi (not yet integrated in Wildfly): https://github.com/opentracing-contrib/java-cdi/blob/master/opentracing-c... https://github.com/opentracing-contrib/java-cdi/blob/master/opentracing-c... Also notice that opentracing java-ejb (not yet integrated in Wildfly) also requires a registration in GlobalTracing: https://github.com/opentracing-contrib/java-ejb/blob/master/opentracing-e... Thank you for your support. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11511) Upgrade Infinispan to 9.4.5.Final

by Radoslav Husar (Jira)

[ https://issues.jboss.org/browse/WFLY-11511?page=com.atlassian.jira.plugin... ] Radoslav Husar commented on WFLY-11511: --------------------------------------- [~kabirkhan] Unfortunately no, because Infinispan team has released 9.4.5.Final without the necessary fix being merged. > Upgrade Infinispan to 9.4.5.Final > --------------------------------- > > Key: WFLY-11511 > URL: https://issues.jboss.org/browse/WFLY-11511 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 15.0.0.Final > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Priority: Major > Fix For: 16.0.0.Beta1 > > > Changelog https://issues.jboss.org/projects/ISPN/versions/12340168 -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3447) Remove "DMN Asset" dependency from TitledAttachmentFileWidget

by Gabriele Cardosi (Jira)

Gabriele Cardosi created DROOLS-3447: ---------------------------------------- Summary: Remove "DMN Asset" dependency from TitledAttachmentFileWidget Key: DROOLS-3447 URL: https://issues.jboss.org/browse/DROOLS-3447 Project: Drools Issue Type: Bug Components: Scenario Simulation and Testing Reporter: Gabriele Cardosi Assignee: Gabriele Cardosi Currently, TitledAttachmentFileWidget use ProjectAssetsQuery to retrieve the "dmn" files. Implicitly, this means that *if* (for whatever reason) dmn editor is disabled, the dmn file are not retrieved. Wording differently, this creates an implicit dependency between scenariosimulation and dmn editor. Fix it so that TitledAttachmentFileWidget could find dmn files regardless of dmn editor. Look at left dock that shows all the files of the project. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3313) Websocket Auth - Container is not aware of the Principal

by Darran Lofthouse (Jira)

[ https://issues.jboss.org/browse/WFLY-3313?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-3313: -------------------------------------- Assignee: Darran Lofthouse (was: Stuart Douglas) > Websocket Auth - Container is not aware of the Principal > -------------------------------------------------------- > > Key: WFLY-3313 > URL: https://issues.jboss.org/browse/WFLY-3313 > Project: WildFly > Issue Type: Bug > Components: EJB, Security, Web (Undertow), Web Sockets > Affects Versions: 8.1.0.CR1, 10.0.0.Final, 15.0.0.Final > Reporter: Markus D > Assignee: Darran Lofthouse > Priority: Major > Attachments: websocket-different-principals-ejb-vs-socket.png, websocket-endpoint-security.war > > > The Websocket is protected by the web.xml. The session object of the callback object correctly returns the principal. > When an EJB is called the callerPrincipal is always anonymous. > @Resource > private SessionContext ctx; > Principal callerPrincipal = ctx.getCallerPrincipal(); > Running thread here: > https://community.jboss.org/thread/240617 > Shouldn't the principal be propagated to the EJB container when a websocket callback method triggered? -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 7 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 December 2018