[JBoss JIRA] (AS7-5902) HornetQ does not delete message from queue when the message is rolled back and the DLQ is not present
by Ravi Bhardwaj (JIRA)
Ravi Bhardwaj created AS7-5902:
----------------------------------
Summary: HornetQ does not delete message from queue when the message is rolled back and the DLQ is not present
Key: AS7-5902
URL: https://issues.jboss.org/browse/AS7-5902
Project: Application Server 7
Issue Type: Bug
Components: JMS
Affects Versions: 7.1.2.Final (EAP)
Reporter: Ravi Bhardwaj
Assignee: Jeff Mesnil
When a message is rolled back and the DLQ binding configured for queue is missing, the server throws the following warning message saying that it is dropping the message, however we can still see the message count and In Delivery count as :
WARN [org.hornetq.core.server.impl.QueueImpl] (Thread-3 (HornetQ-server-HornetQServerImpl::serverUUID=c7787105-2983-11e2-94d2-611405d536ca-619601171)) Message Reference[143]:RELIABLE:ServerMessage[messageID=143,priority=4, bodySize=178,expiration=0, durable=true, address=jms.queue.TestQ2,properties=TypedProperties[null]]@1575145817 has exceeded max delivery attempts. No bindings for Dead Letter Address jms.queue.DLQ123 so dropping 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
11 years, 7 months
[JBoss JIRA] (JBRULES-3682) Guvnor drools-compiler jar file dependancy with antlr3.3 creating issue in deployment of EAR.
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3682?page=com.atlassian.jira.plug... ]
Michael Anstis moved GUVNOR-1967 to JBRULES-3682:
-------------------------------------------------
Project: Drools (was: Guvnor)
Key: JBRULES-3682 (was: GUVNOR-1967)
Issue Type: Task (was: Enhancement)
Affects Version/s: 5.3.0.Final
(was: drools-5.3.0.Final)
> Guvnor drools-compiler jar file dependancy with antlr3.3 creating issue in deployment of EAR.
> ---------------------------------------------------------------------------------------------
>
> Key: JBRULES-3682
> URL: https://issues.jboss.org/browse/JBRULES-3682
> Project: Drools
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 5.3.0.Final
> Environment: local
> Reporter: Amit Telang
> Labels: maven
>
> Hi, after inclusion guvnor 5.x in application, we are unable to deploy our application through Hudson on our managed server. Issue is related to drools-compiler-5.3.0.Final.jar dependancy with antlr3.3 jar file. If I use exclusion tag to exclude this it excludes all the jar which starts with antlr.
> If I use package exclude to include this antlr3.3 it do not compile. Unable to resolve this small looking issue for a long time.
> Please provide any valuable feedback if someone also faces this issue.
--
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
11 years, 7 months
[JBoss JIRA] (JBRULES-3682) drools-compiler jar file dependancy with antlr3.3 creating issue in deployment of EAR.
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/JBRULES-3682?page=com.atlassian.jira.plug... ]
Michael Anstis updated JBRULES-3682:
------------------------------------
Summary: drools-compiler jar file dependancy with antlr3.3 creating issue in deployment of EAR. (was: Guvnor drools-compiler jar file dependancy with antlr3.3 creating issue in deployment of EAR.)
> drools-compiler jar file dependancy with antlr3.3 creating issue in deployment of EAR.
> ---------------------------------------------------------------------------------------
>
> Key: JBRULES-3682
> URL: https://issues.jboss.org/browse/JBRULES-3682
> Project: Drools
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Affects Versions: 5.3.0.Final
> Environment: local
> Reporter: Amit Telang
> Labels: maven
>
> Hi, after inclusion guvnor 5.x in application, we are unable to deploy our application through Hudson on our managed server. Issue is related to drools-compiler-5.3.0.Final.jar dependancy with antlr3.3 jar file. If I use exclusion tag to exclude this it excludes all the jar which starts with antlr.
> If I use package exclude to include this antlr3.3 it do not compile. Unable to resolve this small looking issue for a long time.
> Please provide any valuable feedback if someone also faces this issue.
--
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
11 years, 7 months
[JBoss JIRA] (AS7-4692) Review SecurityContext associations
by Darran Lofthouse (JIRA)
Darran Lofthouse created AS7-4692:
-------------------------------------
Summary: Review SecurityContext associations
Key: AS7-4692
URL: https://issues.jboss.org/browse/AS7-4692
Project: Application Server 7
Issue Type: Task
Components: Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.2.0.Alpha1
We should re-review the approach we take for security context association within AS7 containers.
Back at the time of AS 3 it fairly reliable to assume a 1:1 mapping of thread and client with the incoming connection being allocated it's own thread, this is no longer automatically the case and different containers can use different threading models e.g. using Executors to handle asynchronous requests.
The problem with using a ThreadLocal approach is that every time a container diverges from the 1:1 mapping of thread and client that container needs to work around the issue of an invalid SecurityContext association.
One possibility is to pass responsibility for managing the context to the container although this then introduces the question of how it is passed from container to container. This issue needs to consider this further.
Also need to review further how the security context can be created at all entry points to the server and how it can be manually switched now that we use SASL on entry for remote calls we do now have the opportunity for equivalent behaviour at the entry point for both web and ejb type calls - in the past we only had this opportunity for web based calls and would only create a security context on entering the interceptors for the EJB calls.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (AS7-4693) Revisit authenticated user / authorized user split
by Darran Lofthouse (JIRA)
Darran Lofthouse created AS7-4693:
-------------------------------------
Summary: Revisit authenticated user / authorized user split
Key: AS7-4693
URL: https://issues.jboss.org/browse/AS7-4693
Project: Application Server 7
Issue Type: Task
Components: Remoting, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.2.0.Alpha1
When establishing a connection a remote user can specify the user they want to be authorized as which can be different to the user they authenticate as, e.g. a user with appropriate permissions may want to connect as an administrator or a user given access to someone elses account may want to connect as them.
We need to re-visit this including validation that they can connect as the user they are asking to.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (AS7-5047) Allow more control over authentication for server to server communication through remote-outbound-connection
by jaikiran pai (JIRA)
jaikiran pai created AS7-5047:
---------------------------------
Summary: Allow more control over authentication for server to server communication through remote-outbound-connection
Key: AS7-5047
URL: https://issues.jboss.org/browse/AS7-5047
Project: Application Server 7
Issue Type: Feature Request
Components: Security
Affects Versions: 7.1.2.Final (EAP), 7.1.1.Final
Reporter: jaikiran pai
Assignee: Anil Saldhana
Right now for server to server communication via a remote-outbound-connection, we expect a static username to be specified (along with the security realm). User applications which use this remote-outbound-connection, for example an EJB application, do not have much control over the user/pass information, since the username is static. This further acts a drawback since the username that's used to connect to the remote server will be used as the (application) user who invoked the EJB.
It would be good to allow more control over the authentication for the remote-outbound-connection.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months
[JBoss JIRA] (AS7-5901) Connection Reauthentication and Security Propagation
by Darran Lofthouse (JIRA)
Darran Lofthouse created AS7-5901:
-------------------------------------
Summary: Connection Reauthentication and Security Propagation
Key: AS7-5901
URL: https://issues.jboss.org/browse/AS7-5901
Project: Application Server 7
Issue Type: Task
Components: EJB, Remoting, Security
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 7.2.0.Alpha1
This task is a top level task to coordinate the addition of support for switching to different security identities on an existing connection over Remoting.
This is to predominantly cover two major scenarios: -
- Clients using a single connection but require different calls to be executed as different users, in this case the client has the information required to start a new authentication as a different user.
- Server to server communication where the first server has already authenticated a remote user - for this scenario the first server needs a way to tell the second server what identity to run the call as.
The following document is building up the requirements and design considerations and decisions: -
https://community.jboss.org/wiki/ConnectionRe-AuthenticationAndSecurityPr...
--
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
11 years, 7 months
[JBoss JIRA] Created: (JBRULES-3155) Bug with default properties in KnowledgeStoreServiceImpl
by Pavel Sknar (JIRA)
Bug with default properties in KnowledgeStoreServiceImpl
--------------------------------------------------------
Key: JBRULES-3155
URL: https://issues.jboss.org/browse/JBRULES-3155
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.2.0.Final
Reporter: Pavel Sknar
Assignee: Mark Proctor
Priority: Critical
Method setDefaultImplementations() set default properties in configProps (class KnowledgeStoreServiceImpl). mergeConfig() execute after specific properties loaded to configuration. This overlaps specific properties.
[17:08] <pavlz> hi
[17:09] <pavlz> I have bug for you
[17:09] <Rikkola> :(
[17:10] <pavlz> Problem with KnowledgeStoreServiceImpl
[17:10] <pavlz> in org.drools.persistence.jpa
[17:12] <pavlz> default properties merged first in config (in ChainedProperties: this.props.add( 0, properties ))
[17:14] <pavlz> and this overlaps specific properties
[17:15] <pavlz> drools.commandService, drools.timerService and else
[17:15] <pavlz> I have this bug in 5.2.0.Final
[17:23] <conan> pavlz: do you have a fix?
[17:25] <pavlz> No, I see this now
[17:27] <pavlz> but I think: need to create in ChainedProperties new method "setDefaultProperties"
[17:29] <pavlz> and in SessionConfiguration too, to use this method in KnowledgeStoreServiceImpl.mergeConfig()
[17:30] <pavlz> then default properties loaded later
[17:31] <Rikkola> pavlz: best to make a jira about it
[17:31] <Rikkola> https://issues.jboss.org/browse/JBRULES
[17:31] <pavlz> ok
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 7 months