September 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBAS-3670) org.jboss.axis.ConfigurationException: No engine configuration file

by Keith Gregory (JIRA)

org.jboss.axis.ConfigurationException: No engine configuration file ------------------------------------------------------------------- Key: JBAS-3670 URL: http://jira.jboss.com/jira/browse/JBAS-3670 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: JBossAS-4.0.3 SP1 Reporter: Keith Gregory Assigned To: Thomas Diesler Priority: Minor The default org.jboss.axis.client.Service constructor will throw this exception. My particular case involves creating a new Service object from within an EJB, but this should occur with any client. Tracing through the code, I discovered that org.jboss.axis.configuration.EngineConfigurationFactoryDefault defines the default filenames for the client configuration as "client-config.wsdd", while the actual file distributed with jboss-ws4ee-client.jar is "axis-client-config.xml". When the Service object is constructed, org.jboss.axis.configuration.FileProvider looks on the classpath for "client-config.wsdd", and of course can't find it. The workaround specified in JBAS-1106 puts a file with the correct name but possibly the wrong configuration information onto the classpath, where FileProvider can find it. This will work for a standalone client, but not for client code within an EJB, since the Axis packages appear to be loaded with a different classloader than that for the EJB. The workaround is to provide the Service constructor with a FileProvider that specifies the correct configuration file: new Service(new FileProvider("META-INF/axis-client-config.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

18 years, 1 month

2
1
0 / 0

[JBoss JIRA] Created: (JBAS-3671) org.jboss.axis.ConfigurationException: No engine configuration file

by Keith Gregory (JIRA)

org.jboss.axis.ConfigurationException: No engine configuration file ------------------------------------------------------------------- Key: JBAS-3671 URL: http://jira.jboss.com/jira/browse/JBAS-3671 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Web Services Affects Versions: JBossAS-4.0.3 SP1 Reporter: Keith Gregory Assigned To: Thomas Diesler Priority: Minor The default org.jboss.axis.client.Service constructor will throw this exception. My particular case involves creating a new Service object from within an EJB, but this should occur with any client. Tracing through the code, I discovered that org.jboss.axis.configuration.EngineConfigurationFactoryDefault defines the default filenames for the client configuration as "client-config.wsdd", while the actual file distributed with jboss-ws4ee-client.jar is "axis-client-config.xml". When the Service object is constructed, org.jboss.axis.configuration.FileProvider looks on the classpath for "client-config.wsdd", and of course can't find it. The workaround specified in JBAS-1106 puts a file with the correct name but possibly the wrong configuration information onto the classpath, where FileProvider can find it. This will work for a standalone client, but not for client code within an EJB, since the Axis packages appear to be loaded with a different classloader than that for the EJB. The workaround is to provide the Service constructor with a FileProvider that specifies the correct configuration file: new Service(new FileProvider("META-INF/axis-client-config.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

18 years, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (BPEL-200) Redeployment of a changed PAR (with modified .bpel) requires App Server Restart

by Burr Sutter (JIRA)

Redeployment of a changed PAR (with modified .bpel) requires App Server Restart ------------------------------------------------------------------------------- Key: BPEL-200 URL: http://jira.jboss.com/jira/browse/BPEL-200 Project: JBoss jBPM BPEL Issue Type: Bug Security Level: Public (Everyone can see) Components: Engine Affects Versions: jBPM BPEL 1.1 beta 1 Environment: JBoss 4.0.4.GA with EJB3 using beta JEMS installer Reporter: Burr Sutter Assigned To: Alejandro Guizar Simply modifying the .bpel script, running pack-definition and deploy-definition do not reload/restart the process (even though all process instances have terminated). The only thing I've found that refreshes the BPEL engine properly is to restart the App Server. -- 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, 1 month

3
6
0 / 0

[JBoss JIRA] Created: (JGRP-281) Investigate whether sent messages need to be buffered in NAKACK

by Bela Ban (JIRA)

Investigate whether sent messages need to be buffered in NAKACK --------------------------------------------------------------- Key: JGRP-281 URL: http://jira.jboss.com/jira/browse/JGRP-281 Project: JGroups Issue Type: Task Affects Versions: 2.3 SP1, 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 NAKACK buffers sent messages in sent-table and received messages in received-table. We might be able to discard sent-table entirely because received-table will contain a message sent by oneself ! Once we have loopback in place by default, we can be sure that any message sent by P will be in P's received-table. -- 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, 1 month

2
10
0 / 0

[JBoss JIRA] Created: (JBAS-3658) Remote classloading service - Redesign

by Dimitris Andreadis (JIRA)

Remote classloading service - Redesign -------------------------------------- Key: JBAS-3658 URL: http://jira.jboss.com/jira/browse/JBAS-3658 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Remoting Reporter: Dimitris Andreadis Assigned To: Tom Elrod Fix For: JBossAS-4.0.6.CR1 We need to redesign the remote classloading service such that there is more control at the deployment layer on what is exposed. I will create a forum thread where this can be discussed in more detail. Requirement 1: Provide sensible defaults, which probably means no remote classloading by default Requirement 2: Individual deployments can choose whether remote classloading is enabled and what is available remotely Requirement 3: Allow "aspects" of the deployment to enhance what can be downloaded remotely, e.g. RMI/IIOP generated proxies or AOP remoting proxies Requirement 4: Use the spec defined RMIClassloaderSPI (exposed via an MBean) to make this configurable Requirement 5: Alternate implementations, e.g. exposure of remote classloading via a servlet in Tomcat or a custom resource url that triggers the use of invokers to do remote classloading. -- 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, 1 month

3
7
0 / 0

[JBoss JIRA] Created: (JBCACHE-771) PojoCache to have events reacting to transactional context

by Ben Wang (JIRA)

PojoCache to have events reacting to transactional context ---------------------------------------------------------- Key: JBCACHE-771 URL: http://jira.jboss.com/jira/browse/JBCACHE-771 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: 2.1.0 Currently, the 2.0 POJO based events are not tx aware meaning they can't not react to tx rollback (and therefore not sending the events). If we want to acheieve the tx-based events, we will need to use event interceptor and react to before and afterCompletion, perhaps. -- 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, 1 month

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-696) Look into JDBMCacheLoader details and potentially promote as a 'recommended' cache loader?

by Manik Surtani (JIRA)

Look into JDBMCacheLoader details and potentially promote as a 'recommended' cache loader? ------------------------------------------------------------------------------------------ Key: JBCACHE-696 URL: http://jira.jboss.com/jira/browse/JBCACHE-696 Project: JBoss Cache Issue Type: Task Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.0, 1.3.0 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0 -- 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
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-708) EOF exception in TcpCacheLoader

by Manik Surtani (JIRA)

EOF exception in TcpCacheLoader ------------------------------- Key: JBCACHE-708 URL: http://jira.jboss.com/jira/browse/JBCACHE-708 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.0 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0 Happens when a node in the cluster dies. See last few postings in forum thread for details. -- 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
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-710) CacheLoader passivation/activation produces recursive exception when loader.remove fails

by Ben Wang (JIRA)

CacheLoader passivation/activation produces recursive exception when loader.remove fails ---------------------------------------------------------------------------------------- Key: JBCACHE-710 URL: http://jira.jboss.com/jira/browse/JBCACHE-710 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Components: Cache loaders Affects Versions: 1.4.0 Reporter: Ben Wang Assigned To: Manik Surtani Priority: Critical Fix For: 2.0.0 I have encountered this problem during ejb3 sfsb port of JBC1.4. This is what happened: In ActivationInterceptor.java, we have: if (n != null && !n.containsKey(TreeCache.UNINITIALIZED)) { if (n.hasChildren()) { if (allInitialized(n)) { log.debug("children all initialized"); remove(fqn); } } else if (loaderNoChildren(fqn)) { log.debug("no children " + n); remove(fqn); } } } } return retval; } private void remove(Fqn fqn) throws Exception { loader.remove(fqn); cache.notifyNodeActivate(fqn, false); if (cache.getUseInterceptorMbeans()&& statsEnabled) m_activations++; } problem arises when loader.remove(fqn) fails (can be a file lock there, e.g.), then if I have a Cache listener to receive nodeActivate event, and in there, I will have to retrieve the node value, e.g., cache.get(fqn, key) to process some logic, then get(fqn, key) will come back to ActivationInterceptor and attempt another .remove() and therefore the recursion. A proposed fix is we should throw exception when removing the node fails in CacheLoader (I am using FileCacheLoader), e.g., DataNotRemovedException. That way, ActivationInterceptor can catch it here and skip event notification (since it won't be valid anyway). -- 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

4
10
0 / 0

[JBoss JIRA] Created: (JBCACHE-723) Proper collection rollback

by Ben Wang (JIRA)

Proper collection rollback -------------------------- Key: JBCACHE-723 URL: http://jira.jboss.com/jira/browse/JBCACHE-723 Project: JBoss Cache Issue Type: Sub-task Security Level: Public (Everyone can see) Components: PojoCache Reporter: Ben Wang Assigned To: Ben Wang Fix For: 2.0.0 It is not properly yet via the undointerceptor -- 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
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2006