[JBoss JIRA] Created: (JBRULES-1214) drools-server should not have .settings commited into svn
by Geoffrey De Smet (JIRA)
drools-server should not have .settings commited into svn
---------------------------------------------------------
Key: JBRULES-1214
URL: http://jira.jboss.com/jira/browse/JBRULES-1214
Project: JBoss Rules
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-brms
Affects Versions: 4.0.1
Reporter: Geoffrey De Smet
Assigned To: Mark Proctor
Priority: Trivial
Fix For: FUTURE
See JBRULES-834.
As far as I can tell, the commit of /drools-server/.settings is an error because the other server modules explicitly svn:ignore the .settings directory.
The svn ignore was probably forgotten, which might have given our good friend eclipse the opportunity to commit it.
I could be wrong though.
If I am right though, the .settings directory should be deleted in svn, which will cause havoc when everyone updates who's relying on .settings in drools-server, and the svn:ignore should be edited to contain these 3 items:
.metadata
.settings
.wtpmodules
This way it uses standardized svn ignores just like the other modules.
--
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
17 years, 4 months
[JBoss JIRA] Created: (JBAS-5182) Retire EJB3 JaccHelper
by Anil Saldhana (JIRA)
Retire EJB3 JaccHelper
----------------------
Key: JBAS-5182
URL: http://jira.jboss.com/jira/browse/JBAS-5182
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: EJB3, Security
Affects Versions: JBossAS-5.0.0.Beta3
Reporter: Anil Saldhana
Assigned To: Anil Saldhana
Priority: Critical
Fix For: JBossAS-5.0.0.CR1
The entire EJB3 Jacc Layer needs to go. The Permissions creation will be done via a separate deployer working on the Metadata. The Policy enforcement will be done by the security layer. We have already consolidated the enforcement for web and ejb2 layers.
--
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
17 years, 4 months
[JBoss JIRA] Created: (JBMESSAGING-1197) support HTTP transport
by Jeff Mesnil (JIRA)
support HTTP transport
----------------------
Key: JBMESSAGING-1197
URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1197
Project: JBoss Messaging
Issue Type: Sub-task
Components: JMS Remoting
Reporter: Jeff Mesnil
Assigned To: Jeff Mesnil
Fix For: 2.0.0 Alpha
the new remoting code based on MINA currently supports only TCP transport.
It must also support HTTP transport.
MINA provides an HTTP package we can use for both the JMS clients (send requests/receive responses)
and the JMS servers (receive request/send response).
Message delivery must also be taken into account. The client can use polling (and remains a simple HTTP client). However since MINA code is used on both the client and ther server, we need to check if we can
send HTTP requests to the client on the same TCP connection (the ideabeing that we MUST NOT open a server connection on the client in any way)
--
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
17 years, 4 months