[JBoss JIRA] (ELY-304) Create mechanism package
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/ELY-304?page=com.atlassian.jira.plugin.sy... ]
David Lloyd commented on ELY-304:
---------------------------------
I'm thinking that the callback logic should also be in this centralized portion. The mechanism logic could create objects representing the various messages, which could be transported in a protocol-specific manner.
> Create mechanism package
> ------------------------
>
> Key: ELY-304
> URL: https://issues.jboss.org/browse/ELY-304
> Project: WildFly Elytron
> Issue Type: Enhancement
> Components: API / SPI, SASL
> Reporter: David Lloyd
>
> Create a package "org.wildfly.security.mechanism"; for each authentication mechanism that spans multiple mechanism types (HTTP, SASL, GSSAPI, etc.), move that mechanism's core logic to the mechanism package, and have each mechanism type delegate to that package for its core authentication logic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (DROOLS-932) kie-server POST fails with org.kie.server.api.marshalling.MarshallingException: Can't marshall input object:
by Edson Tirelli (JIRA)
[ https://issues.jboss.org/browse/DROOLS-932?page=com.atlassian.jira.plugin... ]
Edson Tirelli reassigned DROOLS-932:
------------------------------------
Assignee: Maciej Swiderski (was: Edson Tirelli)
> kie-server POST fails with org.kie.server.api.marshalling.MarshallingException: Can't marshall input object:
> -------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-932
> URL: https://issues.jboss.org/browse/DROOLS-932
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Environment: kie-server 6.3.0.FINAL with JBoss EAP 6.4.0 or Widfly 8.1.0.FINAL
> Reporter: Stefano Picozzi
> Assignee: Maciej Swiderski
> Priority: Blocker
>
> The GET and PUT APIs work OK, e.g. to GET KIE-SERVER details or to PUT a new container.
> However a POST to e.g. send some facts to test actual rule reasoning fails as per this log snippet:
> 07:24:27,998 INFO [org.kie.server.services.impl.KieServerImpl] (http-/0.0.0.0:8080-1) Container watch (for release id com.redhat.demos:weightwatchers:1.0) successfully started
> 07:24:45,028 ERROR [org.kie.server.services.impl.KieContainerCommandServiceImpl] (http-/0.0.0.0:8080-1) Error calling container 'watch': org.kie.server.api.marshalling.MarshallingException: Can't marshall input object: org.drools.core.runtime.impl.ExecutionResultImpl@3c402d4b
> at org.kie.server.api.marshalling.jaxb.JaxbMarshaller.marshall(JaxbMarshaller.java:187) [kie-server-api-6.3.0.Final.jar:6.3.0.Final]
> at org.kie.server.services.impl.KieContainerCommandServiceImpl.callContainer(KieContainerCommandServiceImpl.java:114) [kie-server-services-common-6.3.0.Final.jar:6.3.0.Final]
> at org.kie.server.remote.rest.drools.CommandResource.manageContainer(CommandResource.java:73) [kie-server-rest-drools-6.3.0.Final.jar:6.3.0.Final]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_65]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_65]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_65]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_65]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:168) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invokeOnTarget(ResourceMethod.java:269) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:227) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.ResourceMethod.invoke(ResourceMethod.java:216) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.getResponse(SynchronousDispatcher.java:541) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:523) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:125) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:208) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:55) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:50) [resteasy-jaxrs-2.3.10.Final-redhat-1.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.authenticator.SingleSignOn.invoke(SingleSignOn.java:400) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.7.Final-redhat-1.jar:7.5.7.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> Caused by: javax.xml.bind.MarshalException
> - with linked exception:
> [com.sun.istack.SAXException2: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.]
> at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:326) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.MarshallerImpl.marshal(MarshallerImpl.java:251) [jaxb-impl-2.2.11.jar:2.2.11]
> at javax.xml.bind.helpers.AbstractMarshallerImpl.marshal(AbstractMarshallerImpl.java:95) [jboss-jaxb-api_2.2_spec-1.0.4.Final-redhat-3.jar:1.0.4.Final-redhat-3]
> at org.kie.server.api.marshalling.jaxb.JaxbMarshaller.marshall(JaxbMarshaller.java:185) [kie-server-api-6.3.0.Final.jar:6.3.0.Final]
> ... 32 more
> Caused by: com.sun.istack.SAXException2: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:247) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.reportError(XMLSerializer.java:262) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:653) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:158) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:360) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:696) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ArrayBeanInfoImpl.serializeBody(ArrayBeanInfoImpl.java:142) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:696) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.property.SingleElementNodeProperty.serializeBody(SingleElementNodeProperty.java:158) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeBody(ClassBeanInfoImpl.java:360) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsSoleContent(XMLSerializer.java:593) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.ClassBeanInfoImpl.serializeRoot(ClassBeanInfoImpl.java:341) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsRoot(XMLSerializer.java:494) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.MarshallerImpl.write(MarshallerImpl.java:323) [jaxb-impl-2.2.11.jar:2.2.11]
> ... 35 more
> Caused by: javax.xml.bind.JAXBException: class org.drools.core.runtime.rule.impl.FlatQueryResults nor any of its super class is known to this context.
> at com.sun.xml.bind.v2.runtime.JAXBContextImpl.getBeanInfo(JAXBContextImpl.java:582) [jaxb-impl-2.2.11.jar:2.2.11]
> at com.sun.xml.bind.v2.runtime.XMLSerializer.childAsXsiType(XMLSerializer.java:648) [jaxb-impl-2.2.11.jar:2.2.11]
> ... 46 more
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (LOGMGR-122) Syslog handler is not generating correct timestamp format
by Ricardo Kagawa (JIRA)
Ricardo Kagawa created LOGMGR-122:
-------------------------------------
Summary: Syslog handler is not generating correct timestamp format
Key: LOGMGR-122
URL: https://issues.jboss.org/browse/LOGMGR-122
Project: JBoss Log Manager
Issue Type: Bug
Affects Versions: 2.0.0.Final
Environment: Wildfly 9.0.1.Final, Oracle JRE 1.8.0_11, CentOS 6
Reporter: Ricardo Kagawa
Assignee: James Perkins
The Syslog handler is outputting an extra zero before the month in the header timestamp for RFC5424, specifically for October.
Checking [Github|https://github.com/jboss-logging/jboss-logmanager/blob/master/src/...], I have noticed that the month number is tested for double digit before being offset, so a zero is added for October (month 9 for java.util.Calendar), then offset for proper display (month "10" for ISO8601), resulting in a three-digit month ("010").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-5447) Removing virtual server which has access log fails first time and succeeds the second time
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5447?page=com.atlassian.jira.plugin.... ]
Radim Hatlapatka updated WFLY-5447:
-----------------------------------
Description:
When having created virtual server with access-log and then trying to remove the viratual server directly, it fails with {quote}WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service jboss.undertow.server.default-server.testvs was depended upon by service jboss.undertow.server.default-server.testvs.access-log{quote}, still when trying to remove it second time, it is successfully removed. To reproduce see steps bellow containing also output. See mainly that it failed first time, still it succeeded the second time.
{noformat}
[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=testvs:add()
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=testvs/setting=access-log:add()
{"outcome" => "success"}
[standalone@localhost:9990 /] reload
[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=testvs:remove()
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service jboss.undertow.server.default-server.testvs was depended upon by service jboss.undertow.server.default-server.testvs.access-log",
"rolled-back" => true
}
[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=testvs:remove()
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
{noformat}
was:
When having created virtual server with access-log and then trying to remove the viratual server directly, it fails with {quote}WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service jboss.undertow.server.default-server.testvs was depended upon by service jboss.undertow.server.default-server.testvs.access-log{quote}, still when trying to remove it second time, it is successfully removed. To reproduce see steps bellow:
{noformat}
[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=testvs:add()
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=testvs/setting=access-log:add()
{"outcome" => "success"}
[standalone@localhost:9990 /] reload
[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=testvs:remove()
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service jboss.undertow.server.default-server.testvs was depended upon by service jboss.undertow.server.default-server.testvs.access-log",
"rolled-back" => true
}
[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=testvs:remove()
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
{noformat}
> Removing virtual server which has access log fails first time and succeeds the second time
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-5447
> URL: https://issues.jboss.org/browse/WFLY-5447
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Radim Hatlapatka
> Assignee: Stuart Douglas
> Priority: Minor
>
> When having created virtual server with access-log and then trying to remove the viratual server directly, it fails with {quote}WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service jboss.undertow.server.default-server.testvs was depended upon by service jboss.undertow.server.default-server.testvs.access-log{quote}, still when trying to remove it second time, it is successfully removed. To reproduce see steps bellow containing also output. See mainly that it failed first time, still it succeeded the second time.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=testvs:add()
> {"outcome" => "success"}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=testvs/setting=access-log:add()
> {"outcome" => "success"}
> [standalone@localhost:9990 /] reload
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=testvs:remove()
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
> Service jboss.undertow.server.default-server.testvs was depended upon by service jboss.undertow.server.default-server.testvs.access-log",
> "rolled-back" => true
> }
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=testvs:remove()
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (ELY-304) Create mechanism package
by David Lloyd (JIRA)
David Lloyd created ELY-304:
-------------------------------
Summary: Create mechanism package
Key: ELY-304
URL: https://issues.jboss.org/browse/ELY-304
Project: WildFly Elytron
Issue Type: Enhancement
Components: API / SPI, SASL
Reporter: David Lloyd
Create a package "org.wildfly.security.mechanism"; for each authentication mechanism that spans multiple mechanism types (HTTP, SASL, GSSAPI, etc.), move that mechanism's core logic to the mechanism package, and have each mechanism type delegate to that package for its core authentication logic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-5447) Removing virtual server which has access log fails first time and succeeds the second time
by Radim Hatlapatka (JIRA)
Radim Hatlapatka created WFLY-5447:
--------------------------------------
Summary: Removing virtual server which has access log fails first time and succeeds the second time
Key: WFLY-5447
URL: https://issues.jboss.org/browse/WFLY-5447
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Radim Hatlapatka
Assignee: Stuart Douglas
Priority: Minor
When having created virtual server with access-log and then trying to remove the viratual server directly, it fails with {quote}WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service jboss.undertow.server.default-server.testvs was depended upon by service jboss.undertow.server.default-server.testvs.access-log{quote}, still when trying to remove it second time, it is successfully removed. To reproduce see steps bellow:
{noformat}
[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=testvs:add()
{"outcome" => "success"}
[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=testvs/setting=access-log:add()
{"outcome" => "success"}
[standalone@localhost:9990 /] reload
[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=testvs:remove()
{
"outcome" => "failed",
"failure-description" => "WFLYCTL0171: Removing services has lead to unsatisfied dependencies:
Service jboss.undertow.server.default-server.testvs was depended upon by service jboss.undertow.server.default-server.testvs.access-log",
"rolled-back" => true
}
[standalone@localhost:9990 /] /subsystem=undertow/server=default-server/host=testvs:remove()
{
"outcome" => "success",
"response-headers" => {
"operation-requires-reload" => true,
"process-state" => "reload-required"
}
}
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months
[JBoss JIRA] (WFLY-5446) Support connection to older messaging servers
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-5446?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil updated WFLY-5446:
------------------------------
Priority: Critical (was: Major)
> Support connection to older messaging servers
> ---------------------------------------------
>
> Key: WFLY-5446
> URL: https://issues.jboss.org/browse/WFLY-5446
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 10.0.0.CR2
> Reporter: Jeff Mesnil
> Assignee: Jeff Mesnil
> Priority: Critical
> Fix For: 10.0.0.Final
>
>
> WildFly 10 comes with new Artemis messaging broker.
> At the moment, it is not possible to connect to an older WildFly server (WFLY 8 & 9) that were using HornetQ messaging broker.
> It should be possible for a WildFly10 application to connect to these older brokers (esp. during migration and system upgrade).
> This should work both for JMS client and MDB deployed on WildFly 10 by using a pooled-connection-factory pointing to the old servers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 6 months