July 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Updated: (JBAS-2558) default virtual host always "localhost"

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2558?page=all ] Dimitris Andreadis updated JBAS-2558: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) Assignee: Remy Maucherat Maybe look at this for the next release. > default virtual host always "localhost" > --------------------------------------- > > Key: JBAS-2558 > URL: http://jira.jboss.com/jira/browse/JBAS-2558 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service > Affects Versions: JBossAS-4.0.3 SP1 > Reporter: Arto Huusko > Assigned To: Remy Maucherat > Priority: Minor > Fix For: JBossAS-4.0.6.CR1 > > > JBoss 4.0.3SP1 admin guide claims that > "When a WAR file is deployed, it is associated by default with the virtual host whose name matches the defaultHost attribute of the containing Engine." > This is false, and thus default WAR deployments are broken when there is no host named "localhost" -- or even if there is such virtual host, but WARs should not be deployed there by default. > It seems that, regardless of what Hosts are configured, and what the defaultHost is, if WAR does not have a jboss-web descriptor that specifies the virtual host, the WAR always deploys to "localhost". If there is no Host with that name configured, the WAR is inaccessible. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2315) Create an automated test for JBAS-2314

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2315?page=all ] Dimitris Andreadis updated JBAS-2315: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > Create an automated test for JBAS-2314 > -------------------------------------- > > Key: JBAS-2315 > URL: http://jira.jboss.com/jira/browse/JBAS-2315 > Project: JBoss Application Server > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service > Reporter: Brian Stansberry > Assigned To: Brian Stansberry > Priority: Minor > Fix For: JBossAS-4.0.6.CR1 > > > I currently test the JBAS-2314 fix manually; need to automate. Basically need to add a war to web-sso.ear that has secured resources but no authenticator configured. Test should access the normal sso test war on one server, then the other, and then on the 2nd server access the war w/o authenticator, confirming that no 403 is seen. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2598) [PerTxEntityInstanceCache] Unable to passivate due to ctx lock

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2598?page=all ] Dimitris Andreadis updated JBAS-2598: ------------------------------------- Fix Version/s: (was: JBossAS-4.0.5.CR1) > [PerTxEntityInstanceCache] Unable to passivate due to ctx lock > -------------------------------------------------------------- > > Key: JBAS-2598 > URL: http://jira.jboss.com/jira/browse/JBAS-2598 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EJB2 > Affects Versions: JBossAS-4.0.3 SP1 > Environment: Linux kos 2.6.14-archck5 #3 SMP PREEMPT Wed Dec 21 03:25:49 MSK 2005 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ AuthenticAMD GNU/Linux > java version "1.5.0_05" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05) > Java HotSpot(TM) Server VM (build 1.5.0_05-b05, mixed mode) > Reporter: Konstantin Sobolev > Priority: Minor > > I'm getting lots of > [PerTxEntityInstanceCache] Unable to passivate due to ctx lock > warnings. I'm calling instance per transaction BMP entity bean without a transaction context, by default it has a commit option C (there's no warnings if using B). Right after bean method invocation JBoss tries to passivate the instance, but fails because enterprise context is still locked, thus a perfectly valid(?) code generates lots of warnings. > My code looks like this (schematically): > MyInstancePerTransactionBean bean = home.findByPrimaryKey(...); > bean.method1(); //here we get passivation failure warning > bean.method2(); //and another one here > Call trace to the point where passivation fails: > at org.jboss.ejb.plugins.PerTxEntityInstanceCache.canPassivate(PerTxEntityInstanceCache.java:181) <-- returns false > at org.jboss.ejb.plugins.PerTxEntityInstanceCache.tryToPassivate(PerTxEntityInstanceCache.java:152) > at org.jboss.ejb.plugins.PerTxEntityInstanceCache.release(PerTxEntityInstanceCache.java:94) > at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.invoke(EntitySynchronizationInterceptor.java:364) > at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:149) > at org.jboss.ejb.plugins.EntityReentranceInterceptor.invoke(EntityReentranceInterceptor.java:111) > at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke(EntityInstanceInterceptor.java:261) > at org.jboss.ejb.plugins.EntityLockInterceptor.invoke(EntityLockInterceptor.java:89) > at org.jboss.ejb.plugins.EntityCreationInterceptor.invoke(EntityCreationInterceptor.java:53) > at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48) > at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:106) > at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:363) > at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:166) > at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:153) > at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192) > at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122) > at org.jboss.ejb.EntityContainer.internalInvoke(EntityContainer.java:514) > at org.jboss.ejb.Container.invoke(Container.java:873) > at sun.reflect.GeneratedMethodAccessor104.invoke(Unknown Source) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141) > at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80) > at org.jboss.mx.server.Invocation.invoke(Invocation.java:72) > at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245) > at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644) > at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(LocalInvoker.java:155) > at org.jboss.invocation.local.LocalInvoker.invoke(LocalInvoker.java:104) > at org.jboss.invocation.InvokerInterceptor.invokeLocal(InvokerInterceptor.java:179) > at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:165) > at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:46) > at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:55) > at org.jboss.proxy.ejb.EntityInterceptor.invoke(EntityInterceptor.java:97) > at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:86) > at $Proxy1264.getHierarchyName(Unknown Source) > at com.supportwizard.swgroups.SWGroupsBean.ejbFindByName(SWGroupsBean.java:915)me(SWGroupsBean.java:915) > > Here SWGroupsBean is an ordinary BMP bean, it's ejbFindByName method contains the code snippet shown above (method1 being getHierarchyName). As I said ctx is locked, so PerTxEntityInstanceCache.canPassivate returns false and we get a warning. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2968) Allow UseJBossWebLoader to be configured per war

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2968?page=all ] Dimitris Andreadis updated JBAS-2968: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > Allow UseJBossWebLoader to be configured per war > ------------------------------------------------ > > Key: JBAS-2968 > URL: http://jira.jboss.com/jira/browse/JBAS-2968 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service, Deployment services > Affects Versions: JBossAS-4.0.4RC1, JBossAS-4.0.3 SP1, JBossAS-3.2.8 Final, JBossAS-3.2.8.SP1 > Reporter: Jim Moran > Priority: Minor > Fix For: JBossAS-4.0.6.CR1 > > > Allow for wars to individually be configured to use either the Tomcat classloader or the JBoss deployment UCL. > Provide individual wars with the semantic currently provided on a global level via UseJbossWebLoader attribute of jboss.web:service=WebServer MBean configured in deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-2968) Allow UseJBossWebLoader to be configured per war

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-2968?page=all ] Dimitris Andreadis updated JBAS-2968: ------------------------------------- Comment: was deleted > Allow UseJBossWebLoader to be configured per war > ------------------------------------------------ > > Key: JBAS-2968 > URL: http://jira.jboss.com/jira/browse/JBAS-2968 > Project: JBoss Application Server > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Web (Tomcat) service, Deployment services > Affects Versions: JBossAS-4.0.4RC1, JBossAS-4.0.3 SP1, JBossAS-3.2.8 Final, JBossAS-3.2.8.SP1 > Reporter: Jim Moran > Priority: Minor > Fix For: JBossAS-4.0.5.CR1 > > > Allow for wars to individually be configured to use either the Tomcat classloader or the JBoss deployment UCL. > Provide individual wars with the semantic currently provided on a global level via UseJbossWebLoader attribute of jboss.web:service=WebServer MBean configured in deploy/jbossweb-tomcat55.sar/META-INF/jboss-service.xml -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBAS-3097) AbstractMBeanInvoker.initDispatchers called twice

by Dimitris Andreadis (JIRA)

[ http://jira.jboss.com/jira/browse/JBAS-3097?page=all ] Dimitris Andreadis updated JBAS-3097: ------------------------------------- Fix Version/s: JBossAS-4.0.6.CR1 (was: JBossAS-4.0.5.CR1) > AbstractMBeanInvoker.initDispatchers called twice > ------------------------------------------------- > > Key: JBAS-3097 > URL: http://jira.jboss.com/jira/browse/JBAS-3097 > Project: JBoss Application Server > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: JMX > Affects Versions: JBossAS-4.0.2 Final, JBossAS-4.0.3 SP1, JBossAS-4.0.4.CR2 > Reporter: Dimitris Andreadis > Priority: Minor > Fix For: JBossAS-4.0.6.CR1 > > > See attached forum post. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Resolved: (EJBTHREE-612) Nested bean during repeated failover throw NPE

by Ben Wang (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-612?page=all ] Ben Wang resolved EJBTHREE-612. ------------------------------- Resolution: Done > Nested bean during repeated failover throw NPE > ---------------------------------------------- > > Key: EJBTHREE-612 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-612 > Project: EJB 3.0 > Issue Type: Bug > Components: Clustering > Reporter: Ben Wang > Assigned To: Ben Wang > Fix For: EJB 3.0 RC9 - FD > > > I have encountered this during writing more complete unit testing for sfsb clustering. The test case is: > org.jboss.ejb3.test.clusteredsession.unit.testStatefulBeanCounterFailover > Here is how to reproduce it: > Create a ParentBean and NestedBean for nested sfsb case. Hit node1, failover to node2, and execute will produce the following exception: > Caused by: java.lang.NullPointerException^M > at org.jboss.ejb3.stateful.StatefulBeanContextReference.<init>(StatefulBeanContextReference.java:51)^M > at org.jboss.ejb3.stateful.ProxiedStatefulBeanContext.writeExternal(ProxiedStatefulBeanContext.java:92)^M > at org.jboss.serial.persister.ExternalizePersister.writeData(ExternalizePersister.java:58)^M > at org.jboss.serial.objectmetamodel.ObjectDescriptorFactory.describeObject(ObjectDescriptorFactory.java:275)^M > at org.jboss.serial.objectmetamodel.DataContainer$DataContainerDirectOutput.writeObject(DataContainer.java:197)^M > at org.jboss.serial.io.JBossObjectOutputStreamSharedTree.writeObjectOverride(JBossObjectOutputStreamSharedTree.java:59)^M > at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:287)^M > at org.jboss.cache.marshall.EnhancedTreeCacheMarshaller.marshallObject(EnhancedTreeCacheMarshaller.java:258)^M > @ > Note that this error has already existed before any refactoring is in place. -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Closed: (EJBTHREE-589) Make MDBs purely RAR based

by William DeCoste (JIRA)

[ http://jira.jboss.com/jira/browse/EJBTHREE-589?page=all ] William DeCoste closed EJBTHREE-589. ------------------------------------ Resolution: Done > Make MDBs purely RAR based > -------------------------- > > Key: EJBTHREE-589 > URL: http://jira.jboss.com/jira/browse/EJBTHREE-589 > Project: EJB 3.0 > Issue Type: Task > Reporter: Bill Burke > Assigned To: William DeCoste > Priority: Critical > Fix For: EJB 3.0 RC9 - FD > > > This is easy to do from a JBoss App Server perspective. The real work is in getting the Embeddable EJB3 container to work with the new JCA implementation. We cannot make this switch until: > * JMS RAR works > * JMS RAR works in E-EJB3 environment > This should be fun because you'll have to work with Weston. > Questions? -- 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

19 years, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-3420) Fix org.jboss.test.timer.test.SecureTimerUnitTestCase in HEAD

by Anil Saldhana (JIRA)

Fix org.jboss.test.timer.test.SecureTimerUnitTestCase in HEAD ------------------------------------------------------------- Key: JBAS-3420 URL: http://jira.jboss.com/jira/browse/JBAS-3420 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Scheduling/Timers, Security Reporter: Anil Saldhana Assigned To: Carlo de Wolf Fix For: JBossAS-5.0.0.Beta There is some vagaries associated with this test when run as a collection, part of the target "tests-security-basic-unit" against a jboss instance in the all config. Here the testcase consistently throws failures/errors. Now if this testcase is run standalone as $>ant -Dtest=org.jboss.test.timer.test.SecureTimerUnitTestCase one-test The first time there are a couple of errors but when this test is again run, the testcase passes. >From the log files, I see: ===================================================================================================== (1:31:47 PM) anil_aol: Caused by: java.lang.SecurityException: Invalid authentication attempt, principal=null at org.jboss.resource.connectionmanager.BaseConnectionManager2.getSubject(BaseConnectionManager2.java:587) at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:393) at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:838) at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88) at org.jboss.ejb.txtimer.GeneralPurposeDatabasePersistencePlugin.selectTimers(GeneralPurposeDatabasePersistencePlugin.java:207)^M at org.jboss.ejb.txtimer.DatabasePersistencePolicy.listTimerHandles(DatabasePersistencePolicy.java:164) ...... * Nested Exception (Underlying Cause) --------------- java.sql.SQLException: Could not retrieve datasource via JNDI url 'java:DefaultDS' java.lang.SecurityException: Invalid authentication attempt, principal=null at org.quartz.utils.JNDIConnectionProvider.getConnection(JNDIConnectionProvider.java:166) at org.quartz.utils.DBConnectionManager.getConnection(DBConnectionManager.java:111) at org.quartz.impl.jdbcjobstore.JobStoreCMT.getNonManagedTXConnection(JobStoreCMT.java:1431) at org.quartz.impl.jdbcjobstore.JobStoreCMT.doRecoverMisfires(JobStoreCMT.java:1335) at org.quartz.impl.jdbcjobstore.JobStoreSupport$MisfireHandler.manage(JobStoreSupport.java:2449) ============================================================================================= Please verify that this is not a Quart integration layer issue. -- 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

19 years, 10 months

1
3
0 / 0

[JBoss JIRA] Closed: (JBMESSAGING-227) Complete extension of smoke test to deploy/test non-scoped Messaging with JBoss 5.0

by Ovidiu Feodorov (JIRA)

[ http://jira.jboss.com/jira/browse/JBMESSAGING-227?page=all ] Ovidiu Feodorov closed JBMESSAGING-227. --------------------------------------- Resolution: Done > Complete extension of smoke test to deploy/test non-scoped Messaging with JBoss 5.0 > ----------------------------------------------------------------------------------- > > Key: JBMESSAGING-227 > URL: http://jira.jboss.com/jira/browse/JBMESSAGING-227 > Project: JBoss Messaging > Issue Type: Task > Components: Tests and Performance > Reporter: Ovidiu Feodorov > Fix For: 1.2.0.Alpha1 > > > The current smoke test deploys and test a scoped sar with JBoss 4. > Some support exists to deploy and test an un-scoped sar with JBoss 5. > Complete JBoss 5.0 smoke test support so the test will deploy/test Messaging on JBoss 4 and JBoss 5 in the same run. -- 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

19 years, 10 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 July 2006