[JBoss JIRA] (WFLY-2344) undertow claims already registered
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2344?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-2344:
-----------------------------------
In any case this was fixed long ago.
> undertow claims already registered
> ----------------------------------
>
> Key: WFLY-2344
> URL: https://issues.jboss.org/browse/WFLY-2344
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Reporter: miguel deanda
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.CR1
>
>
> I've downloaded wildfly beta, attempted to add a vhost using the undertow configuration (can't find documentation btw) but when it starts, it says:
> org.jboss.msc.service.DuplicateServiceException: Service jboss.web.common.host./ is already registered
> I originally posted the question here:
> https://community.jboss.org/message/842352
> The relevant config section (standalone.xml) is the following:
> <subsystem xmlns="urn:jboss:domain:undertow:1.0">
> <buffer-caches>
> <buffer-cache name="default" buffer-size="1024" buffers-per-region="1024" max-regions="10"/>
> </buffer-caches>
> <server name="default-server">
> <http-listener name="default" socket-binding="http" max-post-size="10485760"/>
> <host name="default-host" alias="localhost">
> <location name="/" handler="welcome-content"/>
> </host>
> <host name="other-host" alias="www.mysite.com" default-web-module="something.war">
> <location name="/" handler="welcome-content">
> <filter-ref name="connection-limit"/>
> </location>
> </host>
> </server>
> <servlet-container name="default" default-buffer-cache="default" stack-trace-on-error="local-only">
> <jsp-config/>
> <persistent-sessions path="persistent-web-sessions" relative-to="jboss.server.data.dir"/>
> </servlet-container>
> <handlers>
> <file name="welcome-content" path="${jboss.home.dir}/welcome-content" directory-listing="true"/>
> </handlers>
> </subsystem>
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (WFLY-3811) Infinispan cache module override is ignored
by Enrique González Martínez (JIRA)
[ https://issues.jboss.org/browse/WFLY-3811?page=com.atlassian.jira.plugin.... ]
Enrique González Martínez reassigned WFLY-3811:
-----------------------------------------------
Assignee: Enrique González Martínez (was: Paul Ferraro)
> Infinispan cache module override is ignored
> -------------------------------------------
>
> Key: WFLY-3811
> URL: https://issues.jboss.org/browse/WFLY-3811
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.1.0.Final
> Reporter: Rich DiCroce
> Assignee: Enrique González Martínez
>
> I was trying to set up a cache for a Registry (part of the public clustering API) and got an ugly exception. After mucking with it for a while, I've determined that this configuration works:
> {code:xml}
> <cache-container name="test" module="org.wildfly.clustering.server">
> <transport lock-timeout="60000"/>
> <replicated-cache name="SONGv1-GP-names" batching="true" mode="SYNC">
> <locking isolation="REPEATABLE_READ"/>
> </replicated-cache>
> </cache-container>
> {code}
> and so does this configuration:
> {code:xml}
> <cache-container name="test">
> <transport lock-timeout="60000"/>
> <replicated-cache name="SONGv1-GP-names" batching="true" mode="SYNC" module="org.wildfly.clustering.server">
> <locking isolation="REPEATABLE_READ"/>
> </replicated-cache>
> </cache-container>
> {code}
> but this configuration does not:
> {code:xml}
> <cache-container name="test" module="org.infinispan.query">
> <transport lock-timeout="60000"/>
> <replicated-cache name="SONGv1-GP-names" batching="true" module="org.wildfly.clustering.server" mode="SYNC">
> <locking isolation="REPEATABLE_READ"/>
> </replicated-cache>
> </cache-container>
> {code}
> The last one causes exceptions like this:
> {code}
> 05:19:15,300 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-1) ISPN000136: Execution error: org.infinispan.commons.CacheException: java.lang.RuntimeException: Failure to marshal argument(s)
> at org.infinispan.commons.util.Util.rewrapAsCacheException(Util.java:581) [infinispan-commons-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:141) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:524) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:281) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.distribution.TxDistributionInterceptor.prepareOnAffectedNodes(TxDistributionInterceptor.java:219) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.distribution.TxDistributionInterceptor.visitPrepareCommand(TxDistributionInterceptor.java:203) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:96) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:78) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:263) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:194) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:94) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:110) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:73) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:66) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:124) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:333) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.CacheImpl.endBatch(CacheImpl.java:777) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.jboss.as.clustering.infinispan.invoker.BatchCacheInvoker.invoke(BatchCacheInvoker.java:53)
> at org.wildfly.clustering.server.registry.RegistryFactoryService.getLocalEntry(RegistryFactoryService.java:170)
> at org.wildfly.clustering.server.registry.RegistryFactoryService.createRegistry(RegistryFactoryService.java:101)
> at com.sgi.song.gp.cluster.ClusterObjectsProducer.init(ClusterObjectsProducer.java:123) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_20]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_20]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_20]
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_20]
> at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:89) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.postConstruct(DefaultLifecycleCallbackInvoker.java:72) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.injection.producer.BasicInjectionTarget.postConstruct(BasicInjectionTarget.java:95) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.injection.producer.BeanInjectionTarget.postConstruct(BeanInjectionTarget.java:63) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:153) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:733) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.injection.producer.AbstractMemberProducer.getReceiver(AbstractMemberProducer.java:128) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:148) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:183) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:69) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:733) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:789) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90) [weld-core-impl-2.1.2.Final.jar:2014-01-09 09:23]
> at org.apache.deltaspike.core.api.provider.BeanProvider.injectFields(BeanProvider.java:408) [deltaspike-core-api-0.7.jar:0.7]
> at com.sgi.song.gp.util.command.TestCommandService.executeCommand(TestCommandService.java:20) [classes:]
> at com.sgi.song.gp.util.command.TestCommandService$Proxy$_$$_WeldClientProxy.executeCommand(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_20]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_20]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_20]
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_20]
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:137) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:296) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:250) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:237) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:356) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:179) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:220) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.8.Final.jar:]
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.8.Final.jar:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:113) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:25) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:240) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:227) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:73) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:146) [undertow-servlet-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:177) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:727) [undertow-core-1.0.15.Final.jar:1.0.15.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> Caused by: java.lang.RuntimeException: Failure to marshal argument(s)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.marshallCall(CommandAwareRpcDispatcher.java:333) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processCalls(CommandAwareRpcDispatcher.java:407) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommands(CommandAwareRpcDispatcher.java:132) [infinispan-core-6.0.2.Final.jar:6.0.2.Final]
> ... 126 more
> Caused by: org.infinispan.commons.marshall.NotSerializableException: org.wildfly.clustering.server.group.AddressableNode
> Caused by: an exception which occurred:
> in object org.wildfly.clustering.server.group.AddressableNode@7b3f1d4e
> in object org.infinispan.commands.write.PutKeyValueCommand@bc035005
> in object org.infinispan.commands.tx.PrepareCommand@7b3f1d52
> {code}
> Note that this only occurs when Infinispan tries to serialize the cache entries for transmission to other nodes, so you must have multiple WildFly instances running in a cluster. The issue does not occur on a single WildFly instance.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (WFBUILD-8) Add copy-artifacts to server provisioning
by Eduardo Martins (JIRA)
Eduardo Martins created WFBUILD-8:
-------------------------------------
Summary: Add copy-artifacts to server provisioning
Key: WFBUILD-8
URL: https://issues.jboss.org/browse/WFBUILD-8
Project: WildFly Build Tools
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Reporter: Eduardo Martins
Assignee: Eduardo Martins
As a first solution for WFBUILD-3, by adding feature-pack's copy-artifacts to server provisioning, such feature may be used to copy a deployment from maven repository into the server's deployment dir.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.... ]
Radoslav Husar reassigned JGRP-1878:
------------------------------------
Assignee: Radoslav Husar (was: Bela Ban)
> Multicast discovery does not work on JDK8
> -----------------------------------------
>
> Key: JGRP-1878
> URL: https://issues.jboss.org/browse/JGRP-1878
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.2.12, 3.5
> Environment: OpenJDK8, OracleJDK8u40
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Blocker
> Fix For: 3.2.14, 3.6
>
> Attachments: mcast.java
>
>
> Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8.
> Steps to reproduce with draw, switch to JDK8:
> {noformat}
> export IP_ADDR=127.0.0.1
> ./draw.sh
> export IP_ADDR=192.168.1.10
> ./draw.sh
> {noformat}
> Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug..
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1878:
---------------------------
Attachment: mcast.java
> Multicast discovery does not work on JDK8
> -----------------------------------------
>
> Key: JGRP-1878
> URL: https://issues.jboss.org/browse/JGRP-1878
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.2.12, 3.5
> Environment: OpenJDK8, OracleJDK8u40
> Reporter: Radoslav Husar
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 3.2.14, 3.6
>
> Attachments: mcast.java
>
>
> Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8.
> Steps to reproduce with draw, switch to JDK8:
> {noformat}
> export IP_ADDR=127.0.0.1
> ./draw.sh
> export IP_ADDR=192.168.1.10
> ./draw.sh
> {noformat}
> Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug..
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (JGRP-1878) Multicast discovery does not work on JDK8
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/JGRP-1878?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on JGRP-1878:
--------------------------------------
Looks like this is the core of the problem, just adding {code}<UDP receive_on_all_interfaces="true">{code} does the job for my tests.
> Multicast discovery does not work on JDK8
> -----------------------------------------
>
> Key: JGRP-1878
> URL: https://issues.jboss.org/browse/JGRP-1878
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.2.12, 3.5
> Environment: OpenJDK8, OracleJDK8u40
> Reporter: Radoslav Husar
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 3.2.14, 3.6
>
>
> Multicast discovery does not work on JDK8 when using different bind IP addresses. This blocks EAP certification on JDK8.
> Steps to reproduce with draw, switch to JDK8:
> {noformat}
> export IP_ADDR=127.0.0.1
> ./draw.sh
> export IP_ADDR=192.168.1.10
> ./draw.sh
> {noformat}
> Everything works when binding to the same IP address or using JDK 6 or 7. Possibly a JDK8 bug..
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (WFLY-1402) Too Many Dependencies
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1402?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1402:
-----------------------------------------------
Jay SenSharma <jsenshar(a)redhat.com> changed the Status of [bug 1138111|https://bugzilla.redhat.com/show_bug.cgi?id=1138111] from NEW to POST
> Too Many Dependencies
> ---------------------
>
> Key: WFLY-1402
> URL: https://issues.jboss.org/browse/WFLY-1402
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Alpha1
> Environment: W7 64 bit
> Reporter: Michael McGovern
> Assignee: Stuart Douglas
> Fix For: 8.0.0.Alpha2
>
>
> Large app ~ 1000 SLSB gets
> Caused by: java.lang.IllegalArgumentException: Too many dependencies specified (max is 16383)
> at org.jboss.msc.service.ServiceBuilderImpl.doAddDependency(ServiceBuilderImpl.java:216) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at org.jboss.msc.service.ServiceBuilderImpl.addDependenciesNoCheck(ServiceBuilderImpl.java:158) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at org.jboss.msc.service.ServiceBuilderImpl.addDependencies(ServiceBuilderImpl.java:152) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at org.jboss.msc.service.ServiceBuilderImpl.addDependencies(ServiceBuilderImpl.java:142) [jboss-msc-1.1.2.Final.jar:1.1.2.Final]
> at org.jboss.as.naming.deployment.JndiNamingDependencyProcessor.deploy(JndiNamingDependencyProcessor.java:59)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Alpha1.jar:8.0.0.Alpha1]
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (WFBUILD-4) Add the ability to override the specific version of Maven artifacts
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFBUILD-4?page=com.atlassian.jira.plugin.... ]
Eduardo Martins commented on WFBUILD-4:
---------------------------------------
Here is an idea to support multiple versions of same artefacts:
{code:xml}
<?xml version="1.0" ?>
<feature-pack xmlns="urn:wildfly:feature-pack:1.0">
<dependencies>
<artifact name="org.wildfly:kickass-feature-pack" />
</dependencies>
<artifact-resolver>
<maven-artifact name="io.undertow:undertow-core:1.x" groupId="io.undertow" artifactId="undertow-core" version="1.1.0.Beta7"/>
<maven-artifact name="io.undertow:undertow-core:2.x" groupId="io.undertow" artifactId="undertow-core" version="2.0.0.Alpha1"/>
<url-artifact name="org.jboss.modules:jboss-modules" url="http://blablabla/my-jboss-modules.jar"/>
<url-artifact name="org.wildfly:kickass-feature-pack" url="http://wildfly.org/feature-packs/kickass.zip"/>
</artifact-resolver>
<copy-artifacts>
<copy-artifact artifact="org.jboss.modules:jboss-modules" to-location="jboss-modules.jar"/>
</copy-artifacts>
</feature-pack>
{code}
This is actually a small change compared to what we have now internally for feature packs, simply expose to wildfly-feature-pack.xml, the artifact reference name that is in module.xml (property name), other elements of the feature-pack xml such as the copy-artifact, or the ones computed from maven dependencies that are used as keys in the maven artifact resolver. The maven artifact version becomes just one more id, and we can even introduce - later - different type of artifacts, such as the url-artifact above.
What do you think?
> Add the ability to override the specific version of Maven artifacts
> -------------------------------------------------------------------
>
> Key: WFBUILD-4
> URL: https://issues.jboss.org/browse/WFBUILD-4
> Project: WildFly Build Tools
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Fix For: 1.0.0.Alpha3
>
>
> e.g. it should be possible to assemble a server with a newer version of Weld or Resteasy that what was provided in the feature pack.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (DROOLS-591) "not" and "accumulate" ordering LHS yield different counting
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-591?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-591:
----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> "not" and "accumulate" ordering LHS yield different counting
> ------------------------------------------------------------
>
> Key: DROOLS-591
> URL: https://issues.jboss.org/browse/DROOLS-591
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Final
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
>
> Ref. original post in Drools-Usage
> https://groups.google.com/d/msg/drools-usage/ETkH7gn3YwY/Fc46KqqkN9QJ
> h5. excerpt of original post
> I'm experiencing a very weird behavior of using "not" and "accumulate", their ordering in LHS yield different counting results. I can provide privately a reproducer because this happens only when several rules are deployed - the other rules do NOT interact over the same objects in memory, except from queries.
> The example knowledge base below, the goal is to detect spikes in temperature (integers) over the last 5m, and raise/clear an Alert accordingly. The unit test prove that when either of the rules "Trending Alert" or "Trending Clear" fires, the content of $myList if compared to the $myList coming from the third rule, is the SAME, because indeed just collecting over the same over window:time(5m)
> However, here is the odd behavior, when I also deploy the full kb:
> * If I leave "Trending Alert" this way, the content of $myList when the rule fire, actually extend beyond the 5m sliding window, in fact keeping track of 20m, 30m old samples, therefore yielding wrong results
> * If I reorder "Trending Alert" LHS to have the not Alert ( condition == "TEMPERATURE_TRENDING") to appear before the accumulate, the content of $myList when the rule fire is correct.
> * If I leave "Trending Alert" this way, and I remove other .drl files, the content of $myList when the rule fire is correct.
> Thanks
> {code}
> rule "Trending Alert"
> no-loop
> when
> accumulate( $cc : AirSurveyTemp ($temp : TheTemp ) over window:time(5m) ;
> $myList : collectList($cc),
> $number : count($cc),
> $min : min($temp),
> $max : max($temp) ;
> $max-$min > 10 )
> $oWhere : Measurement( id == "Inhabited area", val == "False" )
> not Alert ( condition == "TEMPERATURE_TRENDING")
> then
> Alert a = new Alert();
> a.setCondition("TEMPERATURE_TRENDING");
> System.out.println("++ Temperature Trending - " + a.getCondition() + " - Number of Object: " + $number + " - Min Value = " + $min + " - Max Value: " + $max );
> insert(a);
> alert.clear();
> alert.addAll($myList);
> end
>
> rule "Trending Clear"
> no-loop
> when
> $a : Alert(condition == "TEMPERATURE_TRENDING")
> accumulate( $cc : AirSurveyTemp ($temp : TheTemp ) over window:time(5m) ;
> $myList : collectList($cc),
> $number : count($cc),
> $min : min($temp),
> $max : max($temp) ;
> $max-$min < 11 )
> then
> System.out.println("-- Clear Alert "+ $a.getCondition() + "Number of Object: " + " - Number of Object: " + $number + " - Min Value = " + $min + " - Max Value: " + $max );
> retract($a);
> clear.clear();
> clear.addAll($myList);
> end
> rule "Trending Sampling window 5m"
> salience 1
> no-loop
> when
> accumulate( $cc : AirSurveyTemp ($temp : TheTemp ) over window:time(5m) ;
> $myList : collectList($cc),
> $number : count($cc),
> $min : min($temp),
> $max : max($temp)
> )
> then
> sampling.clear();
> sampling.addAll($myList);
> end
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months