[JBoss JIRA] Created: (JBAS-4858) SecurityDeployer changes with metadata
by Anil Saldhana (JIRA)
SecurityDeployer changes with metadata
--------------------------------------
Key: JBAS-4858
URL: http://jira.jboss.com/jira/browse/JBAS-4858
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Security
Affects Versions: JBossAS-5.0.0.Beta2
Reporter: Anil Saldhana
Assigned To: Anil Saldhana
Fix For: JBossAS-5.0.0.Beta3
The Security Deployer needs to be changed as per the following rant from Adrian
=============================
To me this is the wrong approach anyway.
There shouldn't be any code that does
if (ejbdeployment)
doThis();
else if (webdeployment)
doThat();
else if (unknowntype) // OOPS (pun intended ;-)
cantDoIt();
The webservice deployers should be working off some generic metadata that triggers them to operate.
Then each type of deployment can populate that metadata to say "I want a webservice endpoint for this".
This is a seperate deployer for each type we know how to map to a webservice it takes the ejb/web/other metadata and maps or bridges it to the webservice metadata.
It shouldn't just be restricted to ejbs and wars.
e.g. An MBean should be capable of being an endpoint if there is a deployer that creates the relevant metadata attachment from say a META-INF/jboss-webservice.xml in the sar.
The security deployers take the same brain dead (non object orientated) approach.
============================================================
--
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
18 years, 5 months
[JBoss JIRA] Created: (JBRULES-1229) separate compile classpath from class loader's getResource() facility
by Godmar Back (JIRA)
separate compile classpath from class loader's getResource() facility
---------------------------------------------------------------------
Key: JBRULES-1229
URL: http://jira.jboss.com/jira/browse/JBRULES-1229
Project: JBoss Rules
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Drl Parser/Builder
Affects Versions: 4.0.1
Reporter: Godmar Back
Assigned To: Mark Proctor
Priority: Minor
The current compiler relies on being able to read the bytecode for referred-to classes as a resource. For instance, to resolve the name "org.jboss.pkg.Clazz", a resource "org/jboss/pkg/Clazz.class" must be accessible.
This requirement is not part of the public interface of a class loader. Read the Sun Java documentation, which states: "A resource is some data (images, audio, text, etc) that can be accessed by class code in a way that is independent of the location of the code."
Although, this approach works by coincidence since most class loaders in fact return this resource - at least class loaders that don't do anything fancy to bytecode before defining classes, a more principled solution would separate the classpath used by the runtime engine from the classpath used by the compiler. (This is, for instance, what javac or practically all command-line compilers do.)
My suggestion is to either document this dependency on this particular class loader behavior, or, better, introduce a specific type resolver for the compilation process that is separated from the class loader's resource loading mechanism.
--
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
18 years, 5 months