May 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1595) Reenable source compatibility check during build

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-1595?page=com.atlassian.jira.plugin.s... ] Martin Choma updated ELY-1595: ------------------------------ Fix Version/s: 1.3.4.CR1 > Reenable source compatibility check during build > ------------------------------------------------ > > Key: ELY-1595 > URL: https://issues.jboss.org/browse/ELY-1595 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.3.3.Final > Reporter: Martin Choma > Assignee: Jan Kalina > Fix For: 1.3.4.CR1 > > > With ELY-1572 source compatibility check was disabled because of bug in japicmp-base-0.12.0 . With new release it should be fixed and source compatibility can be checked again. > [1] https://github.com/wildfly-security/wildfly-elytron/pull/1145#issuecommen... > [2] Also related ELY-1587 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1595) Reenable source compatibility check during build

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-1595?page=com.atlassian.jira.plugin.s... ] Martin Choma updated ELY-1595: ------------------------------ Description: With ELY-1572 source compatibility check was disabled because of bug in japicmp-base-0.12.0 . With new release of japicmp it should be fixed and source compatibility can be checked again. [1] https://github.com/wildfly-security/wildfly-elytron/pull/1145#issuecommen... [2] Also related ELY-1587 was: With ELY-1572 source compatibility check was disabled because of bug in japicmp-base-0.12.0 . With new release it should be fixed and source compatibility can be checked again. [1] https://github.com/wildfly-security/wildfly-elytron/pull/1145#issuecommen... [2] Also related ELY-1587 > Reenable source compatibility check during build > ------------------------------------------------ > > Key: ELY-1595 > URL: https://issues.jboss.org/browse/ELY-1595 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.3.3.Final > Reporter: Martin Choma > Assignee: Jan Kalina > Fix For: 1.3.4.CR1 > > > With ELY-1572 source compatibility check was disabled because of bug in japicmp-base-0.12.0 . With new release of japicmp it should be fixed and source compatibility can be checked again. > [1] https://github.com/wildfly-security/wildfly-elytron/pull/1145#issuecommen... > [2] Also related ELY-1587 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1595) Reenable source compatibility check during build

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/ELY-1595?page=com.atlassian.jira.plugin.s... ] Martin Choma reassigned ELY-1595: --------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Reenable source compatibility check during build > ------------------------------------------------ > > Key: ELY-1595 > URL: https://issues.jboss.org/browse/ELY-1595 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.3.3.Final > Reporter: Martin Choma > Assignee: Jan Kalina > > With ELY-1572 source compatibility check was disabled because of bug in japicmp-base-0.12.0 . With new release it should be fixed and source compatibility can be checked again. > [1] https://github.com/wildfly-security/wildfly-elytron/pull/1145#issuecommen... > [2] Also related ELY-1587 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1595) Reenable source compatibility check during build

by Martin Choma (JIRA)

Martin Choma created ELY-1595: --------------------------------- Summary: Reenable source compatibility check during build Key: ELY-1595 URL: https://issues.jboss.org/browse/ELY-1595 Project: WildFly Elytron Issue Type: Bug Affects Versions: 1.3.3.Final Reporter: Martin Choma Assignee: Darran Lofthouse With ELY-1572 source compatibility check was disabled because of bug in japicmp-base-0.12.0 . With new release it should be fixed and source compatibility can be checked again. [1] https://github.com/wildfly-security/wildfly-elytron/pull/1145#issuecommen... [2] Also related ELY-1587 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2596) KieScanner does not load new rules

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2596?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-2596: ------------------------------------- Also requires https://github.com/kiegroup/drools/commit/74dec3a9f709952c85f7cd358724110... > KieScanner does not load new rules > ---------------------------------- > > Key: DROOLS-2596 > URL: https://issues.jboss.org/browse/DROOLS-2596 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.6.0.Final, 7.7.0.Final > Reporter: Viacheslav Krot > Assignee: Mario Fusco > Attachments: drools7_bug.zip, drools7_bug_rules.zip > > > There is a problem with adding new rules via KieScanner. If I add new .drl files to rules artifact - new rules are not fired. KieScanner successfully updates artifact, it applies changes to previously loaded rules, but it does not see new rules. > I've created a simple project reproducing this bug. > Steps to reproduce: > - unpack drools7_bug and drools7_bug_rules projects > - build drools7_bug (mvn clean install) > - updated repository url in drools7_bug_rules pom, deploy it > - run Main in drools7_bug. rule1 is fired, prints to stderr once a second. > - copy rule2.drl from src/main/tmp to src/main/resources. change output string in rule1. > - deploy artifact > - now I expect both rules fired, but only rule1 is works, no output from rule2. Make sure new artifact was loaded in scanner jmx bean. Rule1 writes new string to stderr, it was updated. > - now simply restart Main, both rules are fired. > There are no error or warning, new rules simply don't work. Am I doing something wrong? > Same scenario worked perfect until version 7.5.0. You can update version in pom and same scenario passes successfully. 7.6.0 and 7.7.0 don't though > I added api module with pojos just to reproduce our usecase as close as possible. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10411) TLDs under META-INF/resources inside the web-fragment jar is not loaded

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFLY-10411?page=com.atlassian.jira.plugin... ] Tomas Hofman commented on WFLY-10411: ------------------------------------- I think that specifying taglib by its' physical location is possible only in cases when: * taglib is located directly in the WAR - in this case uri is relative path to the tld, * a single tld is located in JAR in META-INF/taglib.tld - in this case uri is relative path to the JAR. When JAR contains multiple tlds (allowed since JSP 1.2), then the TLD can be referenced by: * URIs defined in <taglib-uri> element in web-fragment.xml: {code} <jsp-config> <taglib> <taglib-uri>/HiTag</taglib-uri> <taglib-location>/resources/WEB-INF/tlds/hi.tld</taglib-location> </taglib> </jsp-config> {code} * URIs defined in <uri> element in the TLD file itself: {code} <taglib ...> <tlib-version>1.0</tlib-version> <short-name>hi-taglib</short-name> <uri>/HiTag</uri> <tag>...</tag> </taglib> {code} {quote} JSP.7.3.2 TLD resource path A URI in a taglib directive is mapped into a context relative path ... called the TLD resource path. The TLD resource path is interpreted relative to the root of the web application and should resolve to a TLD file directly, or to a JAR file that has a TLD file at location META-INF/taglib.tld. If the TLD resource path is not one of these two cases, a fatal translation error will occur. {quote} {quote} JSP.7.3.4 Implicit Map Entries from TLDs The taglib map described in web.xml is extended with new entries extracted from TLD files in the Web Application. The new entries are computed as follows: * The container searches for all files with a .tld extension under /WEB-INF or a subdirectory, and inside JAR files that are in /WEB-INF/lib. When examining a JAR file, only resources under /META-INF or a subdirectory are considered. The order in which these files are searched for is implementation-specific and should not be relied on by web applications. * Each TLD file is examined. If it has a <uri> element, then a new <taglib> element is created, with a <taglib-uri> subelement whose value is that of the <uri> element, and with a <taglib-location> subelement that refers to the TLD file. * If the created <taglib> element has a different <taglib-uri> to any in the taglib map, it is added. This mechanism provides an automatic URI to TLD mapping as well as supporting multiple TLDs within a packaged JAR. Note that this functionality does not require explicitly naming the location of the TLD file, which would require a mechanism like the jar:protocol. {quote} > TLDs under META-INF/resources inside the web-fragment jar is not loaded > ----------------------------------------------------------------------- > > Key: WFLY-10411 > URL: https://issues.jboss.org/browse/WFLY-10411 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 13.0.0.Beta1 > Reporter: Masafumi Miura > Assignee: Stuart Douglas > Attachments: jsp-taglib-jar-in-war.zip > > > TLDs under META-INF/resources inside the web-fragment jar is not loaded. > {code:title=directory structure of the web-fragment jar} > taglib-jar > |-- META-INF > | |-- resources > | | `-- WEB-INF > | | `-- tlds > | | `-- hi.tld > | `-- web-fragment.xml > `-- simple > `-- HiTag.class > {code} > {code:title=web-fragment.xml} > <?xml version="1.0" encoding="UTF-8"?> > <web-fragment id="WebFragment_ID" > version="3.0" > xmlns="http://java.sun.com/xml/ns/javaee" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-fragment_3_0.xsd"> > ...(snip)... > <jsp-config> > <taglib> > <taglib-uri>/HiTag</taglib-uri> > <taglib-location>/WEB-INF/tlds/hi.tld</taglib-location> > </taglib> > </jsp-config> > </web-fragment> > {code} > The following ERROR is thrown at the deployment: > {code} > ERROR [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0074: Could not find TLD /WEB-INF/tlds/hi.tld > {code} > JSP returns "500 Internal Server Error" and Jastow throws the following ERROR when accessing the JSP which has {{<%@ taglib uri="/HiTag" prefix="say"%>}} or {{<%@ taglib uri="/WEB-INF/tlds/hi.tld" prefix="say"%>}}: > {code} > ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /taglib-jar-in-war/hi.jsp: org.apache.jasper.JasperException: JBWEB004036: File "/HiTag" not found > at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:57) > at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:278) > at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:75) > at org.apache.jasper.compiler.TagLibraryInfoImpl.<init>(TagLibraryInfoImpl.java:171) > at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:412) > at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:475) > at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1459) > at org.apache.jasper.compiler.Parser.parse(Parser.java:143) > at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:223) > at org.apache.jasper.compiler.ParserController.parse(ParserController.java:102) > at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:200) > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354) > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) > at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652) > at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) > at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > ...(snip)... > {code} > {code} > ERROR [io.undertow.request] (default task-1) UT005023: Exception handling request to /taglib-jar-in-war/index.jsp: org.apache.jasper.JasperException: JBWEB004036: File "/WEB-INF/tlds/hi.tld" not found > at org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:57) > at org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:278) > at org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:75) > at org.apache.jasper.compiler.TagLibraryInfoImpl.<init>(TagLibraryInfoImpl.java:171) > at org.apache.jasper.compiler.Parser.parseTaglibDirective(Parser.java:412) > at org.apache.jasper.compiler.Parser.parseDirective(Parser.java:475) > at org.apache.jasper.compiler.Parser.parseElements(Parser.java:1459) > at org.apache.jasper.compiler.Parser.parse(Parser.java:143) > at org.apache.jasper.compiler.ParserController.doParse(ParserController.java:223) > at org.apache.jasper.compiler.ParserController.parse(ParserController.java:102) > at org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:200) > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:354) > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:334) > at org.apache.jasper.compiler.Compiler.compile(Compiler.java:321) > at org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:652) > at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:358) > at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:403) > at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:347) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > ...(snip)... > {code} > Note that the same war file can be deployed and the JSPs works on Tomcat 8. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10480) ElytronSecurityDomainContextImpl does not propagate authenticated subject

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-10480?page=com.atlassian.jira.plugin... ] Alessio Soldano commented on WFLY-10480: ---------------------------------------- [~darranl] please see here, can you help Jim on this please? > ElytronSecurityDomainContextImpl does not propagate authenticated subject > ------------------------------------------------------------------------- > > Key: WFLY-10480 > URL: https://issues.jboss.org/browse/WFLY-10480 > Project: WildFly > Issue Type: Bug > Reporter: Alessio Soldano > Assignee: Jim Ma > Fix For: 14.0.0.CR1 > > > We have a usecase scenario which requires ElytronSecurityDomainContextImpl to propagate the authenticated subject from webservice subsystem to > ejb subystem. With old security domain , we used to rely on the following integration code in the SecurityDomainContextImpl: > @Override > public void pushSubjectContext(final Subject subject, final Principal principal, final Object credential) { > AccessController.doPrivileged(new PrivilegedAction<Void>() { > public Void run() { > SecurityContext securityContext = SecurityContextAssociation.getSecurityContext(); > if (securityContext == null) { > securityContext = createSecurityContext(getSecurityDomain()); > setSecurityContextOnAssociation(securityContext); > } > securityContext.getUtil().createSubjectInfo(principal, credential, subject); > return null; > } > }); > } > When an Elytron security domain is configured for the ws application, the functionality is not working as the corresponding method in ElytronSecurityDomainContextImpl is empty. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10480) ElytronSecurityDomainContextImpl does not propagate authenticated subject

by Alessio Soldano (JIRA)

Alessio Soldano created WFLY-10480: -------------------------------------- Summary: ElytronSecurityDomainContextImpl does not propagate authenticated subject Key: WFLY-10480 URL: https://issues.jboss.org/browse/WFLY-10480 Project: WildFly Issue Type: Bug Reporter: Alessio Soldano Assignee: Jim Ma Fix For: 14.0.0.CR1 We have a usecase scenario which requires ElytronSecurityDomainContextImpl to propagate the authenticated subject from webservice subsystem to ejb subystem. With old security domain , we used to rely on the following integration code in the SecurityDomainContextImpl: @Override public void pushSubjectContext(final Subject subject, final Principal principal, final Object credential) { AccessController.doPrivileged(new PrivilegedAction<Void>() { public Void run() { SecurityContext securityContext = SecurityContextAssociation.getSecurityContext(); if (securityContext == null) { securityContext = createSecurityContext(getSecurityDomain()); setSecurityContextOnAssociation(securityContext); } securityContext.getUtil().createSubjectInfo(principal, credential, subject); return null; } }); } When an Elytron security domain is configured for the ws application, the functionality is not working as the corresponding method in ElytronSecurityDomainContextImpl is empty. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2432) [DMN Designer] Back to from DRD doesn't select proper element in DRG

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2432?page=com.atlassian.jira.plugi... ] Jozef Marko commented on DROOLS-2432: ------------------------------------- [~karreiro] Hi, during checking third point of the acceptance test I noticed this. If you select multiple nodes of canvas (blue rectangle around them) and then select single node in the navigation dock, the group selection will not disappear, see the attachment. My concern is that this is not consistent with selecting single node directly on canvas, that always discards the group selection (if present). Could you please confirm I can file a jira for this? > [DMN Designer] Back to from DRD doesn't select proper element in DRG > -------------------------------------------------------------------- > > Key: DROOLS-2432 > URL: https://issues.jboss.org/browse/DROOLS-2432 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.8.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Carreiro > Priority: Minor > Attachments: Screenshot from 2018-05-30 09-10-26.png > > > If user navigates back from DRD, the selection in DRG is not updated. > h3. Manual Acceptance Test > - Select *nothing* on canvas, open some context, use back to xyz (/) > - Select *one node* on canvas, open some context, use back to xyz (/) > - Select *multiple nodes* on canvas, open some context, use back to xyz (?) > - Do *unsaved changes* on canvas, open some context, use back to xyz (/) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2432) [DMN Designer] Back to from DRD doesn't select proper element in DRG

by Jozef Marko (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2432?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-2432: -------------------------------- Attachment: Screenshot from 2018-05-30 09-10-26.png > [DMN Designer] Back to from DRD doesn't select proper element in DRG > -------------------------------------------------------------------- > > Key: DROOLS-2432 > URL: https://issues.jboss.org/browse/DROOLS-2432 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.8.0.Final > Reporter: Jozef Marko > Assignee: Guilherme Carreiro > Priority: Minor > Attachments: Screenshot from 2018-05-30 09-10-26.png > > > If user navigates back from DRD, the selection in DRG is not updated. > h3. Manual Acceptance Test > - Select *nothing* on canvas, open some context, use back to xyz (/) > - Select *one node* on canvas, open some context, use back to xyz (/) > - Select *multiple nodes* on canvas, open some context, use back to xyz (?) > - Do *unsaved changes* on canvas, open some context, use back to xyz (/) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 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 May 2018