[JBoss JIRA] (WFLY-3067) Webservices DUP is not scanning all visible classes for @WebService annotation
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3067?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3067:
-----------------------------------------------
Rostislav Svoboda <rsvoboda(a)redhat.com> changed the Status of [bug 1079084|https://bugzilla.redhat.com/show_bug.cgi?id=1079084] from ON_QA to VERIFIED
> Webservices DUP is not scanning all visible classes for @WebService annotation
> ------------------------------------------------------------------------------
>
> Key: WFLY-3067
> URL: https://issues.jboss.org/browse/WFLY-3067
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Affects Versions: 8.0.0.Final
> Reporter: Kyle Lape
> Assignee: Jim Ma
> Fix For: 8.1.0.CR1
>
>
> Sample use case: You have a .war in an .ear, and the .war has a web.xml with a {{<servlet-class>}} that refers to a JAX-WS endpoint, so the class is annotated with {{@WebService}}. If that class is packaged in a jar found in the ear's lib directory, the JBossWS DUP won't pick it up, and then Undertow will throw an error like this:
> {noformat}
> UT010009: Servlet ClientEndpoint of type class com.redhat.gss.jaxws.ClientEndpoint does not implement javax.servlet.Servlet
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3048?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3048:
-----------------------------------------------
Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 1069127|https://bugzilla.redhat.com/show_bug.cgi?id=1069127] from ON_QA to VERIFIED
> "Local" authentication fails when LDAP is used for ManagementRealm
> ------------------------------------------------------------------
>
> Key: WFLY-3048
> URL: https://issues.jboss.org/browse/WFLY-3048
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 8.0.0.Final
> Environment: Ubuntu 13.04, Xeon-based VPS
> Reporter: Matt Jensen
> Assignee: Darran Lofthouse
> Fix For: 8.1.0.CR1
>
>
> When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working.
> I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows:
> <security-realm name="ManagementRealm">
> <authentication>
> <local default-user="$local" />
> <ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false">
> ...
> </ldap>
> </authentication>
> <authorization map-groups-to-roles="false">
> <ldap connection="...">
> ...
> </ldap>
> </authorization>
> </security-realm>
> I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command.
> The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm.
> If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password.
> I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password.
> The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up.
> The documentation specifically mentions that <local/> should work along with <ldap/> here:
> https://docs.jboss.org/author/display/WFLY8/Security+Realms
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (WFLY-3048) "Local" authentication fails when LDAP is used for ManagementRealm
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3048?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3048:
-----------------------------------------------
Ondrej Lukas <olukas(a)redhat.com> changed the Status of [bug 1043667|https://bugzilla.redhat.com/show_bug.cgi?id=1043667] from ON_QA to VERIFIED
> "Local" authentication fails when LDAP is used for ManagementRealm
> ------------------------------------------------------------------
>
> Key: WFLY-3048
> URL: https://issues.jboss.org/browse/WFLY-3048
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Security
> Affects Versions: 8.0.0.Final
> Environment: Ubuntu 13.04, Xeon-based VPS
> Reporter: Matt Jensen
> Assignee: Darran Lofthouse
> Fix For: 8.1.0.CR1
>
>
> When LDAP is used for authentication in ManagementRealm, "local" authentication, which is enabled in configuration for the realm, appears to stop working.
> I have configured my ManagementRealm to use LDAP for authentication of remote clients. However, I also need to allow local authentication without a username and password, for when jboss-cli is invoked from the command line on the server. This is needed in order for the wildfly-init-debian.sh script to shut down the server. I have configured the ManagementRealm as follows:
> <security-realm name="ManagementRealm">
> <authentication>
> <local default-user="$local" />
> <ldap connection="..." base-dn="ou=accounts,dc=..." recursive="false">
> ...
> </ldap>
> </authentication>
> <authorization map-groups-to-roles="false">
> <ldap connection="...">
> ...
> </ldap>
> </authorization>
> </security-realm>
> I left out most of the LDAP configuration because I don't think it is important for this issue. LDAP authentication works fine for remote clients. In fact, it works fine for local clients as well--when I invoke jboss-cli with LDAP authentication enabled, it prompts for a username and password; if I enter a valid combination from the LDAP directory, jboss-cli connects successfully and executes its command.
> The problem is that I need it to NOT prompt for a username and password when jboss-cli is invoked locally. Which, I believe, is how things are supposed to work when "local" authentication is also enabled; it just doesn't work that way when LDAP is enabled for the same realm.
> If I comment out the <ldap .../> element in <authentication> for the realm, local authentication starts working again. I can invoke jboss-cli locally and the command is carried out without a username and password prompt. Re-enable LDAP, with no other configuration changes, and again it flips back to requiring a username and password.
> I have tried replacing "$local" in the @default-user element of the <local> element with a valid name from the LDAP directory, both as a simple username and as a full DN, and jboss-cli still prompts for a username and password.
> The modification date on the [tmp/auth] directory changes when I run jboss-cli with LDAP in place and get the username/password prompt, so it appears that the client is putting a token in there to try to use local authentication. The server just never picks it up.
> The documentation specifically mentions that <local/> should work along with <ldap/> here:
> https://docs.jboss.org/author/display/WFLY8/Security+Realms
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (WFLY-3228) ApplyRemoteMasterDomainHandler should use values sent from DC for root resource
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3228?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3228:
-----------------------------------------------
Petr Kremensky <pkremens(a)redhat.com> changed the Status of [bug 1085122|https://bugzilla.redhat.com/show_bug.cgi?id=1085122] from ON_QA to VERIFIED
> ApplyRemoteMasterDomainHandler should use values sent from DC for root resource
> -------------------------------------------------------------------------------
>
> Key: WFLY-3228
> URL: https://issues.jboss.org/browse/WFLY-3228
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 8.0.0.Final
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 8.1.0.CR1
>
>
> This is needed to keep the slave copy of the resource model actually the same, and popped up during mixed domain testing of EAP with a 6.2.0 slave.
> Connect directly to to 6.1.1 slave - gets domain version from master
> {code}
> [domain@localhost:19999 /] :read-resource
> {
> "outcome" => "success",
> "result" => {
> "deployment" => undefined,
> "deployment-overlay" => undefined,
> "management-major-version" => 1,
> "management-micro-version" => 0,
> "management-minor-version" => 6,
> "name" => "Unnamed Domain",
> "namespaces" => [],
> "path" => undefined,
> "product-name" => "EAP",
> "product-version" => "6.3.0.Alpha3",
> "profile" => undefined,
> "release-codename" => "Janus",
> "release-version" => "7.4.0.Final-redhat-SNAPSHOT",
> {code}
> Connect directly to 6.2.0 slave - does not get domain version from master
> {code}
> [domain@localhost:19999 /] :read-resource
> {
> "outcome" => "success",
> "result" => {
> "management-major-version" => 1,
> "management-micro-version" => 0,
> "management-minor-version" => 5,
> "name" => "Unnamed Domain",
> "namespaces" => [],
> "product-name" => "EAP",
> "product-version" => "6.2.0.GA",
> "release-codename" => "Janus",
> "release-version" => "7.3.0.Final-redhat-14",
> {code}
> The 6.2.0 slave should look the same as the 6.1.1 slave for these attributes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (DROOLS-88) Support generics in declared types' fields
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-88?page=com.atlassian.jira.plugin.... ]
Michael Biarnes Kiefer updated DROOLS-88:
-----------------------------------------
Fix Version/s: 6.1.0.Beta4
(was: 6.1.0.Beta3)
> Support generics in declared types' fields
> ------------------------------------------
>
> Key: DROOLS-88
> URL: https://issues.jboss.org/browse/DROOLS-88
> Project: Drools
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Reporter: Davide Sottara
> Assignee: Davide Sottara
> Priority: Minor
> Fix For: 5.5.1.Final, 6.1.0.Beta4
>
>
> It should be possible to write:
> declare Foo
> list : List<String>
> end
> While not supported in rules using the mvel dialect, it makes declared types much more readable, and adds some type-safety to java rules.
> Notice that this ticket is NOT related to the possibility of declaring generic classes, such as Foo<T>.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months
[JBoss JIRA] (DROOLS-115) Add support for strong negation
by Michael Biarnes Kiefer (JIRA)
[ https://issues.jboss.org/browse/DROOLS-115?page=com.atlassian.jira.plugin... ]
Michael Biarnes Kiefer updated DROOLS-115:
------------------------------------------
Fix Version/s: 6.1.0.Beta4
(was: 6.1.0.Beta3)
> Add support for strong negation
> -------------------------------
>
> Key: DROOLS-115
> URL: https://issues.jboss.org/browse/DROOLS-115
> Project: Drools
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Davide Sottara
> Assignee: Davide Sottara
> Priority: Minor
> Fix For: 6.1.0.Beta4
>
>
> Drools "not" operator implements a type of "negation by failure", i.e. not X() behaves as the negation of "exists" or, in other words, translates as "it is NOT asserted that ...".
> However, another form of stronger negation is needed to express conditionals such as "it is asserted that NOT ..."
> It should be possible, then, to assert facts both in a "positive" and "negative" way, to assert THAT and THAT NOT.
> The language should also support a "neg" CE to create "negative" patterns which will match with negative facts. I.e. it should be possible to write rules such as:
> when $p : Person() and Car( owner == $p ) then
> // a positive, matching Car is present in the WM
> when $p : Person() and neg Car( owner == $p ) then
> // a negative, matching Car is present in the WM
> when $p : Person() and not Car( owner == $p ) then
> // neither a positive nor a negative fact exists in the WM
> For a more detailed description and motivation see e.g.:
> https://oxygen.informatik.tu-cottbus.de/publications/wagner/WebRules2Neg.pdf
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 4 months