May 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Closed: (JBAOP-85) Annotation compiler should support imports

by Kabir Khan (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-85?page=all ] Kabir Khan closed JBAOP-85. --------------------------- Resolution: Out of Date > Annotation compiler should support imports > ------------------------------------------ > > Key: JBAOP-85 > URL: http://jira.jboss.com/jira/browse/JBAOP-85 > Project: JBoss AOP > Issue Type: Task > Reporter: Adrian Brock > Assigned To: Bill Burke > > The annotation should process imports, i.e. > import org.jboss.security.Security; > /** > * @@Security > */ > instead of > /** > * @(a)org.jboss.security.Security > */ -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBAOP-126) Retain ProtectionDomain for instrumented classes

by Kabir Khan (JIRA)

[ http://jira.jboss.com/jira/browse/JBAOP-126?page=all ] Kabir Khan closed JBAOP-126. ---------------------------- Resolution: Out of Date Scott did this ages ago > Retain ProtectionDomain for instrumented classes > ------------------------------------------------ > > Key: JBAOP-126 > URL: http://jira.jboss.com/jira/browse/JBAOP-126 > Project: JBoss AOP > Issue Type: Bug > Reporter: Scott M Stark > > Sorry I wasn't clearer in my original post. It's been a while since I looked at this issue. > My particular problem is that the generated field wrapper inner classes don't get assigned the correct protection domain. Here's a stack trace that shows the problem occuring. > | getDefaultDomain():1583, ClassLoader.java > | preDefineClass():483, ClassLoader.java > | defineClass():614, ClassLoader.java > | defineClass():465, ClassLoader.java > | invoke0():-1, NativeMethodAccessorImpl.java > | invoke():39, NativeMethodAccessorImpl.java > | invoke():25, DelegatingMethodAccessorImpl.java > | invoke():585, Method.java > | toClass():52, StandaloneClassPool.java > | toClass():962, CtClass.java > | compileOrLoadClass():119, TransformerCommon.java > | createOptimizedInvocationClass():572, FieldAccessTransformer.java > | buildOptimizedReadWrapper():358, FieldAccessTransformer.java > | buildOptimizedWrappers():342, FieldAccessTransformer.java > | buildFieldWrappers():232, FieldAccessTransformer.java > | buildFieldWrappers():65, FieldAccessTransformer.java > | transform():592, Instrumentor.java > | translate():572, AspectManager.java > | transform():490, AspectManager.java > | aspectTransform():100, AopAgent.java > | transform():141, AopAgent.java > | transform():122, TransformerManager.java > | transform():155, InstrumentationImpl.java > | defineClass1():-1, ClassLoader.java > | defineClass():620, ClassLoader.java > | defineClass():320, BaseURLClassLoader.java > | access$000():38, BaseURLClassLoader.java > | run():108, BaseURLClassLoader.java > | run():98, BaseURLClassLoader.java > | doPrivileged():-1, AccessController.java > | findClass():96, BaseURLClassLoader.java > | findClassInternal():168, BaseClassLoader.java > | findClassInternal():146, BaseClassLoader.java > | findClassInternal():49, FrameworkClassLoader.java > | loadClass():280, BaseClassLoader.java > | loadClass():251, ClassLoader.java > | loadClassInternal():319, ClassLoader.java > | initialiseDomains():117, DomainManagerImpl.java > | <init>():78, DomainManagerImpl.java > | start():153, FrameworkController.java > | invoke0():-1, NativeMethodAccessorImpl.java > | invoke():39, NativeMethodAccessorImpl.java > | invoke():25, DelegatingMethodAccessorImpl.java > | invoke():585, Method.java > | initialiseFramework():366, FrameworkLoader.java > | main():463, FrameworkLoader.java > | > The toClass method of StandaloneClassPool does the following: > | Class cl = Class.forName("java.lang.ClassLoader"); > | java.lang.reflect.Method method > | = cl.getDeclaredMethod("defineClass", > | new Class[]{String.class, byte[].class, > | int.class, int.class}); > | > My classloader doesn't get a chance to define the class, causing the field wrappers to be assigned a default protection domain. > So, what's actually needed is for the class pool to use the correct classloader when calling defineClass. > Hope that helps. > Tim. -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAOP-479) Enable org.jboss.test.aop.proxy.ProxyTestCase(jdk14).testAnnotationsExistInProxy

by Kabir Khan (JIRA)

Enable org.jboss.test.aop.proxy.ProxyTestCase(jdk14).testAnnotationsExistInProxy -------------------------------------------------------------------------------- Key: JBAOP-479 URL: http://jira.jboss.com/jira/browse/JBAOP-479 Project: JBoss AOP Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Kabir Khan Assigned To: Kabir Khan Fix For: 2.0.0.GA public void testAnnotationsExistInProxy() throws Exception { //THis test fails if we run with jboss retro try { Class.forName("org.jboss.lang.ClassRedirects"); System.out.println("IGNORING TEST ON JDK 1.4"); return; } catch(Exception ignoreWeAreRunningWithJDK5) { } This *might* be deferrable to a later release since it is a JDK 1.4 thing and AOP 2.0 is targeting AS 5 (JDK 5) -- 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, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (HIBERNATE-70) Interceptor.onLoad not called from EJB3 event listeners

by Wise Guy (JIRA)

Interceptor.onLoad not called from EJB3 event listeners ------------------------------------------------------- Key: HIBERNATE-70 URL: http://jira.jboss.com/jira/browse/HIBERNATE-70 Project: Hibernate Issue Type: Bug Environment: JBoss 4.2.1.GA, Hibernate 3.2.1 SP1, Seam 1.2.1.GA Reporter: Wise Guy Assigned To: Steve Ebersole Priority: Minor I have a Seam 1.2.1.GA application. I installed an implementation of the interface org.hibernate.Interceptor and declared it in the persistence.xml as hibernate.ejb.interceptor. The interceptor works (ex.: onSave(), onFlushDirty()) except that onLoad() doesn't get called. I guess that there is a problem with the DefaultPreLoadEventListener who should call my interceptor. He is defined in org.hibernate.event.EventListeners as a default listener to the event "pre-load". I also found that the DefaultLoadEventListener.onLoad() gets called but DefaultPreLoadEventListener.onPreLoad() not. Does that have something to do with EJB3? I have found that there is an EJB3PostLoadEventListener that is used when run under JPA and the default listeners are overridden. -- 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, 2 months

2
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2012) IE6 SSL iframe security warnings

by Ryan Carmichael (JIRA)

IE6 SSL iframe security warnings -------------------------------- Key: JBPORTAL-2012 URL: http://jira.jboss.com/jira/browse/JBPORTAL-2012 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal Core, Portal Security, Portal Web Affects Versions: 2.6.4 Final Environment: Internet Explorer 6 Reporter: Ryan Carmichael Assigned To: Julien Viet IE6 displayed warning "This page contains both secure and nonsecure items" appears on every page when using SSL. This seems to be cause by IE6 not handling iframe src set to "". The fix is: --- server/default/deploy/jboss-portal.sar/portal-core.war/layouts/common/modal.jsp change iframe src="" to iframe src="javascript:''" --- --- server\default\deploy\jboss-portal.sar\portal-core.war\WEB-INF\jsp\header\header.jsp change <script type="text/javascript"> //we don't need the iframe/modal if logged in document.getElementById('loginIframe').src = ''; </script> to <script type="text/javascript"> //we don't need the iframe/modal if logged in document.getElementById('loginIframe').src = "javascript:''"; </script> --- -- 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, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1342) Cleanup JNDI injectors

by Carlo de Wolf (JIRA)

Cleanup JNDI injectors ---------------------- Key: EJBTHREE-1342 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1342 Project: EJB 3.0 Issue Type: Task Reporter: Carlo de Wolf Assigned To: Carlo de Wolf Fix For: AS 5.0.0.CR1 -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1299) Stateful bean must not be discarded when a transaction attribute violation is detected

by Carlo de Wolf (JIRA)

Stateful bean must not be discarded when a transaction attribute violation is detected -------------------------------------------------------------------------------------- Key: EJBTHREE-1299 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1299 Project: EJB 3.0 Issue Type: Bug Reporter: Carlo de Wolf Assigned To: Carlo de Wolf Priority: Critical Fix For: AS 5.0.0.CR1 -- 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, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-976) CLONE [JBREM-912] - Remove stacktrace when SSLSocketBuilder.createSSLSocketFactory() fails

by Ron Sigal (JIRA)

CLONE [JBREM-912] - Remove stacktrace when SSLSocketBuilder.createSSLSocketFactory() fails ------------------------------------------------------------------------------------------ Key: JBREM-976 URL: http://jira.jboss.com/jira/browse/JBREM-976 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.2.0.SP4 Reporter: Ron Sigal Assigned To: Ron Sigal Priority: Minor Fix For: 2.2.2.SP7 Remoting is too noisy in places when org.jboss.remoting.security.SSLSocketBuilder.createSSLSocketFactory() fails. In particular, org.jboss.remoting.transport.http.ssl.HTTPSClientInvoker.createSocketFactory() org.jboss.remoting.transport.sslbisocket.BisocketClientInvoker.createSocketFactory() org.jboss.remoting.transport.sslbisocket.BisocketServerInvoker.createSocketFactory() org.jboss.remoting.transport.bisocket.SocketClientInvoker.createSocketFactory() print stacktraces at ERROR log level. It would be better if they just printed a message at ERROR level and saved the stacktrace for DEBUG level. -- 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, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1352) Use JBoss Security 2.0.2.CR1

by Anil Saldhana (JIRA)

Use JBoss Security 2.0.2.CR1 ---------------------------- Key: EJBTHREE-1352 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1352 Project: EJB 3.0 Issue Type: Task Components: Security Affects Versions: AS 5.0.0.Beta4 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: AS 5.0.0.CR1 No code change. If there is any issue, revert to either 2.0.2.Beta7 or 2.0.2.Beta6 AS5 is using 2.0.2.CR1 -- 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, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMETA-38) Expand determineResolvedJndiName behavior to accept iface + ifaceType

by Scott M Stark (JIRA)

Expand determineResolvedJndiName behavior to accept iface + ifaceType --------------------------------------------------------------------- Key: JBMETA-38 URL: http://jira.jboss.com/jira/browse/JBMETA-38 Project: JBoss Metadata Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 1.0.0.Beta14 Reporter: Scott M Stark Assigned To: Scott M Stark In order for the jndi name behavior to be fully externalized in the DefaultJndiBindingPolicy, the DefaultJndiBindingPolicy method: getJndiName(EjbDeploymentSummary summary, String iface) needs to become: getJndiName(EjbDeploymentSummary summary, String iface, KnownInterfaceType ifaceType) where KnownInterfaceType is an enum of {LocalHome, RemoteHome, BusinessLocal, BusinessRemote, Unknown} and the JBossEnterpriseBeanMetaData.determineResolvedJndiName(String iface, DefaultJndiBindingPolicy defaultPolicy) needs to map iface onto a KnownInterfaceType based on the metadata for the bean. -- 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, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2008