[JBoss JIRA] Created: (JBAS-3792) Better error reporting when messages "mysteriously" vanish
by Adrian Brock (JIRA)
Better error reporting when messages "mysteriously" vanish
----------------------------------------------------------
Key: JBAS-3792
URL: http://jira.jboss.com/jira/browse/JBAS-3792
Project: JBoss Application Server
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: JMS service
Affects Versions: JBossAS-4.0.5.GA
Reporter: Adrian Brock
Fix For: JBossAS-4.0.6.GA
It is commonly the case that people try to run two instances of JBossMQ against the same
database tables. This can lead to errors like the ones in the parent task or a similar message
in the delete when doing acknowledgements.
These error messages need improving and also give a hint to the possible reasons,
e.g.
1) competing JBossMQs trying to share the same database
2) trying to use a replicating database that does not support synchronous replication (i..e there
is a delay in a row getting written to one database before it appears in the other database)
The parent issue's error message belongs in org.jboss.mq.pm.jdbc2.PersistenceManager
public SpyMessage loadFromStorage(MessageReference messageRef) throws JMSException
{
...
rs = stmt.executeQuery();
if (rs.next())
return extractMessage(rs);
+ else
throw new JMSException("Unable to load message " + messageRef + " from storage, are you trying to share database tables between JBossMQ instances? Are you using a replicating database that does not support synchronous replication?");
- return null;
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JBBUILD-326) JBossRetro missing getDeclaredAnnotations; getAnnotations implementation is deficient
by David Lloyd (JIRA)
JBossRetro missing getDeclaredAnnotations; getAnnotations implementation is deficient
-------------------------------------------------------------------------------------
Key: JBBUILD-326
URL: http://jira.jboss.com/jira/browse/JBBUILD-326
Project: JBoss Build System
Issue Type: Bug
Components: JBossRetro
Affects Versions: JBossRetro-1.0.4.GA
Reporter: David Lloyd
Priority: Minor
Fix For: JBossRetro-1.0.5.GA
I put in a fix to JBossRetro to add support for getDeclaredAnnotations on Method, Field, Constructor, and AccessibleObject. In doing this I realized that getAnnotations seems to be doing what getDeclaredAnnotations is supposed to be doing; according to the JDK javadocs, getAnnotations is supposed to return inherited annotations as well as declared annotations, whereas getDeclaredAnnotations only returns annotations on the specific object.
I committed a change to implement getDeclaredAnnotations which essentially duplicates the current getAnnotations behavior, but someone may want to go in and enhance getAnnotations.
I'm attaching the patch that I committed in case I'm wrong and someone wants to revert it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months
[JBoss JIRA] Created: (JBAS-3781) Stateful SB Instance Interceptor should not push SubjectContext if RunAsIdentity present
by Anil Saldhana (JIRA)
Stateful SB Instance Interceptor should not push SubjectContext if RunAsIdentity present
----------------------------------------------------------------------------------------
Key: JBAS-3781
URL: http://jira.jboss.com/jira/browse/JBAS-3781
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: EJB2
Affects Versions: JBossAS-4.0.5.GA, JBossAS-3.2.8.SP1, JBossAS-5.0.0.Beta
Reporter: Anil Saldhana
Assigned To: Anil Saldhana
Fix For: JBossAS-5.0.0.Beta, JBossAS-3.2.8.SP2, JBossAS-4.0.6.CR1
The following Subject Context push (with null Subject) to establish client security context should not be performed if the user has configured a RunAsIdentity in the caller bean.
/* The security context must be established before the cache
lookup because the activation of a session should have the caller's
security context as ejbActivate is allowed to call other secured
resources. Since the pm makes the ejbActivate call, we need to
set the caller's security context. The only reason this shows up for
stateful session is that we moved the SecurityInterceptor to after
the instance interceptor to allow security exceptions to result in
invalidation of the session. This may be too literal an interpretation
of the ejb spec requirement that runtime exceptions should invalidate
the session.
*/
SecurityActions.pushSubjectContext(mi.getPrincipal(), mi.getCredential(), null);
The resolution is:
if(SecurityActions.peekRunAsIdentity() == null)
SecurityActions.pushSubjectContext(mi.getPrincipal(), mi.getCredential(), null);
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
19 years, 2 months