[JBoss JIRA] (WFLY-3201) Channel end notification received, closing channel ... should be logged at debug
by Brad Maxwell (JIRA)
Brad Maxwell created WFLY-3201:
----------------------------------
Summary: Channel end notification received, closing channel ... should be logged at debug
Key: WFLY-3201
URL: https://issues.jboss.org/browse/WFLY-3201
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Naming
Reporter: Brad Maxwell
Assignee: Brad Maxwell
Remote naming is logging this at ERROR, though it seems normal and no adverse effects are apparent, we should log it at debug instead of error.
ERROR Channel end notification received, closing channel Channel ID b8e969d6 (outbound) of Remoting connection 4970f4db to ...
--
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
11 years, 8 months
[JBoss JIRA] (WFLY-2881) org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase#testCalendarBasedTimeout
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-2881?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-2881:
-------------------------------
Priority: Blocker (was: Major)
> org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase#testCalendarBasedTimeout
> --------------------------------------------------------------------------------------
>
> Key: WFLY-2881
> URL: https://issues.jboss.org/browse/WFLY-2881
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Frank Langelage
> Assignee: Eduardo Martins
> Priority: Blocker
> Fix For: 8.0.1.Final
>
> Attachments: org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.txt, TEST-org.jboss.as.ejb3.timer.schedule.CalendarBasedTimeoutTestCase.xml
>
>
> Running build with smoke tests on current github sources I get failure in this test case.
> HOUR_OF_DAY is not 0 as expected but 1.
> I changed the Assert in the test case to print out firstTimeout.toString() instead of only timeZoneDisplayName.
> See attached files for more.
--
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
11 years, 8 months
[JBoss JIRA] (WFLY-3200) Support Jackson 2 out of the box
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3200?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3200:
------------------------------
Affects Version/s: 8.0.0.Final
> Support Jackson 2 out of the box
> --------------------------------
>
> Key: WFLY-3200
> URL: https://issues.jboss.org/browse/WFLY-3200
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: REST
> Affects Versions: 8.0.0.Final
> Reporter: Nathaniel A. Johnson
> Assignee: Stuart Douglas
> Priority: Minor
>
> Wildfly can be configured to allow access to the native Jackson API. In order to accomplish this, you have to add a jboss-deployment-structure.xml that contains the following:
> <jboss-deployment-structure>
> <deployment>
> <exclusions>
> <module name="org.jboss.resteasy.resteasy-jackson-provider"/>
> </exclusions>
> <dependencies>
> <module name="org.jboss.resteasy.resteasy-jackson2-provider" services="import"/>
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> It would be better if Jackson 2 were the default provider and this were not necessary.
--
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
11 years, 8 months
[JBoss JIRA] (WFLY-3200) Support Jackson 2 out of the box
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3200?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3200:
------------------------------
Description:
Wildfly can be configured to allow access to the native Jackson API. In order to accomplish this, you have to add a jboss-deployment-structure.xml that contains the following:
{code:xml}
<jboss-deployment-structure>
<deployment>
<exclusions>
<module name="org.jboss.resteasy.resteasy-jackson-provider"/>
</exclusions>
<dependencies>
<module name="org.jboss.resteasy.resteasy-jackson2-provider" services="import"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
{code}
It would be better if Jackson 2 were the default provider and this were not necessary.
was:
Wildfly can be configured to allow access to the native Jackson API. In order to accomplish this, you have to add a jboss-deployment-structure.xml that contains the following:
<jboss-deployment-structure>
<deployment>
<exclusions>
<module name="org.jboss.resteasy.resteasy-jackson-provider"/>
</exclusions>
<dependencies>
<module name="org.jboss.resteasy.resteasy-jackson2-provider" services="import"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
It would be better if Jackson 2 were the default provider and this were not necessary.
> Support Jackson 2 out of the box
> --------------------------------
>
> Key: WFLY-3200
> URL: https://issues.jboss.org/browse/WFLY-3200
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: REST
> Affects Versions: 8.0.0.Final
> Reporter: Nathaniel A. Johnson
> Assignee: Stuart Douglas
> Priority: Minor
>
> Wildfly can be configured to allow access to the native Jackson API. In order to accomplish this, you have to add a jboss-deployment-structure.xml that contains the following:
> {code:xml}
> <jboss-deployment-structure>
> <deployment>
> <exclusions>
> <module name="org.jboss.resteasy.resteasy-jackson-provider"/>
> </exclusions>
> <dependencies>
> <module name="org.jboss.resteasy.resteasy-jackson2-provider" services="import"/>
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> {code}
> It would be better if Jackson 2 were the default provider and this were not necessary.
--
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
11 years, 8 months
[JBoss JIRA] (SECURITY-815) NegotiationAuthenticator loses post data
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-815?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated SECURITY-815:
--------------------------------------
Fix Version/s: Negotiation_2_3_0_Final
> NegotiationAuthenticator loses post data
> ----------------------------------------
>
> Key: SECURITY-815
> URL: https://issues.jboss.org/browse/SECURITY-815
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Affects Versions: Negotiation_2_2_5
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
> Fix For: Negotiation_2_3_0_Final
>
>
> The NegotiationAuthenticator loses post data.
> A customer is attempting to use Negotiation along with PicketLink at the IDP. This works fine as long as the SP is using HTTP-Redirect SAML binding.
> If the SP is using HTTP-Redirect, then this issue is avoided as the SAMLRequest is passed along through the redirects on the URL.
> If the HTTP-POST binding is used, then the NegotiationAuthenticator will lose the SAMLRequest post parameter. This means that after a user is successfully authenticated, the IDP will not know where to redirect the user to. As a result, the user will be left at the IDP index.html page.
--
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
11 years, 8 months
[JBoss JIRA] (SECURITY-815) NegotiationAuthenticator loses post data
by Derek Horton (JIRA)
[ https://issues.jboss.org/browse/SECURITY-815?page=com.atlassian.jira.plug... ]
Derek Horton updated SECURITY-815:
----------------------------------
Git Pull Request: https://github.com/wildfly/jboss-negotiation/pull/3
> NegotiationAuthenticator loses post data
> ----------------------------------------
>
> Key: SECURITY-815
> URL: https://issues.jboss.org/browse/SECURITY-815
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Affects Versions: Negotiation_2_2_5
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
>
> The NegotiationAuthenticator loses post data.
> A customer is attempting to use Negotiation along with PicketLink at the IDP. This works fine as long as the SP is using HTTP-Redirect SAML binding.
> If the SP is using HTTP-Redirect, then this issue is avoided as the SAMLRequest is passed along through the redirects on the URL.
> If the HTTP-POST binding is used, then the NegotiationAuthenticator will lose the SAMLRequest post parameter. This means that after a user is successfully authenticated, the IDP will not know where to redirect the user to. As a result, the user will be left at the IDP index.html page.
--
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
11 years, 8 months
[JBoss JIRA] (SECURITY-815) NegotiationAuthenticator loses post data
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/SECURITY-815?page=com.atlassian.jira.plug... ]
RH Bugzilla Integration updated SECURITY-815:
---------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1030053
> NegotiationAuthenticator loses post data
> ----------------------------------------
>
> Key: SECURITY-815
> URL: https://issues.jboss.org/browse/SECURITY-815
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Affects Versions: Negotiation_2_2_5
> Reporter: Derek Horton
> Assignee: Darran Lofthouse
>
> The NegotiationAuthenticator loses post data.
> A customer is attempting to use Negotiation along with PicketLink at the IDP. This works fine as long as the SP is using HTTP-Redirect SAML binding.
> If the SP is using HTTP-Redirect, then this issue is avoided as the SAMLRequest is passed along through the redirects on the URL.
> If the HTTP-POST binding is used, then the NegotiationAuthenticator will lose the SAMLRequest post parameter. This means that after a user is successfully authenticated, the IDP will not know where to redirect the user to. As a result, the user will be left at the IDP index.html page.
--
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
11 years, 8 months
[JBoss JIRA] (SECURITY-815) NegotiationAuthenticator loses post data
by Derek Horton (JIRA)
Derek Horton created SECURITY-815:
-------------------------------------
Summary: NegotiationAuthenticator loses post data
Key: SECURITY-815
URL: https://issues.jboss.org/browse/SECURITY-815
Project: PicketBox
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Negotiation
Affects Versions: Negotiation_2_2_5
Reporter: Derek Horton
Assignee: Darran Lofthouse
The NegotiationAuthenticator loses post data.
A customer is attempting to use Negotiation along with PicketLink at the IDP. This works fine as long as the SP is using HTTP-Redirect SAML binding.
If the SP is using HTTP-Redirect, then this issue is avoided as the SAMLRequest is passed along through the redirects on the URL.
If the HTTP-POST binding is used, then the NegotiationAuthenticator will lose the SAMLRequest post parameter. This means that after a user is successfully authenticated, the IDP will not know where to redirect the user to. As a result, the user will be left at the IDP index.html page.
--
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
11 years, 8 months