[JBoss JIRA] Created: (JBAOP-300) SecurityActions$PrincipalInfoAction missing from client jar
by Thomas Diesler (JIRA)
SecurityActions$PrincipalInfoAction missing from client jar
-----------------------------------------------------------
Key: JBAOP-300
URL: http://jira.jboss.com/jira/browse/JBAOP-300
Project: JBoss AOP
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Thomas Diesler
java.lang.NoClassDefFoundError: org/jboss/aspects/security/SecurityActions$PrincipalInfoAction
at org.jboss.aspects.security.SecurityActions.getPrincipal(SecurityActions.java:363)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:47)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:77)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:102)
--
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
[JBoss JIRA] Created: (JBRULES-434) Cannot enter more than one parameter in one column on German computers
by Volker Augustin (JIRA)
Cannot enter more than one parameter in one column on German computers
----------------------------------------------------------------------
Key: JBRULES-434
URL: http://jira.jboss.com/jira/browse/JBRULES-434
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Decision tables
Environment: Windows XP, standard GERMAN settings
Reporter: Volker Augustin
Assigned To: Mark Proctor
Section 4.1.4.1 of the JBoss Rules documentation states:
The "$para" place holder is used in templates to indicate where data form the cell will be interpolated. You can also use "$1" to the same effect. If the cell contains a comma seperated list of values, $1 and $2 etc. may be used to indicate which positional parameter from the list of values in the cell will be used.
As the German decimal separator is ',' and not '.' as in the English locale, no list of this form can be entered on a German computer system if there are e.g. only two values and they happen to be integers. E.g. if you try to create the list containing the two values 10 and 20, according to the documentation you must enter '10,20'. This will be interpreted as 10.20 by a German computer and result in a single decimal value instead of a list of two integers.
The separator ',' is hardcoded somewhere (in SnippedBuilder (?) I think). Maybe this can be made configurable. E.g. a "Configuration" section in the Excel spreadsheet would do.
--
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
[JBoss JIRA] Created: (JBMESSAGING-520) Messages received from Receiver.receive() using an XA are never deleted from the database if not withing a transactional boundary.
by Joel Lindheimer (JIRA)
Messages received from Receiver.receive() using an XA are never deleted from the database if not withing a transactional boundary.
----------------------------------------------------------------------------------------------------------------------------------
Key: JBMESSAGING-520
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-520
Project: JBoss Messaging
Issue Type: Feature Request
Components: Messaging Core
Affects Versions: 1.0.1.CR4
Environment: Windows XP, JBossServer4.0.4GA, Oracle10G
Reporter: Joel Lindheimer
Assigned To: Ovidiu Feodorov
Create a simple receiver, but do not place it within a Transaction boundary; shut down the server; look up the tables and you will see all the messages are still in the Messages and MessageRef tables.
=========================================
Observations using a debbuger reveal the following:
=========================================
Looking over the org.jboss.resource.adapter.jms.JmsManagedConnection the setup method will always call createXAQueueSession() and create an XAQueconnection as transacted and Session.SESSION_TRANSACTED. That being the case, non-XA Queues have no message-deletion problems with the current version (RC4) because the API removes all messages that are "not transacted and (!ack==1). I am guessing that using XA is problematic because the persistence layer is expecting manipulation of the transacted XASession--which for some reason is not working in this version of Messaging. More specifically, I suspect that when MDBs are tested you are not seeing this problem because the container is doing needed magic to manage the XASession transacted state, and therefore everything works fine therein. And consequently, when operating as a non-MDB client, AKA a simple Receiver, there is something missing in the equation ergo the problems that I have been reporting regarding the ClickCommerce applications which use Receivers and not MDBs.
Work-around: None; the strategy for my team is to NOT use an XAQueueConnection while waiting for a fix.
--
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
[JBoss JIRA] Created: (JBMESSAGING-584) Eliminate jgroups.jar "processing"
by Ovidiu Feodorov (JIRA)
Eliminate jgroups.jar "processing"
----------------------------------
Key: JBMESSAGING-584
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-584
Project: JBoss Messaging
Issue Type: Task
Components: Build System
Reporter: Ovidiu Feodorov
Assigned To: Ovidiu Feodorov
Priority: Trivial
Fix For: 1.2.0.CR1
During the release procedure, the current release script expands jgroups.jar and removes service deployment descriptos (gossip-service.xml multiplexer-service.xml). It has just been confirmed by the JGroups team that the presence of those deployment descriptors is not intentional, it's just an unwanted artifact of their release process.
Get rid of "jgroups jar processing" as soon as we upgrade our dependency to a "clean" jgroups jar.
--
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