[JBoss JIRA] (WFLY-7016) Wildfly 10.1 IllegalStateException when starting applications when getting a session in a listener
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7016?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7016:
-----------------------------------
Summary: Wildfly 10.1 IllegalStateException when starting applications when getting a session in a listener (was: Wildfly 10.1 now crashes when starting applications when getting a session in a listener )
> Wildfly 10.1 IllegalStateException when starting applications when getting a session in a listener
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-7016
> URL: https://issues.jboss.org/browse/WFLY-7016
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Reporter: Matthew Casperson
> Assignee: Stuart Douglas
>
> We have the following code in a ServletRequestListener:
> {code}
> final HttpSession httpSession = httpRequest.getSession(false);
> {code}
> This code is the line:
> {code}
> [Server:main-server] at au.com.agic.settings.listener.SessionInvalidatorListener.clearSession(SessionInvalidatorListener.java:94)
> {code}
> in the stack trace below.
> We have been running applications with this listener in WildFly 10 for months without any issues, but when we migrated to WildFly 10.1, Infinispan started throwing exceptions when opening the app for the first time. The exception doesn't always happen, but often enough to make WildFly 10.1 unusable.
> The configuration was copied directly from WildFly 10 to WildFly 10.1, so there are no configuration changes between the two versions.
> {code}
> [Server:main-server] 2016-08-26 15:03:10+1000 ERROR [[io.undertow.request]] [[default task-32]] UT005023: Exception handling request to /app/retrieve_quote.jsp: java.lang.IllegalStateException: Transaction TransactionImple < ac, BasicAction: 0:ffff0a1617d4:6cdfa442:57bfb3cd:31b status: ActionStatus.COMMITTED > is not in a valid state to be invoking cache operations on.
> [Server:main-server] at org.infinispan.interceptors.TxInterceptor.enlist(TxInterceptor.java:395)
> [Server:main-server] at org.infinispan.interceptors.TxInterceptor.enlistIfNeeded(TxInterceptor.java:351)
> [Server:main-server] at org.infinispan.interceptors.TxInterceptor.enlistReadAndInvokeNext(TxInterceptor.java:345)
> [Server:main-server] at org.infinispan.interceptors.TxInterceptor.visitGetKeyValueCommand(TxInterceptor.java:331)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [Server:main-server] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] at org.infinispan.statetransfer.StateTransferInterceptor.visitReadCommand(StateTransferInterceptor.java:177)
> [Server:main-server] at org.infinispan.statetransfer.StateTransferInterceptor.visitGetKeyValueCommand(StateTransferInterceptor.java:154)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:114)
> [Server:main-server] at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:83)
> [Server:main-server] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:99)
> [Server:main-server] at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:113)
> [Server:main-server] at org.infinispan.commands.AbstractVisitor.visitGetKeyValueCommand(AbstractVisitor.java:85)
> [Server:main-server] at org.infinispan.commands.read.GetKeyValueCommand.acceptVisitor(GetKeyValueCommand.java:43)
> [Server:main-server] at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:335)
> [Server:main-server] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:411)
> [Server:main-server] at org.infinispan.cache.impl.CacheImpl.get(CacheImpl.java:403)
> [Server:main-server] at org.infinispan.cache.impl.AbstractDelegatingCache.get(AbstractDelegatingCache.java:286)
> [Server:main-server] at org.wildfly.clustering.server.registry.CacheRegistry.getEntry(CacheRegistry.java:128)
> [Server:main-server] at org.wildfly.clustering.web.infinispan.session.InfinispanRouteLocator.locate(InfinispanRouteLocator.java:58)
> [Server:main-server] at org.wildfly.clustering.web.undertow.session.DistributableSessionIdentifierCodec.encode(DistributableSessionIdentifierCodec.java:48)
> [Server:main-server] at org.wildfly.extension.undertow.session.CodecSessionConfig.findSessionId(CodecSessionConfig.java:60)
> [Server:main-server] at io.undertow.servlet.spec.ServletContextImpl$ServletContextSessionConfig.findSessionId(ServletContextImpl.java:1084)
> [Server:main-server] at io.undertow.servlet.spec.ServletContextImpl.getSession(ServletContextImpl.java:778)
> [Server:main-server] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:370)
> [Server:main-server] at io.undertow.servlet.spec.HttpServletRequestImpl.getSession(HttpServletRequestImpl.java:375)
> [Server:main-server] at au.com.agic.settings.listener.SessionInvalidatorListener.clearSession(SessionInvalidatorListener.java:94)
> [Server:main-server] at au.com.agic.settings.listener.SessionInvalidatorListener.requestInitialized(SessionInvalidatorListener.java:52)
> [Server:main-server] at io.undertow.servlet.core.ApplicationListeners.requestInitialized(ApplicationListeners.java:246)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:291)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> [Server:main-server] at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> [Server:main-server] at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.api.LegacyThreadSetupActionWrapper$1.call(LegacyThreadSetupActionWrapper.java:44)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> [Server:main-server] at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> [Server:main-server] at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> [Server:main-server] at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFCORE-1726) CLI support for response attachments
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1726?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1726:
----------------------------------------------
Implementation went well. Works in all workflow (nominal, batch, if, try).
Branch is: https://github.com/jfdenise/wildfly-core/tree/streams-read-content
The command is attachment {display|save} --operation=<operation> [--file=<path to file>]
The read-content will have to be updated to contain somewhere the uuid.
> CLI support for response attachments
> ------------------------------------
>
> Key: WFCORE-1726
> URL: https://issues.jboss.org/browse/WFCORE-1726
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> CLI doesn't support the streams attached to a response. Incremental deployment support offers today the ability to read the content of a deployment. It would be interesting to operate it from the CLI. Some resource (such as the log file) expose some attributes as stream.
> The following operations are returning streams:
> /subsystem=logging/log-file=server.log:read-attribute(name=stream)
> /subsystem=logging/log-file=server.log:read-resource(include-runtime)
> /deployment=toto:read-content(path=index.html)
> As we can see, streams can be located in attributes, as operation response, inside a resource.
> The CLI offers 2 way to approach the problem:
> 1) Extend the Low level operation support with a way to save/display attached streams. This would require some XML configuration and possibly UI workflow to prompt user for the right action. Making from stream to file path would be not ideal and far from being user friendly. The good side is tha tit would work in any case (batch, non batch). The XML configuration can be a bit complex and prompting user is not an ideal workflow.
> 2) Define a new high level command that would cope with any operation.
> Such command would look like:
> attachment save --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream) --file=/my/local/path/to/file
> attachment display --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream)
> - No risk to impact existing scripts. This is a new feature, so people would have to update their scripts to add the command.
> - The challenge is located in mapping a Stream to a file name. The user provides the name he wants. Furthermore, in interactive mode, the user can use completion to complete this target file.
> - No more prompting, the user knows ahead of time what he wants to do.
> - Problem is that batch mode doesn't re-dispatch each step response to each input command. So some logic should be needed to properly handle streams in batch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFCORE-1726) CLI support for response attachments
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1726?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise edited comment on WFCORE-1726 at 8/26/16 12:03 PM:
------------------------------------------------------------------------
Implementation went well. Works in all workflow (nominal, batch, if, try).
Branch is: https://github.com/jfdenise/wildfly-core/tree/streams-read-content
The command is attachment [display|save] --operation=<operation> [--file=<path to file>]
The read-content will have to be updated to contain somewhere the uuid.
was (Author: jdenise):
Implementation went well. Works in all workflow (nominal, batch, if, try).
Branch is: https://github.com/jfdenise/wildfly-core/tree/streams-read-content
The command is attachment {display|save} --operation=<operation> [--file=<path to file>]
The read-content will have to be updated to contain somewhere the uuid.
> CLI support for response attachments
> ------------------------------------
>
> Key: WFCORE-1726
> URL: https://issues.jboss.org/browse/WFCORE-1726
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
>
> CLI doesn't support the streams attached to a response. Incremental deployment support offers today the ability to read the content of a deployment. It would be interesting to operate it from the CLI. Some resource (such as the log file) expose some attributes as stream.
> The following operations are returning streams:
> /subsystem=logging/log-file=server.log:read-attribute(name=stream)
> /subsystem=logging/log-file=server.log:read-resource(include-runtime)
> /deployment=toto:read-content(path=index.html)
> As we can see, streams can be located in attributes, as operation response, inside a resource.
> The CLI offers 2 way to approach the problem:
> 1) Extend the Low level operation support with a way to save/display attached streams. This would require some XML configuration and possibly UI workflow to prompt user for the right action. Making from stream to file path would be not ideal and far from being user friendly. The good side is tha tit would work in any case (batch, non batch). The XML configuration can be a bit complex and prompting user is not an ideal workflow.
> 2) Define a new high level command that would cope with any operation.
> Such command would look like:
> attachment save --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream) --file=/my/local/path/to/file
> attachment display --operation=/subsystem=logging/log-file=server.log:read-attribute(name=stream)
> - No risk to impact existing scripts. This is a new feature, so people would have to update their scripts to add the command.
> - The challenge is located in mapping a Stream to a file name. The user provides the name he wants. Furthermore, in interactive mode, the user can use completion to complete this target file.
> - No more prompting, the user knows ahead of time what he wants to do.
> - Problem is that batch mode doesn't re-dispatch each step response to each input command. So some logic should be needed to properly handle streams in batch.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFLY-5892) JGroups throws UnknownHostException on processing IPv6 zone interface id with a subinterface
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-5892?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-5892:
-------------------------------------------
I did a bit of investigating on this issue. The root cause of the problem seems to be with the JDK 8 version of the JDK on Solaris 11 (sparc) and the way InetAddress.getByName() works (or in this case, doesn't work) with virtual interfaces (virtual sub interfaces of a physical interface). Works fine for previous versions of the JDK on Solaris.
In a nutshell, during EAP startup, a socket binding for JGroups is created using an address associated with a virtual interface, and its address is of the form:
{noformat}
2620:52:0:105f:221:28ff:feb3:20f2%net0:7
{noformat}
Note the virtual interface name net0:7 used as a scope id.
Later on, when the JGroups stack is initialised, JGroups Configurator calls InetAddress.getByName() on that string. The JDK 8 version of the JDK can not handle this string correctly and returns an UnknownHostException. Previous versions of the JDK ( < 8) do handle it successfully.
See JBEAP-2509 comments.
> JGroups throws UnknownHostException on processing IPv6 zone interface id with a subinterface
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-5892
> URL: https://issues.jboss.org/browse/WFLY-5892
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Environment: Solaris 11 Sparc JDK8, IPv6
> Reporter: Michal Karm Babacek
> Assignee: Bela Ban
> Priority: Critical
> Attachments: tcp.xml
>
>
> JGroups pick up IPv6 zone id index and it fails at translating it into an interface name:
> h3. Address
> * address used {{2620:52:0:105f:0:0:ffff:188%net0:2}}
> * {{Caused by: java.net.UnknownHostException: no such interface net0:2}}
> h3. Configuration
> {code}
> <interfaces>
> <interface name="management">
> <inet-address value="2620:52:0:105f::ffff:188"/>
> </interface>
> <interface name="public">
> <inet-address value="2620:52:0:105f::ffff:188"/>
> </interface>
> </interfaces>
> <socket-binding-group name="standard-sockets" default-interface="public" port-offset="${jboss.socket.binding.port-offset:0}">
> <socket-binding name="management-http" interface="management" port="${jboss.management.http.port:9990}"/>
> <socket-binding name="management-https" interface="management" port="${jboss.management.https.port:9993}"/>
> <socket-binding name="ajp" port="${jboss.ajp.port:8009}"/>
> <socket-binding name="http" port="${jboss.http.port:8080}"/>
> <socket-binding name="https" port="${jboss.https.port:8443}"/>
> <socket-binding name="jgroups-mping" port="0" multicast-address="ff02::12" multicast-port="45700"/>
> <socket-binding name="jgroups-tcp" port="7600"/>
> <socket-binding name="jgroups-tcp-fd" port="57600"/>
> <socket-binding name="jgroups-udp" port="55200" multicast-address="ff02::12" multicast-port="45688"/>
> <socket-binding name="jgroups-udp-fd" port="54200"/>
> <socket-binding name="modcluster" port="0" multicast-address="ff02::a" multicast-port="32983"/>
> <socket-binding name="txn-recovery-environment" port="4712"/>
> <socket-binding name="txn-status-manager" port="4713"/>
> <outbound-socket-binding name="mail-smtp">
> <remote-destination host="localhost" port="25"/>
> </outbound-socket-binding>
> </socket-binding-group>
> {code}
> h3. Exception
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-5) MSC000001: Failed to start service jboss.jgroups.channel.ee: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> at org.wildfly.clustering.jgroups.spi.service.ChannelBuilder.start(ChannelBuilder.java:80)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:640)
> at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:98)
> at org.wildfly.clustering.jgroups.spi.service.ChannelBuilder.start(ChannelBuilder.java:78)
> ... 5 more
> Caused by: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1154)
> at org.jgroups.stack.Configurator.createLayer(Configurator.java:445)
> at org.jgroups.stack.Configurator.createProtocols(Configurator.java:398)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:90)
> at org.jgroups.stack.Configurator.setupProtocolStack(Configurator.java:57)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:477)
> at org.jgroups.JChannel.init(JChannel.java:853)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jboss.as.clustering.jgroups.JChannelFactory$1.run(JChannelFactory.java:95)
> at org.jboss.as.clustering.jgroups.JChannelFactory$1.run(JChannelFactory.java:92)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> ... 7 more
> Caused by: java.lang.Exception: Conversion of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 failed
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:84)
> at org.jgroups.stack.Configurator.resolveAndAssignField(Configurator.java:1148)
> ... 17 more
> Caused by: java.net.UnknownHostException: no such interface net0:2
> at java.net.Inet6Address.initstr(Inet6Address.java:487)
> at java.net.Inet6Address.<init>(Inet6Address.java:408)
> at java.net.InetAddress.getAllByName(InetAddress.java:1181)
> at java.net.InetAddress.getAllByName(InetAddress.java:1126)
> at java.net.InetAddress.getByName(InetAddress.java:1076)
> at org.jgroups.conf.PropertyConverters$Default.convert(PropertyConverters.java:288)
> at org.jgroups.conf.PropertyHelper.getConvertedValue(PropertyHelper.java:81)
> ... 18 more
> ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "jgroups"),
> ("channel" => "ee")
> ]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.jgroups.channel.ee" => "org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> Caused by: java.security.PrivilegedActionException: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> Caused by: java.lang.Exception: Property assignment of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 and converted to null could not be assigned
> Caused by: java.lang.Exception: Conversion of bind_addr in UDP with original property value 2620:52:0:105f:0:0:ffff:188%net0:2 failed
> Caused by: java.net.UnknownHostException: no such interface net0:2"}}
> {code}
> h3. Interfaces on the Solaris 11 box
> See my undermentioned example:
> {code}
> [mbabacek@dev33 ~]$ groovy https://gist.githubusercontent.com/Karm/ec21b42b59f8889f976f/raw/951f01c6...
> Iface Display name: net4
> Iface Name: net4
> Iface Display name: net0
> Iface Name: net0
> Subiface Display name: net0:7
> Subiface Name: net0:7
> Subiface Display name: net0:6
> Subiface Name: net0:6
> Subiface Display name: net0:5
> Subiface Name: net0:5
> Subiface Display name: net0:4
> Subiface Name: net0:4
> Subiface Display name: net0:3
> Subiface Name: net0:3
> Subiface Display name: net0:2
> Subiface Name: net0:2
> Subiface Display name: net0:1
> Subiface Name: net0:1
> Iface Display name: lo0
> Iface Name: lo0
> {code}
> WDYT? Why should JGroups even try to do that?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFCORE-1740) Not displaying all possibilities for FS completion breaks from the command
by Tomas Hofman (JIRA)
Tomas Hofman created WFCORE-1740:
------------------------------------
Summary: Not displaying all possibilities for FS completion breaks from the command
Key: WFCORE-1740
URL: https://issues.jboss.org/browse/WFCORE-1740
Project: WildFly Core
Issue Type: Bug
Components: CLI
Affects Versions: 3.0.0.Alpha4
Reporter: Tomas Hofman
Assignee: Alexey Loubyansky
Terminal gets cleared in case user select not to display all possibilities during FS completion.
*my use-case*
{noformat}
[disconnected /] module add --name=org.wildfly.extension.blocker-test
--dependencies=org.jboss.staxmapper,org.jboss.as.controller,org.jboss.msc
--resources=~/help/test-extension.jar --module-root-dir=../../../<TAB>
Display all 103 possibilities? (y or n)<n>
[disconnected /]
{noformat}
*reproduce*
_actual_
{noformat}
[disconnected /] patch apply /etc/<TAB>
Display all 299 possibilities? (y or n)<n>
[disconnected /]
{noformat}
_expected_
{noformat}
[disconnected /] patch apply /etc/<TAB>
Display all 299 possibilities? (y or n)<n>
[disconnected /] patch apply /etc/
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (DROOLS-1261) Trait's mixins don't inherit methods from parent traits
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-1261:
-----------------------------------
Summary: Trait's mixins don't inherit methods from parent traits
Key: DROOLS-1261
URL: https://issues.jboss.org/browse/DROOLS-1261
Project: Drools
Issue Type: Bug
Components: core engine
Reporter: Mario Fusco
Assignee: Mario Fusco
When a trait mixin is created it doesn't take count of the trait class hierarchy and then the methods declared in a trait superinterface are not implemented in the resulting mixin class.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (DROOLS-805) JobResult causes exception creating JAXB context
by Marco Rietveld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-805?page=com.atlassian.jira.plugin... ]
Marco Rietveld reassigned DROOLS-805:
-------------------------------------
Assignee: Marco Rietveld (was: Mario Fusco)
> JobResult causes exception creating JAXB context
> ------------------------------------------------
>
> Key: DROOLS-805
> URL: https://issues.jboss.org/browse/DROOLS-805
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Reporter: Carl Miller
> Assignee: Marco Rietveld
>
> In trying to use the following snippet of code:
> JAXBContext jc = JAXBContext.newInstance( JobResult.class );
> to transform a json string returned by a /jobs/jobId REST call into a JobResult, I kept getting an error stating setLastModified( Long ) was not a method in that class. Upon further examination, the getter in the JobResult.java class returns a "Long" yet the setter accepts a "long" (subtle difference). Made the change to setLastModified to accept a Long and my JaxBContext issue went away.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (DROOLS-960) Create a kie-core-jaxb module for easier serialization
by Marco Rietveld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-960?page=com.atlassian.jira.plugin... ]
Marco Rietveld resolved DROOLS-960.
-----------------------------------
Resolution: Out of Date
> Create a kie-core-jaxb module for easier serialization
> ------------------------------------------------------
>
> Key: DROOLS-960
> URL: https://issues.jboss.org/browse/DROOLS-960
> Project: Drools
> Issue Type: Bug
> Components: core engine, kie server
> Affects Versions: 6.3.0.Final
> Reporter: Marco Rietveld
> Assignee: Mario Fusco
> Priority: Critical
> Fix For: 7.0.0.Final
>
> Attachments: CoreObject.java, ImplObject.java, JaxbInheritanceTest.java
>
>
> At the moment, the cost of supporting serialization of our command pattern is way too expensive.
> The hacked-together solution that I'm doing is basically taking {{Command}} implementation classes in the core engines, and then
> 1. converting those classes to an xsd schema
> 2. generating new classes from the xsd schema
> However, this means that I'm constantly wrestling with the core command implementations in order to make sure that they serialize correctly and convert nicely to an xsd schema.
> Instead, we should have a {{kie-core-jaxb}} module that contains 2 things:
> 1. The utilties (Java JAXB Adapters) that are used in multiple modules ({{drools-core}}, {{jbpm-human-task-core}}, {{kie-remote-jaxb}})
> 2. The Core command serialization implementations.
> See the attached java files for an example of how we can use inheritance to do what we want.
> In short:
> 1. The {{CoreObject}} is the Command DTO class, that would be in {{kie-core-jaxb}}
> 2. The {{ImplObject}} is the Command implementation, that would be in a {{drools-core}}, {{jbpm-human-task-core}} or other core module. This class would extend the {{CoreObject}} class, but also make sure to use the same {{@XmlRootElement}} name value.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months
[JBoss JIRA] (WFCORE-1738) Hint when versions are out-of-date pending restart
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1738?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1738:
-------------------------------------
Component/s: Patching
> Hint when versions are out-of-date pending restart
> --------------------------------------------------
>
> Key: WFCORE-1738
> URL: https://issues.jboss.org/browse/WFCORE-1738
> Project: WildFly Core
> Issue Type: Feature Request
> Components: CLI, Patching
> Reporter: Marek Kopecký
> Assignee: Alexey Loubyansky
> Priority: Optional
>
> I have a minor usability suggestion. It's merely informational but I think helpful.
> When I was in the CLI tool to apply a version update patch (7.0.0 -> 7.0.1), I wasn't yet aware that I needed to restart the server for it to take effect. So when I afterward typed "version" to confirm the expected version bumps... well, they did not. I was specifically looking to confirm a change in both fields "JBoss AS release" and "JBoss AS product". With that said, it would be useful to add something to the output indicating the information being displayed will no longer be true.
> Illustrated example. Notice the asterisks:
> {code}
> JBOSS_HOME: C:\dev\jboss-eap-7
> JBoss AS release: 2.1.2.Final-redhat-1 "Kenny"(*)
> JBoss AS product: JBoss EAP 7.0.0.GA(*)
> JAVA_HOME: c:\java\jdk1.8.0_45
> java.version: 1.8.0_45
> java.vm.vendor: Oracle Corporation
> java.vm.version: 25.45-b02
> os.name: Windows 7
> os.version: 6.1
> (*) Versions subject to change after patch takes effect at restart.
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 2 months