[JBoss JIRA] (AS7-5884) CLONE - Deployment in a domain will be destroyed if there are multiple deplyments with the same content SHA1
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-5884?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-5884:
----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 901159|https://bugzilla.redhat.com/show_bug.cgi?id=901159] from MODIFIED to ON_QA
> CLONE - Deployment in a domain will be destroyed if there are multiple deplyments with the same content SHA1
> ------------------------------------------------------------------------------------------------------------
>
> Key: AS7-5884
> URL: https://issues.jboss.org/browse/AS7-5884
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Wolf-Dieter Fink
> Assignee: Kabir Khan
> Priority: Critical
> Labels: deployers, domain, eap, jboss
> Fix For: 7.2.0.CR1, 7.1.4.Final (EAP)
>
>
> If a deployment in a domain is the same file, deployed with different names to different server-groups, it become the same SHA1.
> In that case the stored content will not be updated and the <deployments> section become a new entry which is used by the second server group.
> But if one of the deployments will be undeployed or updated the content is complete removed but the second deployment entry is still available.
> The second deployment can be used as long as there is a action to it (e.g. restart).
> In that case a FATAL error is thrown:
> [Host Controller] 11:43:36,493 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("add") failed - address: ([("deployment" => "prod.ear")]) - failure description: "JBAS010876: No deployment content with hash 0807c2c28e5feebb8dfb905788e53b104ecb89fc is available in the deployment content repository for deployment 'prod.ear'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuraiton file and restart."
> [Host Controller] 11:43:36,496 FATAL [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010933: Host Controller boot has failed in an unrecoverable manner; exiting. See previous messages for details.
--
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
13 years, 4 months
[JBoss JIRA] (AS7-6630) Unable to change attributes of Mail session through cli
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-6630?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-6630:
----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 910282|https://bugzilla.redhat.com/show_bug.cgi?id=910282] from MODIFIED to ON_QA
> Unable to change attributes of Mail session through cli
> -------------------------------------------------------
>
> Key: AS7-6630
> URL: https://issues.jboss.org/browse/AS7-6630
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, Mail
> Affects Versions: 7.2.0.Alpha1, 8.0.0.Alpha1
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Fix For: 7.3.0.Alpha1, 8.0.0.Alpha1
>
>
> Any attempt to change Mail session after it was created fails
> Steps to Reproduce: In jboss-cli
> 1. Create new session
> /subsystem=mail/mail-session=mysession/:add(jndi-name="java:/musession")
> result:
> {"outcome" => "success"}
> 2. Check created resource
> /subsystem=mail/mail-session=mysession/:read-resource
> result:
> {
> "outcome" => "success",
> "result" => {
> "custom" => undefined,
> "debug" => false,
> "from" => undefined,
> "jndi-name" => "java:/mysession",
> "server" => undefined
> }
> }
> 3. Try to change some attribute (e.g. jndi)
> /subsystem=mail/mail-session=mysession/:write-attribute(name=jndi-name,value="java:/mailsession")
> result:
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014749: Operation handler failed: null",
> "rolled-back" => true
> }
>
> expected result:
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> Additional:
> The debug attribute can be changed exactly once and only to true. Once it is turned on it cannot be changed again like the rest.
--
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
13 years, 4 months
[JBoss JIRA] (AS7-5937) UndeclaredThrowableException if EJB invocation fails with IOException
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-5937?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-5937:
----------------------------------------------
Paul Gier <pgier(a)redhat.com> changed the Status of [bug 901006|https://bugzilla.redhat.com/show_bug.cgi?id=901006] from ASSIGNED to MODIFIED
> UndeclaredThrowableException if EJB invocation fails with IOException
> ---------------------------------------------------------------------
>
> Key: AS7-5937
> URL: https://issues.jboss.org/browse/AS7-5937
> Project: Application Server 7
> Issue Type: Bug
> Components: EJB
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Richard Janík
> Assignee: Stuart Douglas
> Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
>
>
> UndeclaredThrowableExceptions were seen at failover testing through server crashes. Scenarios: jvmkill-dist-async, jvmkill-repl-async, jvmkill-repl-sync. Stack traces:
> {code}
> 2012/09/27 09:10:22:331 EDT [ERROR][Runner - 1533] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error getting response. <java.lang.reflect.UndeclaredThrowableException>
> java.lang.reflect.UndeclaredThrowableException
> at $Proxy0.getSerialAndIncrement(Unknown Source)
> at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:75)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.io.IOException: Broken pipe
> at sun.nio.ch.FileDispatcher.write0(Native Method)
> at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:29)
> at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:69)
> at sun.nio.ch.IOUtil.write(IOUtil.java:40)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
> at org.xnio.nio.AbstractNioStreamChannel.write(AbstractNioStreamChannel.java:303)
> at org.xnio.channels.FramedMessageChannel.doFlushBuffer(FramedMessageChannel.java:295)
> at org.xnio.channels.FramedMessageChannel.doFlush(FramedMessageChannel.java:309)
> at org.xnio.channels.FramedMessageChannel.send(FramedMessageChannel.java:236)
> at org.xnio.channels.Channels.sendBlocking(Channels.java:200)
> at org.jboss.remoting3.remote.OutboundMessage$1.accept(OutboundMessage.java:109)
> at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:126)
> at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:114)
> at org.xnio.streams.BufferPipeOutputStream.flush(BufferPipeOutputStream.java:143)
> at org.xnio.streams.BufferPipeOutputStream.close(BufferPipeOutputStream.java:161)
> at org.jboss.remoting3.remote.OutboundMessage.close(OutboundMessage.java:193)
> at org.jboss.ejb.client.remoting.ChannelAssociation.releaseChannelMessageOutputStream(ChannelAssociation.java:266)
> at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.processInvocation(RemotingConnectionEJBReceiver.java:203)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)
> ... 5 more
> {code}
> {code}
> 2012/09/27 09:10:22:344 EDT [ERROR][Runner - 114] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error getting response. <java.lang.reflect.UndeclaredThrowableException>
> java.lang.reflect.UndeclaredThrowableException
> at $Proxy0.getSerialAndIncrement(Unknown Source)
> at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:75)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: org.jboss.remoting3.NotOpenException: Writes closed
> at org.jboss.remoting3.remote.RemoteConnectionChannel.openOutboundMessage(RemoteConnectionChannel.java:107)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.writeMessage(RemoteConnectionChannel.java:296)
> at org.jboss.ejb.client.remoting.ChannelAssociation.acquireChannelMessageOutputStream(ChannelAssociation.java:249)
> at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.processInvocation(RemotingConnectionEJBReceiver.java:196)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125)
> at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:136)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:121)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:104)
> ... 5 more
> {code}
> {code}
> 2012/09/27 09:14:37:914 EDT [ERROR][Runner - 335] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error getting response. <java.lang.reflect.UndeclaredThrowableException>
> java.lang.reflect.UndeclaredThrowableException
> at $Proxy0.getSerialAndIncrement(Unknown Source)
> at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:75)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:87)
> at java.lang.Thread.run(Thread.java:662)
> Caused by: java.io.IOException: Channel Channel ID 9d26983d (outbound) of Remoting connection 12dfbabd to null has been closed
> at org.jboss.ejb.client.remoting.ChannelAssociation$1.handleClose(ChannelAssociation.java:115)
> at org.jboss.ejb.client.remoting.ChannelAssociation$1.handleClose(ChannelAssociation.java:107)
> at org.jboss.remoting3.spi.SpiUtils.safeHandleClose(SpiUtils.java:54)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable$CloseHandlerTask.run(AbstractHandleableCloseable.java:501)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.runCloseTask(AbstractHandleableCloseable.java:406)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeComplete(AbstractHandleableCloseable.java:277)
> at org.jboss.remoting3.remote.RemoteConnectionChannel.closeAction(RemoteConnectionChannel.java:517)
> at org.jboss.remoting3.spi.AbstractHandleableCloseable.closeAsync(AbstractHandleableCloseable.java:359)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.closeAllChannels(RemoteConnectionHandler.java:382)
> at org.jboss.remoting3.remote.RemoteConnectionHandler.handleConnectionClose(RemoteConnectionHandler.java:103)
> at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:78)
> at org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:45)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
> at org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
> at org.xnio.nio.NioHandle.run(NioHandle.java:90)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:187)
> {code}
> These exceptions were numerous and were seen by clients (ejb remote calls) after node crash. This is the client call of the bean:
> {code}
> myBean = (RemoteStatefulSB) context.lookup("ejb:" + appName + "/" + moduleName + "/" + distinctName + "/" + beanName + "!" + viewClassName + "?stateful");
> {code}
> Links to hudson jobs:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-Fail...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-Fail...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/EAP6/view/EAP6-Fail...
--
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
13 years, 4 months
[JBoss JIRA] (AS7-3199) RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/AS7-3199?page=com.atlassian.jira.plugin.s... ]
Ondrej Zizka edited comment on AS7-3199 at 3/5/13 4:26 PM:
-----------------------------------------------------------
Also, could you please merge it to EAP 6.1.x? Once you spent time on it...
> RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present
> ---------------------------------------------------------------------------------------------
>
> Key: AS7-3199
> URL: https://issues.jboss.org/browse/AS7-3199
> Project: Application Server 7
> Issue Type: Bug
> Components: REST
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Attachments: ExampleJAXRS.war
>
>
> If I packed WAR WebApp with more that one subclass of javax.ws.rs.Application, deployment fails with "JBAS011232: Only one JAX-RS Application Class allowed."
> This is not correct because it is against JAX-RS 1.1. specs where invalid situation (in section 2.3.2) is only when "It is a n error for
> more than one application to be deployed +at the same effective servlet mapping+".
> If you have any objections, please compare to reference JEE6 and JAX-RS implementation represented by the GlassFish Prelude 3.1.1 application server with already +fully JEE6 platform support+.
--
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
13 years, 4 months
[JBoss JIRA] (AS7-3199) RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present
by Ondrej Zizka (JIRA)
[ https://issues.jboss.org/browse/AS7-3199?page=com.atlassian.jira.plugin.s... ]
Ondrej Zizka commented on AS7-3199:
-----------------------------------
Unfortunatelly, next AS is just 8...
Anyway, thanks! Can you link the PR please?
> RESTEasy: Can't deploy WebApp if more than one subclass of javax.ws.rs.Application is present
> ---------------------------------------------------------------------------------------------
>
> Key: AS7-3199
> URL: https://issues.jboss.org/browse/AS7-3199
> Project: Application Server 7
> Issue Type: Bug
> Components: REST
> Affects Versions: 7.1.0.CR1b
> Reporter: Pavel Janousek
> Attachments: ExampleJAXRS.war
>
>
> If I packed WAR WebApp with more that one subclass of javax.ws.rs.Application, deployment fails with "JBAS011232: Only one JAX-RS Application Class allowed."
> This is not correct because it is against JAX-RS 1.1. specs where invalid situation (in section 2.3.2) is only when "It is a n error for
> more than one application to be deployed +at the same effective servlet mapping+".
> If you have any objections, please compare to reference JEE6 and JAX-RS implementation represented by the GlassFish Prelude 3.1.1 application server with already +fully JEE6 platform support+.
--
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
13 years, 4 months