[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
[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
[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
[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
[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
[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