[JBoss JIRA] (WFLY-4308) Proxies created via ContextService.createContextualProxy(...) are not Serializable
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-4308:
----------------------------------
Summary: Proxies created via ContextService.createContextualProxy(...) are not Serializable
Key: WFLY-4308
URL: https://issues.jboss.org/browse/WFLY-4308
Project: WildFly
Issue Type: Bug
Components: EE
Affects Versions: 9.0.0.Alpha1
Reporter: Paul Ferraro
Assignee: David Lloyd
Priority: Critical
Setting priority to critical since this is a matter of compliance with the concurrency utilities specification.
Section 3.3.4 of the specification states that:
"All invocation handlers for the contextual proxy implementation must implement java.io.Serializable."
While the invocation handler does indeed implement Serializable, it contains a reference to org.jboss.as.server.moduleservice.ServiceModuleLoader, which is not serializable, thus the invocation handler cannot be serialized.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4304) Servlet authentication kicked off when *not* a part of any security-constraint
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-4304?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-4304:
-----------------------------------
Priority: Major (was: Critical)
> Servlet authentication kicked off when *not* a part of any security-constraint
> ------------------------------------------------------------------------------
>
> Key: WFLY-4304
> URL: https://issues.jboss.org/browse/WFLY-4304
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Reporter: Brett Meyer
> Assignee: Darran Lofthouse
>
> Artificer runs on Wildfly 8.2 and uses Keycloak for auth. If our WAR contains a servlet that is *not* protected by a security-constraint in web.xml, Wildfly still attempts to authenticate the call (using Wireshark, I see the GET/POST get funneled through the Keycloak realm redirection) if basic auth credentials are in the header. In a keycloak-dev thread this past Dec., [~bill.burke] suggested this was most likely an issue within Wildfly auth itself.
> A credentialed call on an un-protected servlet does sound like an edge case. However, this came up possibly due to a secondary symptom:
> If I protect the servlet in web.xml, the call's Authorization header is stripped. I'm not currently able to figure out exactly where that's occurring...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4304) Servlet authentication kicked off when *not* a part of any security-constraint
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-4304?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-4304:
--------------------------------------
Assignee: Darran Lofthouse (was: Jason Greene)
> Servlet authentication kicked off when *not* a part of any security-constraint
> ------------------------------------------------------------------------------
>
> Key: WFLY-4304
> URL: https://issues.jboss.org/browse/WFLY-4304
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Reporter: Brett Meyer
> Assignee: Darran Lofthouse
> Priority: Critical
>
> Artificer runs on Wildfly 8.2 and uses Keycloak for auth. If our WAR contains a servlet that is *not* protected by a security-constraint in web.xml, Wildfly still attempts to authenticate the call (using Wireshark, I see the GET/POST get funneled through the Keycloak realm redirection) if basic auth credentials are in the header. In a keycloak-dev thread this past Dec., [~bill.burke] suggested this was most likely an issue within Wildfly auth itself.
> A credentialed call on an un-protected servlet does sound like an edge case. However, this came up possibly due to a secondary symptom:
> If I protect the servlet in web.xml, the call's Authorization header is stripped. I'm not currently able to figure out exactly where that's occurring...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-702) Rule Inheritance fired the sub rule even the condition doen't match
by Yacine Jaber (JIRA)
[ https://issues.jboss.org/browse/DROOLS-702?page=com.atlassian.jira.plugin... ]
Yacine Jaber commented on DROOLS-702:
-------------------------------------
I think the first one(from) is more secure. Cause "==" depends on hash & equals. It could change the behavior if these methods are extended.
Thank you for your help. I close this issue.
> Rule Inheritance fired the sub rule even the condition doen't match
> -------------------------------------------------------------------
>
> Key: DROOLS-702
> URL: https://issues.jboss.org/browse/DROOLS-702
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final
> Environment: Windows, Java6.0.29
> Reporter: Yacine Jaber
> Assignee: Davide Sottara
> Priority: Critical
> Attachments: wod-drools-test.7z
>
>
> You can find the attached a simple maven project that shows this error.
> You can run ExampleDrools class as main java application.
> The sub rules are fired even if the condition is not matched.
> There are a work arround by using <from $fact> into a sub rule to avoid firing this one.
> This simple project shows the failed and work arround test.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (DROOLS-702) Rule Inheritance fired the sub rule even the condition doen't match
by Yacine Jaber (JIRA)
[ https://issues.jboss.org/browse/DROOLS-702?page=com.atlassian.jira.plugin... ]
Yacine Jaber closed DROOLS-702.
-------------------------------
> Rule Inheritance fired the sub rule even the condition doen't match
> -------------------------------------------------------------------
>
> Key: DROOLS-702
> URL: https://issues.jboss.org/browse/DROOLS-702
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final
> Environment: Windows, Java6.0.29
> Reporter: Yacine Jaber
> Assignee: Davide Sottara
> Priority: Critical
> Attachments: wod-drools-test.7z
>
>
> You can find the attached a simple maven project that shows this error.
> You can run ExampleDrools class as main java application.
> The sub rules are fired even if the condition is not matched.
> There are a work arround by using <from $fact> into a sub rule to avoid firing this one.
> This simple project shows the failed and work arround test.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4305) Script rumbles on after error
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFLY-4305?page=com.atlassian.jira.plugin.... ]
Carlo de Wolf updated WFLY-4305:
--------------------------------
Issue Type: Bug (was: Feature Request)
> Script rumbles on after error
> -----------------------------
>
> Key: WFLY-4305
> URL: https://issues.jboss.org/browse/WFLY-4305
> Project: WildFly
> Issue Type: Bug
> Components: Build System
> Reporter: Carlo de Wolf
> Assignee: Carlo de Wolf
>
> After a failure in the script it rumbles on.
> {noformat}
> (master) carlo@devel01:~/work/wildfly$ ./build.sh clean
> ./tools/download-maven.sh: 20: ./tools/download-maven.sh: curl: not found
> Archive: maven.zip
> End-of-central-directory signature not found. Either this file is not
> a zipfile, or it constitutes one disk of a multi-part archive. In the
> latter case the central directory and zipfile comment will be found on
> the last disk(s) of this archive.
> unzip: cannot find zipfile directory in one of maven.zip or
> maven.zip.zip, and cannot find maven.zip.ZIP, period.
> mv: cannot stat ‘apache-maven*’: No such file or directory
> build.sh: Could not locate Maven; check $MVN or $MAVEN_HOME.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months