July 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Deleted: (JBMICROCONT-317) AbstractTypeMetaData should mask the MetaData

by Kabir Khan (JIRA)

[ https://jira.jboss.org/jira/browse/JBMICROCONT-317?page=com.atlassian.jir... ] Kabir Khan deleted JBMICROCONT-317: ----------------------------------- > AbstractTypeMetaData should mask the MetaData > --------------------------------------------- > > Key: JBMICROCONT-317 > URL: https://jira.jboss.org/jira/browse/JBMICROCONT-317 > Project: JBoss MicroContainer > Issue Type: Feature Request > Reporter: Kabir Khan > Assignee: Kabir Khan > > and AOPConstructorJoinPoint should delegate to the default ConstructorJoinPoint if there is no metadata on the stack. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
0
0 / 0

[JBoss JIRA] Created: (JBMICROCONT-317) AbstractTypeMetaData should mask the MetaData

by Kabir Khan (JIRA)

AbstractTypeMetaData should mask the MetaData --------------------------------------------- Key: JBMICROCONT-317 URL: https://jira.jboss.org/jira/browse/JBMICROCONT-317 Project: JBoss MicroContainer Issue Type: Feature Request Components: AOP, Kernel Reporter: Kabir Khan Assignee: Kabir Khan Fix For: JBossMC.2.0.0.CR1 and AOPConstructorJoinPoint should delegate to the default ConstructorJoinPoint if there is no metadata on the stack. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBCL-20) Don't use CopyOnWriteArraySet for caching and blacklisting

by Adrian Brock (JIRA)

Don't use CopyOnWriteArraySet for caching and blacklisting ---------------------------------------------------------- Key: JBCL-20 URL: https://jira.jboss.org/jira/browse/JBCL-20 Project: JBoss ClassLoader Issue Type: Task Components: ClassLoader Affects Versions: JBossCL.2.0.0.Beta12 Reporter: Adrian Brock Assignee: Adrian Brock Fix For: JBossCL.2.0.0.CR1 According to the javadoc CopyOnWriteArraySet is not designed for large sets. I'm seeing slow calls to blacklist.contains(className) in JBossAS Instead use a ConcurrentHashMap (effectively only the key side). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMETA-80) Field-level @Resource annotation for SessionContext not placed in metadata

by Andrew Lee Rubinger (JIRA)

Field-level @Resource annotation for SessionContext not placed in metadata -------------------------------------------------------------------------- Key: JBMETA-80 URL: https://jira.jboss.org/jira/browse/JBMETA-80 Project: JBoss Metadata Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.0.0.Beta30 Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger Given a simple EJB: @Stateless @Local(BusinessInterface.class) public class SessionContextAnnotatedResourceBean implements BusinessInterface { @Resource public SessionContext context; } ...JBoss50Creator is not returning a Resource Reference. Perhaps I'm looking in the wrong places, but when running EJB3 Embedded in EJB3 Core Unit Tests, this value is not getting injected. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

2
6
0 / 0

[JBoss JIRA] Created: (JBAS-5574) Don't log an error for BMT Stateful not completing their transactions

by Adrian Brock (JIRA)

Don't log an error for BMT Stateful not completing their transactions --------------------------------------------------------------------- Key: JBAS-5574 URL: http://jira.jboss.com/jira/browse/JBAS-5574 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: EJB2 Affects Versions: JBossAS-4.2.2.GA Reporter: Adrian Brock Assigned To: Adrian Brock Fix For: JBossAS-5.0.0.CR1, JBossAS-4.2.3.GA BMT Stateful Session Beans are allowed to hold their user transactions open between invocations. JBAS-4487 added some log message which is wrong. See EJB-2.1 17.3.3 This doesn't actually cause a problem, just some noisy logging. -- 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

16 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBPORTAL-2082) ReadOnlyException - sample weather - jbp 2.7.0.ALPHA

by ced ced (JIRA)

ReadOnlyException - sample weather - jbp 2.7.0.ALPHA ---------------------------------------------------- Key: JBPORTAL-2082 URL: https://jira.jboss.org/jira/browse/JBPORTAL-2082 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Reporter: ced ced I test the sample weather with jbossportal 2.7.0.ALPHA, I change the zip code and I have this exception : I search in the source code and I looked in the class AbstractInstanceDefinition that the method getAccessMode() return always the read-only value. Why the class PersistentInstanceDefinition does not implement in this method getAccessMode() ? 2008-07-23 22:24:53,484 ERROR [STDERR] javax.portlet.ReadOnlyException: Key RssXml cannot be written 2008-07-23 22:24:53,484 ERROR [STDERR] at org.jboss.portal.portlet.impl.jsr168.api.PortletPreferenc esImpl.setValue(PortletPreferencesImpl.java:250) 2008-07-23 22:24:53,484 ERROR [STDERR] at org.jboss.portal.core.samples.weather.WeatherPortlet.proc essAction(WeatherPortlet.java:211) 2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl $Invoker.doFilter(PortletContainerImpl.java:557) 2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.portal.portlet.impl.jsr168.api.FilterChainImpl. doFilter(FilterChainImpl.java:109) 2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.portal.portlet.impl.jsr168.api.FilterChainImpl. doFilter(FilterChainImpl.java:72) 2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.portal.portlet.impl.jsr168.PortletContainerImpl .dispatch(PortletContainerImpl.java:505) 2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.portal.portlet.container.ContainerPortletDispat cher.invoke(ContainerPortletDispatcher.java:42) 2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.portal.portlet.PortletInvokerInterceptor.invoke (PortletInvokerInterceptor.java:82) 2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.portal.core.aspects.portlet.TransactionIntercep tor.org$jboss$portal$core$aspects$portlet$TransactionInterceptor$invokeNotSupported$aop(TransactionI nterceptor.java:97) 2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.portal.core.aspects.portlet.TransactionIntercep tor$invokeNotSupported_N6922078035659651697.invokeNext(TransactionInterceptor$invokeNotSupported_N69 22078035659651697.java) 2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java: 66) 2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.aspects.tx.TxInterceptor$NotSupported.invoke(Tx Interceptor.java:112) 2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.portal.core.aspects.portlet.TransactionIntercep tor$invokeNotSupported_N6922078035659651697.invokeNext(TransactionInterceptor$invokeNotSupported_N69 22078035659651697.java) 2008-07-23 22:24:53,500 ERROR [STDERR] at org.jboss.aspects.tx.TxPolicy.invokeInNoTx(TxPolicy.java: 66) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
2
0 / 0

[JBoss JIRA] Created: (JBAS-4872) Invalid URI if the jboss.bind.address is IPv6

by Takayoshi Kimura (JIRA)

Invalid URI if the jboss.bind.address is IPv6 --------------------------------------------- Key: JBAS-4872 URL: http://jira.jboss.com/jira/browse/JBAS-4872 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Remoting Affects Versions: JBossAS-4.2.1.GA Reporter: Takayoshi Kimura Assigned To: Ron Sigal JBossRemoting uses jboss.bind.address in URI like the following: socket://${jboss.bind.address}:4446/?datatype=invocation However, if the jboss.bind.address is IPv6, it should be inside of square brackets. Invalid URI socket://::1:4446/?datatype=invocation Valid URI socket://[::1]:4446/?datatype=invocation To reproduce this issue: Run JBoss instance by the following commend on IPv6 enabled system. $ ./run.sh -c default -b ::1 Workaround: Edit JBossRemoting URL not to use jboss.bind.address. Note: IPv6 address cannot be parsed with JBossRemoting 2.2.1.GA bundled in 4.2.1.GA. IPv6 parsing needs updated version of JBossRemoting. http://jira.jboss.com/jira/browse/JBREM-645 -- 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

16 years, 2 months

2
4
0 / 0

[JBoss JIRA] Created: (JBAS-4669) Port ClusteredSingleSignOn testNoAuthSingleSignOn test to trunk

by Brian Stansberry (JIRA)

Port ClusteredSingleSignOn testNoAuthSingleSignOn test to trunk --------------------------------------------------------------- Key: JBAS-4669 URL: http://jira.jboss.com/jira/browse/JBAS-4669 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Clustering, Test Suite Reporter: Brian Stansberry Assigned To: Brian Stansberry Priority: Minor Fix For: JBossAS-5.0.0.CR1 Port from Branch_4_2. -- 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

16 years, 2 months

1
3
0 / 0

[JBoss JIRA] Created: (JBAS-4616) NamingContext lookupLink() does not acquire stub to server Naming service

by Brian Stansberry (JIRA)

NamingContext lookupLink() does not acquire stub to server Naming service ------------------------------------------------------------------------- Key: JBAS-4616 URL: http://jira.jboss.com/jira/browse/JBAS-4616 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Naming Affects Versions: JBossAS-4.2.1.GA, JBossAS-4.2.0.GA, JBossAS-5.0.0.Beta2, JBossAS-4.0.5.GA Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: JBossAS-5.0.0.Beta3 org.jnp.interfaces.NamingContext.lookupLink(Name) does not invoke the checkRef() method before invoking on the stub to the server-side Naming object. The checkRef() method is what actually contacts the JNDI server to download the stub.. Result of this is an NPE will be thrown if an earlier call hasn't downloaded the stub before lookupLink() is called. -- 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

16 years, 2 months

1
8
0 / 0

[JBoss JIRA] Created: (JBMETA-79) determineResolvedJndiName for a 2x ejb home returns

by Scott M Stark (JIRA)

determineResolvedJndiName for a 2x ejb home returns ---------------------------------------------------- Key: JBMETA-79 URL: https://jira.jboss.org/jira/browse/JBMETA-79 Project: JBoss Metadata Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.0.0.Beta30 Reporter: Scott M Stark Assignee: Scott M Stark Fix For: 1.0.0.CR1 If one calls JBossEnterpriseBeanMetaData.determineResolvedJndiName(String) with an ejb2x remote home iface, for an TestBean ejb in an appclient_dep_compat12_13.ear, the resulting home jndi name is appclient_dep_compat12_13/TestBean rather than the appclient_deploy_compat12_13_TestBean jndiName that has been specified via the xml descriptor/metadata. The logic for remote homes is wrong for ejb2x deployments. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

16 years, 2 months

1
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira July 2008