[JBoss JIRA] (JBJCA-1053) ResourceAdapter instances not registered for inflow crash recovery
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1053?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1053:
------------------------------------------------
Tom Ross <tom.ross(a)redhat.com> made a comment on [bug 980920|https://bugzilla.redhat.com/show_bug.cgi?id=980920]
Description of problem: Resource adapters are not being registered for for inflow crash recovery.
Version-Release number of selected component (if applicable):
6.00, 6.01, 6.1
How reproducible:
Deploy a RA like IBM WMQ and observe the log file.
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
> ResourceAdapter instances not registered for inflow crash recovery
> ------------------------------------------------------------------
>
> Key: JBJCA-1053
> URL: https://issues.jboss.org/browse/JBJCA-1053
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.17.Final, 1.1.0.Beta5
> Reporter: Jesper Pedersen
> Assignee: Jesper Pedersen
> Priority: Blocker
> Fix For: 1.0.18.Final, 1.1.0.CR1
>
>
> We need to register the ResourceAdapter instances for inflow crash recovery, since we can't depend on users of ResourceAdapterRepository does it
--
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
[JBoss JIRA] (WFLY-1625) WebConsole: Ability to mock different roles
by Harald Pehl (JIRA)
[ https://issues.jboss.org/browse/WFLY-1625?page=com.atlassian.jira.plugin.... ]
Harald Pehl edited comment on WFLY-1625 at 7/3/13 10:03 AM:
------------------------------------------------------------
Available roles:
- Monitor
- Configurator
- Operator
- Maintainer
- Deployer
- Administrator
- Auditor
- SuperUser
To execute a DMR operation on behalf of a specific role, one must add the {{operation-headers}} node and the {{roles}} attribute:
{code}
{
"operation" => "foo",
"address" => [("foo", "bar")],
"operation-headers" =>
{
"roles" => "operator"
}
}
{code}
was (Author: harald.pehl):
Available roles:
- Monitor
- Configurator
- Operator
- Maintainer
- Deployer
- Administrator
- Auditor
- SuperUser
To execute a DMR operation on behalf of a specific role, one must add the `operation-headers` node and the {{roles}} attribute:
{code}
{
"operation" => "foo",
"address" => [("foo", "bar")],
"operation-headers" =>
{
"roles" => "operator"
}
}
{code}
> WebConsole: Ability to mock different roles
> -------------------------------------------
>
> Key: WFLY-1625
> URL: https://issues.jboss.org/browse/WFLY-1625
> Project: WildFly
> Issue Type: Feature Request
> Components: Web Console
> Reporter: Heiko Braun
> Assignee: Harald Pehl
>
--
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
[JBoss JIRA] (JBJCA-1053) ResourceAdapter instances not registered for inflow crash recovery
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-1053:
--------------------------------------
Summary: ResourceAdapter instances not registered for inflow crash recovery
Key: JBJCA-1053
URL: https://issues.jboss.org/browse/JBJCA-1053
Project: IronJacamar
Issue Type: Bug
Components: Core
Affects Versions: 1.1.0.Beta5, 1.0.17.Final
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Priority: Blocker
Fix For: 1.0.18.Final, 1.1.0.CR1
We need to register the ResourceAdapter instances for inflow crash recovery, since we can't depend on users of ResourceAdapterRepository does it
--
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
[JBoss JIRA] (WFLY-1456) 2 responses sent to bean client on bean invocation returning an exception, resulting in StreamCorruptedException under certain conditions
by Christian von Kutzleben (JIRA)
[ https://issues.jboss.org/browse/WFLY-1456?page=com.atlassian.jira.plugin.... ]
Christian von Kutzleben commented on WFLY-1456:
-----------------------------------------------
some additional information:
it turned out, that this (duplicate) bug I've found did not cause the problem; it still occurred after migrating to EAP 6.1
However after some lengthy debugging through the Unmarshaller, it eventually turned out, that our two environments (Eclipse and command line)
which showed different behavior (worked vs. StreamCorruptedException) had 2 different versions of javax.ejb.EJBException
in the classpath (and the 2 environments ordered the classpath differently)
one of the EJBException classes has a field:
private java.lang.Exception causeException;
the other has no declared fields
After serializing all other fields, JBoss serialized this field (here: 2 bytes) but only
the client with the right EJBException version deserialized everything correctly, the other
one deserialized everything less the 2 bytes. So when "readAttachments" was called, a wrong value
was read, because the position in the bytestream was wrong.
> 2 responses sent to bean client on bean invocation returning an exception, resulting in StreamCorruptedException under certain conditions
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1456
> URL: https://issues.jboss.org/browse/WFLY-1456
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: No Release
> Reporter: Christian von Kutzleben
> Assignee: jaikiran pai
> Fix For: 8.0.0.Alpha1
>
>
> I've debugged that against EAP 6.0.1, but the symptom occurred for 7.1.1 as well:
> My test case throws a RuntimeException in the beans method body.
> I've experienced a strang behavior: if my junit test, that is the bean client, was executed within Eclipse, everything seemed to work fine on the client side. I debugged into the RiverUnmarshaller and it received the correctly deserialized exception, there were no attachments transmitted.
> When I executed the junit test case from ant, the RiverUnmarshaller threw an exception, here: java.io.EOFException: Read past end of file
> (I did also get StreamCorruptedExceptions if the exception was thrown in the commit phase rather than the method body).
> In both stack traces (EOFException and StreamCorruptedException) the problem occurred in org.jboss.ejb.client.remoting.ProtocolMessageHandler.readAttachments.
> When I debugged the client invoked from ant, I found, that like in Eclipse, first the exception is correctly deserialized, but then, it tries to read 57 attachments, but not a single byte follows (-> EOFException).
> The next step was, to debug into the server:
> org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler
> anonymous inner class #1, starts at about line 185:
> result = invokeMethod(invocationId, componentView, invokedMethod, methodParams, locator, attachments); //l.202
> throws an exception, this is handled:
> MethodInvocationMessageHandler.this.writeException(channelAssociation, MethodInvocationMessageHandler.this.marshallerFactory, invocationId, throwable, attachments); //l.206
> "attachments" is empty; a response message is created containing no attachments, this is the same for the Eclipse and ant invocation.
> The weird thing now is, regardless, that an exception was thrown and a response message written, in l. 238
> writeMethodInvocationResponse(channelAssociation, invocationId, result, attachments);
> another, second response is written. Containing "null" as result, and this time a single affinity object in the attachments.
> When run from Eclipse, this code executed fine, however the bean client seems to never read the second response.
> When run from ant, this code throws an exception:
> JBAS014560: Could not open message outputstream for writing to Channel
> and the client reads a corrupted first response, containing a valid exception and some nonsense thereafter.
> I blame the different behavior on different timings, for me it seems that the cause of the issue is, that in the exceptional case a second response is written, that should not be written.
--
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
[JBoss JIRA] (WFLY-1633) getCodeSigners() returns null in signed WAR deployments
by Christophe Fillot (JIRA)
Christophe Fillot created WFLY-1633:
---------------------------------------
Summary: getCodeSigners() returns null in signed WAR deployments
Key: WFLY-1633
URL: https://issues.jboss.org/browse/WFLY-1633
Project: WildFly
Issue Type: Bug
Components: Class Loading
Affects Versions: 8.0.0.Alpha2
Reporter: Christophe Fillot
Assignee: David Lloyd
Calling getProtectionDomain().getCodeSource().getCodeSigners() for a class of a WAR deployment returns null, even if the WAR file is signed. No problem for EJB JAR.
This is because the WAR file is exploded on disk (the full analysis is described in the forum post).
--
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
[JBoss JIRA] (WFLY-352) Add sufficient TRACE / DEBUG logging to debug security realm configurations.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-352?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated WFLY-352:
----------------------------------
Summary: Add sufficient TRACE / DEBUG logging to debug security realm configurations. (was: EAP 6 Domain Mode Logging for Management is nonexistent. )
> Add sufficient TRACE / DEBUG logging to debug security realm configurations.
> ----------------------------------------------------------------------------
>
> Key: WFLY-352
> URL: https://issues.jboss.org/browse/WFLY-352
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Eric Rich
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 8.0.0.Alpha3
>
> Attachments: jboss-as-domain-management-7.1.2.Final-redhat-1.jar, log_mgmt_auth_calls.txt
>
>
> When trying to diagnose LDAP or Admin Configuration issue in Domain mode there is currently no logging for any of the authentication information.
--
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
[JBoss JIRA] (WFLY-1632) Cannot deploy distributable application when is defined jdbc-store for web session
by Tomas Remes (JIRA)
Tomas Remes created WFLY-1632:
---------------------------------
Summary: Cannot deploy distributable application when is defined jdbc-store for web session
Key: WFLY-1632
URL: https://issues.jboss.org/browse/WFLY-1632
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 8.0.0.Alpha2
Reporter: Tomas Remes
Assignee: Paul Ferraro
Using following infinispan subsystem configuration is causing CNF org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore
<cache-container name="web" aliases="standard-session-cache" default-cache="local-web" module="org.jboss.as.clustering.web.infinispan">
<local-cache name="local-web" batching="true">
<string-keyed-jdbc-store datasource="java:jboss/datasources/ExampleDS" passivation="false" preload="true" purge="false">
<property name="databaseType">H2</property>
<string-keyed-table prefix="stringbased">
<id-column name="id" type="VARCHAR"/>
<data-column name="datum" type="BINARY"/>
<timestamp-column name="version" type="BIGINT"/>
</string-keyed-table>
</string-keyed-jdbc-store>
</local-cache>
</cache-container>
{noformat}
14:32:29,021 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 15) MSC000001: Failed to start service jboss.infinispan.web.default-host/jdbcStore: org.jboss.msc.service.StartException in service jboss.infinispan.web.default-host/jdbcStore: org.infinispan.CacheException: Unable to invoke method public void org.infinispan.loaders.CacheLoaderManagerImpl.start() on object of type CacheLoaderManagerImpl
at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:87)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_21]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_21]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_21]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
Caused by: org.infinispan.CacheException: Unable to invoke method public void org.infinispan.loaders.CacheLoaderManagerImpl.start() on object of type CacheLoaderManagerImpl
at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:207)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:889)
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:658)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:647)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:550)
at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:221)
at org.infinispan.CacheImpl.start(CacheImpl.java:691)
at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:686)
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:649)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:545)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:559)
at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:109)
at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:100)
at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:78)
at org.jboss.as.clustering.msc.AsynchronousService$1.run(AsynchronousService.java:82)
... 4 more
Caused by: org.infinispan.CacheException: Unable to start cache loaders
at org.infinispan.loaders.CacheLoaderManagerImpl.start(CacheLoaderManagerImpl.java:163)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.7.0_21]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [rt.jar:1.7.0_21]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_21]
at java.lang.reflect.Method.invoke(Method.java:601) [rt.jar:1.7.0_21]
at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
... 18 more
Caused by: org.infinispan.CacheConfigurationException: Unable to instantiate class org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore
at org.infinispan.util.Util.loadClass(Util.java:104)
at org.infinispan.util.Util.getInstance(Util.java:225)
at org.infinispan.loaders.CacheLoaderManagerImpl.createCacheLoader(CacheLoaderManagerImpl.java:347)
at org.infinispan.loaders.CacheLoaderManagerImpl.createCacheLoader(CacheLoaderManagerImpl.java:337)
at org.infinispan.loaders.CacheLoaderManagerImpl.start(CacheLoaderManagerImpl.java:149)
... 23 more
Caused by: java.lang.ClassNotFoundException: org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore
at java.net.URLClassLoader$1.run(URLClassLoader.java:366) [rt.jar:1.7.0_21]
at java.net.URLClassLoader$1.run(URLClassLoader.java:355) [rt.jar:1.7.0_21]
at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.7.0_21]
at java.net.URLClassLoader.findClass(URLClassLoader.java:354) [rt.jar:1.7.0_21]
at java.lang.ClassLoader.loadClass(ClassLoader.java:423) [rt.jar:1.7.0_21]
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308) [rt.jar:1.7.0_21]
at java.lang.ClassLoader.loadClass(ClassLoader.java:356) [rt.jar:1.7.0_21]
at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_21]
at java.lang.Class.forName(Class.java:266) [rt.jar:1.7.0_21]
at org.infinispan.util.Util.loadClassStrict(Util.java:141)
at org.infinispan.util.Util.loadClass(Util.java:102)
... 27 more
{noformat}
--
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