[JBoss JIRA] Created: (JBMETA-305) @Local and @Remote annotation processors should not pick up interfaces of super class of bean class
by jaikiran pai (JIRA)
@Local and @Remote annotation processors should not pick up interfaces of super class of bean class
---------------------------------------------------------------------------------------------------
Key: JBMETA-305
URL: https://jira.jboss.org/browse/JBMETA-305
Project: JBoss Metadata
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ejb
Affects Versions: jboss-metadata-ejb-2.0.0-alpha-20
Reporter: jaikiran pai
Assignee: jaikiran pai
Consider these EJBs:
@Stateless
public class BaseBean implements A
{
...
}
@Local
public interface A
{...
}
@Stateless
public class ChildBean extends BaseBean implements B
{
...
}
@Local
public interface B
{
...
}
In this case, the ChildBean is expected to expose just B as the local business view. It should _not_ expose A as the local business view.
However, our current annotation processors currently don't handle this scenario which breaks the EJB3.1 spec which says:
"4.9.2.1 Session Bean Superclasses:
A session bean class is permitted to have superclasses that are themselves session bean classes. However, there are no special rules that apply to the processing of annotations or the deployment descriptor for this case. For the purposes of processing a particular session bean class, all superclass processing is identical regardless of whether the superclasses are themselves session bean classes. In this regard, the use of session bean classes as superclasses merely represents a convenient use of implementation inheritance, but does not have component inheritance semantics.
As an example, the client views exposed by a particular session bean are not inherited by a subclass that also happens to define a session bean.
@Stateless
public class A implements Foo { ... }
@Stateless
public class B extends A implements Bar { ... }
Assuming Foo and Bar are local business interfaces and there is no associated deployment descriptor, session bean A exposes local business interface Foo and session bean B exposes local business interface Bar, but not Foo."
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 7 months
[JBoss JIRA] Created: (JBMETA-304) Add metadata support for "inherited" atribute of application-exception
by jaikiran pai (JIRA)
Add metadata support for "inherited" atribute of application-exception
----------------------------------------------------------------------
Key: JBMETA-304
URL: https://jira.jboss.org/browse/JBMETA-304
Project: JBoss Metadata
Issue Type: Task
Security Level: Public (Everyone can see)
Components: ejb
Reporter: jaikiran pai
Assignee: jaikiran pai
EJB3.1 introduces a "inherited" attribute for application-exception element in ejb-jar.xml:
<xsd:complexType name="application-exceptionType">
<xsd:annotation>
<xsd:documentation>
The application-exceptionType declares an application
exception. The declaration consists of:
- the exception class. When the container receives
an exception of this type, it is required to
forward this exception as an applcation exception
to the client regardless of whether it is a checked
or unchecked exception.
- an optional rollback element. If this element is
set to true, the container must rollback the current
transaction before forwarding the exception to the
client. If not specified, it defaults to false.
- an optional inherited element. If this element is
set to true, subclasses of the exception class type
are also automatically considered application
exceptions (unless overriden at a lower level).
If set to false, only the exception class type is
considered an application-exception, not its
exception subclasses. If not specified, this
value defaults to true.
</xsd:documentation>
</xsd:annotation>
<xsd:sequence>
<xsd:element name="exception-class"
type="javaee:fully-qualified-classType"/>
<xsd:element name="rollback"
type="javaee:true-falseType"
minOccurs="0"/>
<xsd:element name="inherited"
type="javaee:true-falseType"
minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="id"
type="xsd:ID"/>
</xsd:complexType>
The metadata schema mapping class should support this new attribute.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 7 months
[JBoss JIRA] Updated: (EJBTHREE-558) Memory Leak in AuthenticationInterceptor
by Pranay Ahlawat (JIRA)
[ https://jira.jboss.org/browse/EJBTHREE-558?page=com.atlassian.jira.plugin... ]
Pranay Ahlawat updated EJBTHREE-558:
------------------------------------
Attachment: SecurityAssociation.java.patch
Still see this issue in Jboss 4.2.3.GA - running automated calls leads to a OOM exception in about 3 hours.
I have put in a work around by reimplementing the security stack a sweeping it on every call to push(). Attaching a patch to the bug.
> Memory Leak in AuthenticationInterceptor
> ----------------------------------------
>
> Key: EJBTHREE-558
> URL: https://jira.jboss.org/browse/EJBTHREE-558
> Project: EJB 3.0
> Issue Type: Bug
> Components: Security
> Reporter: Luigi Putanesca
> Assignee: Scott Stark
> Fix For: Branch_4_2
>
> Attachments: SecurityAssociation.java.patch
>
>
> In org.jboss.aspects.security.AuthenticationInterceptor.invoke(), the finally clause sets SecurityAssociation principal and credential to null. Although I think this was intended to clear any login, what it does is add a SubjectContext with principal = null to the SecurityAssociation.subjectContext stack. This entry is never removed and each time this block of code is invoked, it adds another item to the stack. The stack grows and grows. I think this is mainly a problem when restorePrincipal is true.
> What also compounds the problem is that if users were logged in by application code and never logged out, they remain on the stack in this thread indefinitely. Not only is this a problem with the stack growing, it is also a security vulnerability because it means there are still authenticated users on the stack that can be restored by another client or process using the same thread.
> My initial thought on how to fix this was to call the SecurityPrincipal.clear() method in place of setting the principal to null. However I'm not sure it is safe to call clear in that particular place possibly resulting in authentication errors if users are logged out prematurely. Additionally, the 'if' clause there means the code is not always executed so in some cases the clear will not occur. I think the clear needs to be called at some point but I don't know the code well enough to know where the appropriate place would be.
> Here is the snippet of code in question. See the finally clause:
> /**
> * Authenticates the caller using the principal and credentials in the
> * Infocation if thre is a security manager and an invcocation method.
> */
> public Object invoke(org.jboss.aop.joinpoint.Invocation invocation) throws Throwable
> {
> try
> {
> authenticate(invocation);
> }
> catch (GeneralSecurityException gse)
> {
> handleGeneralSecurityException(gse);
> }
> Object oldDomain = SecurityContext.currentDomain.get();
> try
> {
> SecurityContext.currentDomain.set(authenticationManager);
> return invocation.invokeNext();
> }
> finally
> {
> SecurityContext.currentDomain.set(oldDomain);
> // so that the principal doesn't keep being associated with thread if the thread is pooled
> SecurityAssociation.popSubjectContext();
> if (invocation.getMetaData("security", "principal") != null)
> {
> SecurityAssociation.setPrincipal(null);
> SecurityAssociation.setCredential(null);
> }
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 7 months
[JBoss JIRA] Moved: (JBAS-8533) Web Application Context is not registering ComponentType{type=MBean, subtype=WebApplicationManager} in ProfileService when JBossWeb is using host name other than localhost
by Larry O'Leary (JIRA)
[ https://jira.jboss.org/browse/JBAS-8533?page=com.atlassian.jira.plugin.sy... ]
Larry O'Leary moved JBPAPP-5261 to JBAS-8533:
---------------------------------------------
Project: JBoss Application Server (was: JBoss Enterprise Application Platform)
Key: JBAS-8533 (was: JBPAPP-5261)
Affects Version/s: 6.0.0.M5
(was: EAP 5.0.0)
(was: EWP 5.0.0)
(was: EAP 6.0.0)
(was: EAP_EWP 5.1.0)
(was: EAP 5.0.1)
(was: EWP 5.0.1)
(was: EAP_EWP 5.1.1)
(was: EAP 5.1.0 Post Release)
(was: EAP/EWP 5 RHEL-6 RPMs)
Component/s: ProfileService
(was: System)
Fix Version/s: TBD
(was: TBD)
> Web Application Context is not registering ComponentType{type=MBean, subtype=WebApplicationManager} in ProfileService when JBossWeb is using host name other than localhost
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBAS-8533
> URL: https://jira.jboss.org/browse/JBAS-8533
> Project: JBoss Application Server
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: ProfileService
> Affects Versions: 6.0.0.M5
> Environment: Tested using EAP 5.0.0, 5.0.1, 5.1.0, AS 6.0.0 M5, EWP 5.0.1
> Reporter: Larry O'Leary
> Assignee: Jason Greene
> Fix For: TBD
>
>
> When JBossWeb is using host name (defaultHost) of localhost all seems to work fine. But when JBossWeb is using host name other than localhost, we seem to be missing the component type MBean with a subtype of WebApplicationManager for all deployed WARs within the ProfileService.
> The result is that the Web Application Contexts for the WARs (i.e. ROOT.war) showing a state of DOWN in admin-console when using a host other than localhost. -- admin-console -- <hostname> -> JBossAS Servers -> JBoss EAP 5 (default) -> Applications -> Web Application (WAR)s -> ROOT.war -> Web Application Contexts -> //<hostname>/
> Output from ProfileServiceDebugServlet for ROOT.war on localhost and on non-localhost is as follows:
> EAP 5.1.0 - jmx-console/ProfileServiceDebugServlet
> Host: localhost
> http://localhost:8080/jmx-console/ProfileServiceDebugServlet
> ROOT.war:
> ManagedDeployment: //localhost/; state: STARTED
> +++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/, type=(ComponentType{type=MBean, subtype=WebApplication}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//localhost/, attachment: null
> ++++++ properties: [saveConfig, managedResource, manager, cacheTTL, engineName, startTime, configFile, realm, staticResources, antiJARLocking, stateManageable, compilerClasspath, servlets, valveObjectNames, loader, caseSensitive, processingTime, useNaming, deploymentDescriptor, cacheObjectMaxSize, override, namingContextListener, cachingAllowed, swallowOutput, privileged, parentClassLoader, unloadDelay, docBase, eventProvider, workDir, javaVMs, statisticsProvider, tldScanTime, state, children, modelerType, delegate, mappingObject, startupTime, crossContext, welcomeFiles, logger, path, cookies, reloadable, defaultContextXml, objectName, antiResourceLocking, cacheMaxSize, defaultWebXml, server, allowLinking]
> +++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/,j2eeType=Servlet,name=Status Servlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/,j2eeType=Servlet,name=Status Servlet, attachment: null
> ++++++ properties: [minTime, eventProvider, objectName, statisticsProvider, processingTime, engineName, maxTime, errorCount, modelerType, loadTime, stateManageable, classLoadTime, requestCount]
> +++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/,j2eeType=Servlet,name=jsp, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/,j2eeType=Servlet,name=jsp, attachment: null
> ++++++ properties: [minTime, eventProvider, objectName, statisticsProvider, processingTime, engineName, maxTime, errorCount, modelerType, loadTime, stateManageable, classLoadTime, requestCount]
> +++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/,j2eeType=Servlet,name=default, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//localhost/,j2eeType=Servlet,name=default, attachment: null
> ++++++ properties: [minTime, eventProvider, objectName, statisticsProvider, processingTime, engineName, maxTime, errorCount, modelerType, loadTime, stateManageable, classLoadTime, requestCount]
> +++ ManagedComponent(name=jboss.web:host=localhost,path=/,type=Manager, type=(ComponentType{type=MBean, subtype=WebApplicationManager}), compName=jboss.web:host=localhost,path=/,type=Manager, attachment: null
> ++++++ properties: [sessionMaxAliveTime, duplicates, maxInactiveInterval, entropy, activeSessions, sessionCounter, sessionAverageAliveTime, processingTime, sessionIdLength, modelerType, processExpiresFrequency, algorithm, maxActive, distributable, maxActiveSessions, randomFile, name, rejectedSessions, expiredSessions, pathname, className]
> EAP 5.1.0 - jmx-console/ProfileServiceDebugServlet
> Host: loleary
> http://localhost:8080/jmx-console/ProfileServiceDebugServlet
> ROOT.war:
> ManagedDeployment: //loleary/; state: STARTED
> +++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//loleary/, type=(ComponentType{type=MBean, subtype=WebApplication}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,j2eeType=WebModule,name=//loleary/, attachment: null
> ++++++ properties: [saveConfig, managedResource, manager, cacheTTL, engineName, startTime, configFile, realm, staticResources, antiJARLocking, stateManageable, compilerClasspath, servlets, valveObjectNames, loader, caseSensitive, processingTime, useNaming, deploymentDescriptor, cacheObjectMaxSize, override, namingContextListener, cachingAllowed, swallowOutput, privileged, parentClassLoader, unloadDelay, docBase, eventProvider, workDir, javaVMs, statisticsProvider, tldScanTime, state, children, modelerType, delegate, mappingObject, startupTime, crossContext, welcomeFiles, logger, path, cookies, reloadable, defaultContextXml, objectName, antiResourceLocking, cacheMaxSize, defaultWebXml, server, allowLinking]
> +++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//loleary/,j2eeType=Servlet,name=Status Servlet, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//loleary/,j2eeType=Servlet,name=Status Servlet, attachment: null
> ++++++ properties: [minTime, eventProvider, objectName, statisticsProvider, processingTime, engineName, maxTime, errorCount, modelerType, loadTime, stateManageable, classLoadTime, requestCount]
> +++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//loleary/,j2eeType=Servlet,name=jsp, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//loleary/,j2eeType=Servlet,name=jsp, attachment: null
> ++++++ properties: [minTime, eventProvider, objectName, statisticsProvider, processingTime, engineName, maxTime, errorCount, modelerType, loadTime, stateManageable, classLoadTime, requestCount]
> +++ ManagedComponent(name=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//loleary/,j2eeType=Servlet,name=default, type=(ComponentType{type=MBean, subtype=Servlet}), compName=jboss.web:J2EEApplication=none,J2EEServer=none,WebModule=//loleary/,j2eeType=Servlet,name=default, attachment: null
> ++++++ properties: [minTime, eventProvider, objectName, statisticsProvider, processingTime, engineName, maxTime, errorCount, modelerType, loadTime, stateManageable, classLoadTime, requestCount]
> When accessing the Web Application Contexts for ROOT.war from admin-console the following error is captured in server.log:
> ERROR [MeasurementManager] Could not get measurement values
> java.lang.IllegalStateException: Failed to find [ComponentType{type=MBean, subtype=WebApplicationManager}] ManagedComponent named [jboss.web:host=loleary,path=/,type=Manager].
> at org.rhq.plugins.jbossas5.ManagedComponentComponent.getManagedComponent(ManagedComponentComponent.java:365)
> at org.rhq.plugins.jbossas5.ManagedComponentComponent.getValues(ManagedComponentComponent.java:227)
> at org.rhq.plugins.jbossas5.WebApplicationContextComponent.getValues(WebApplicationContextComponent.java:156)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:616)
> at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
> at java.lang.Thread.run(Thread.java:636)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years, 7 months