[jira] Commented: (AMQ-677) ActiveMQ broker leaks advisory topics
[ https://issues.apache.org/activemq/browse/AMQ-677?page=comments#action_35990 ] Andrew Lusk commented on AMQ-677: - I have reproduced this problem in svn trunk (previously I was a few weeks behind). ActiveMQ broker leaks advisory topics - Key: AMQ-677 URL: https://issues.apache.org/activemq/browse/AMQ-677 Project: ActiveMQ Type: Bug Components: Broker Environment: linux, near-trunk version of ActiveMQ Reporter: Andrew Lusk Attachments: ProducerTool.java When I run the attached code, which AFAIK is completely legal JMS, the ActiveMQ broker grows to 500+ mb and crashes due to being out of heap space. Some investigation with hprof has lead me to believe that the advisory topics created by the MessageConsumers (and Producers, but I use the same producer each time so that's not causing a problem) are being put into a DestinationMap and not being removed. The rough origin of this is in the addProducer call in AdvisoryBroker, which creates the advisory topic. Note that this memory is not freed when the DestinationInfo removing the original temptopic is received, nor when the actual client exits. The object lifetime of these advisory destinations seems very poorly defined. If they are implicitly created by the server, they should be implicitly destroyed by the same. To reproduce, I've been running this code with -Dtopic=true and -Dmax=1 (though the problem shows up well before this amount). This is just a modified version of the example ProducerTool (note it doesn't actually send any messages). Please verify the correctness of the attached code. Andrew Lusk -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: Update: AMQ C++ Client: First working draft
Hi Hiram, Yes, it is the content length but its value is always 4 less than the actual content length (calculated from the first content byte at position 5). Regards, Mats -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: den 5 april 2006 18:31 To: activemq-dev@geronimo.apache.org Subject: Re: Update: AMQ C++ Client: First working draft Hi Mats, Feature. Consider it to be like content-length Regards, Hiram On 4/5/06, Mats Forslöf [EMAIL PROTECTED] wrote: Hi, A new update has been uploaded to http://issues.apache.org/activemq/browse/AMQ-656, see issue for more details. When debugging the OpenWire protocol we've found an issue; the size counter (first 4 bytes) of all packages received from the server is always 4 numbers short of the actual package size (excluding the counter itself)!? Bug or feature?? :) Regards, Mats -- Regards, Hiram
Lost permissions on 3.x branch
It seems like I no longer have commit privs on ActiveMQ 3. Could
someone look into that and in the mean time apply the attached patch
and push a new 3.2.4 SNAPSHOT to the repo?
Thanks,
Aaron
Index: modules/gbean-g1_1/src/java/org/activemq/gbean/ActiveMQConnectorGBean.java
===
--- modules/gbean-g1_1/src/java/org/activemq/gbean/ActiveMQConnectorGBean.java (revision 1112)
+++ modules/gbean-g1_1/src/java/org/activemq/gbean/ActiveMQConnectorGBean.java (working copy)
@@ -17,24 +17,23 @@
**/
package org.activemq.gbean;
-import java.net.InetSocketAddress;
-import java.net.URI;
-import java.net.URISyntaxException;
-import javax.jms.JMSException;
-
+import org.activemq.ActiveMQConnectionFactory;
+import org.activemq.broker.BrokerConnector;
+import org.activemq.broker.impl.BrokerConnectorImpl;
+import org.activemq.io.WireFormat;
+import org.activemq.io.impl.DefaultWireFormat;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.geronimo.gbean.GBeanInfo;
import org.apache.geronimo.gbean.GBeanInfoBuilder;
import org.apache.geronimo.gbean.GBeanLifecycle;
import org.apache.geronimo.gbean.GConstructorInfo;
-import org.apache.geronimo.kernel.Kernel;
-import org.activemq.ActiveMQConnectionFactory;
-import org.activemq.broker.BrokerConnector;
-import org.activemq.broker.impl.BrokerConnectorImpl;
-import org.activemq.io.WireFormat;
-import org.activemq.io.impl.DefaultWireFormat;
+import javax.jms.JMSException;
+import java.net.InetSocketAddress;
+import java.net.URI;
+import java.net.URISyntaxException;
+
/**
* Default implementation of the ActiveMQ connector
*
Index: modules/gbean-g1_1/src/java/org/activemq/gbean/ActiveMQContainerGBean.java
===
--- modules/gbean-g1_1/src/java/org/activemq/gbean/ActiveMQContainerGBean.java (revision 1112)
+++ modules/gbean-g1_1/src/java/org/activemq/gbean/ActiveMQContainerGBean.java (working copy)
@@ -42,6 +42,7 @@
private Log log = LogFactory.getLog(getClass().getName());
private final String brokerName;
+private final String objectName;
private BrokerContext context = BrokerContext.getInstance();
private BrokerContainer container;
@@ -56,9 +57,10 @@
jaasConfiguration = null;
securityRoles = null;
persistenceAdapter=null;
+objectName = null;
}
-public ActiveMQContainerGBean(String brokerName, PersistenceAdapter persistenceAdapter, String jaasConfiguration, Properties securityRoles) {
+public ActiveMQContainerGBean(String brokerName, PersistenceAdapter persistenceAdapter, String jaasConfiguration, Properties securityRoles, String objectName) {
assert brokerName != null;
assert persistenceAdapter != null;
@@ -67,12 +69,29 @@
this.jaasConfiguration=jaasConfiguration;
this.persistenceAdapter = persistenceAdapter;
this.securityRoles = securityRoles;
+this.objectName = objectName;
}
public synchronized BrokerContainer getBrokerContainer() {
return container;
}
+public String getObjectName() {
+return objectName;
+}
+
+public boolean isStateManageable() {
+return true;
+}
+
+public boolean isStatisticsProvider() {
+return false; // todo: return true once stats are integrated
+}
+
+public boolean isEventProvider() {
+return true;
+}
+
/**
* @see org.activemq.gbean.ActiveMQContainer#getBrokerAdmin()
*/
@@ -136,8 +155,9 @@
infoFactory.addReference(persistenceAdapter, PersistenceAdapter.class);
infoFactory.addAttribute(jaasConfiguration, String.class, true);
infoFactory.addAttribute(securityRoles, Properties.class, true);
+infoFactory.addAttribute(objectName, String.class, false);
infoFactory.addInterface(ActiveMQContainer.class);
-infoFactory.setConstructor(new String[]{brokerName, persistenceAdapter, jaasConfiguration, securityRoles});
+infoFactory.setConstructor(new String[]{brokerName, persistenceAdapter, jaasConfiguration, securityRoles, objectName});
GBEAN_INFO = infoFactory.getBeanInfo();
}
Index: modules/gbean-g1_1/src/java/org/activemq/gbean/management/ActiveMQManagerGBean.java
===
--- modules/gbean-g1_1/src/java/org/activemq/gbean/management/ActiveMQManagerGBean.java (revision 1112)
+++ modules/gbean-g1_1/src/java/org/activemq/gbean/management/ActiveMQManagerGBean.java (working copy)
@@ -17,12 +17,6 @@
**/
package org.activemq.gbean.management;
-import java.net.URI;
-import java.util.ArrayList;
-import java.util.Iterator;
-import java.util.List;
-import java.util.Set;
-
import org.activemq.gbean.ActiveMQBroker;
import org.activemq.gbean.ActiveMQConnector;
import org.activemq.gbean.ActiveMQConnectorGBean;
@@ -42,7
[jira] Updated: (AMQ-656) Update of AMQ C++ client
[ https://issues.apache.org/activemq/browse/AMQ-656?page=all ] MF updated AMQ-656: --- Attachment: source_060406.zip Same as yesterdays update but with support for Mac OS X 10.4/GCC 4.0.1. Update of AMQ C++ client Key: AMQ-656 URL: https://issues.apache.org/activemq/browse/AMQ-656 Project: ActiveMQ Type: Improvement Components: JMS client Reporter: MF Attachments: README.TXT, source_060323.zip, source_060324.zip, source_060404.zip, source_060406.zip Attached is a new update of the C++ client, the zip-file contains the full source since the update is a major overhaul. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Lost permissions on 3.x branch
It worked now, thanks. Aaron On 4/6/06, Bruce Snyder [EMAIL PROTECTED] wrote: On 4/5/06, Aaron Mulder [EMAIL PROTECTED] wrote: It seems like I no longer have commit privs on ActiveMQ 3. Could someone look into that and in the mean time apply the attached patch and push a new 3.2.4 SNAPSHOT to the repo? You should be good to go now, Aaron. Let me know if you have any issues. Bruce -- perl -e 'print unpack(u30,D0G)[EMAIL PROTECTED]5R\F)R=6-E+G-N61ED\!G;6%I;\YC;VT* );' Apache Geronimo (http://geronimo.apache.org/) Castor (http://castor.org/)
Re: FW: InstanceAlreadyExistsException when creating Connections without start them
On 4/6/06, Li, Fan [EMAIL PROTECTED] wrote: This problem stops to appear if I change the variable nextConnectionId from long to static long, since it now generate different names for each Connection it tries to register with the MBeanServer. Ah I see. I've committed your patch to SVN HEAD which should fix this issue. I wonder, is your issue caused by running multiple brokers - or is it multiple connectors clashing? No worries though, this issue shouldn't occur again -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (AMQ-680) JMX Registration Issue
JMX Registration Issue -- Key: AMQ-680 URL: https://issues.apache.org/activemq/browse/AMQ-680 Project: ActiveMQ Type: Bug Versions: 4.0 RC 2 Reporter: Bryan Schmidt After creating a new destination, rapid multithreaded MessageProducer.send's cause JMX registration conflict. Two or more MessageProducers attempt to register the newly created destination with JMX, hence raising the InstanceAlreadyExistsException. 16:05:57,609 ERROR [ManagedRegionBroker] Failed to register destination topic:// clientRecordQuery-1144357557593-41 javax.management.InstanceAlreadyExistsException: org.apache.activemq:BrokerName= localhost,Type=Topic,Destination=clientRecordQuery-1144357557593-41 already regi stered. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-387) JBI Spec - Resource Loading Styles not correctly implemented
[ https://issues.apache.org/activemq/browse/SM-387?page=comments#action_35991 ] Guillaume Nodet commented on SM-387: I have just added some tests to check that the getResource works as expected (and it seems to work). Could you be more precise on what happens for you ? JBI Spec - Resource Loading Styles not correctly implemented Key: SM-387 URL: https://issues.apache.org/activemq/browse/SM-387 Project: ServiceMix Type: Bug Components: servicemix-core Versions: 3.0 Reporter: Philippe Pinheiro In the current version of ParentFirstClassLoader.java and SelfFirstClassLoader.java, the method getResource doesn't find a resource located on the classpath of the JBI component. The Class Loading Styles (self-first and parent-first) are correctly implemented but it should be not the Resource Loading. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-386) hostname and port in Ant task is not used
[ https://issues.apache.org/activemq/browse/SM-386?page=all ] Guillaume Nodet resolved SM-386: Fix Version: 3.0-M1 Resolution: Fixed Assign To: Guillaume Nodet Author: gnodet Date: Thu Apr 6 02:50:31 2006 New Revision: 391950 URL: http://svn.apache.org/viewcvs?rev=391950view=rev Log: SM-386: hostname and port in Ant task is not used Modified: incubator/servicemix/trunk/servicemix-core/src/main/java/org/apache/servicemix/jbi/management/task/JbiTask.java incubator/servicemix/trunk/servicemix-core/src/test/java/org/apache/servicemix/jbi/management/task/JbiTaskTest.java hostname and port in Ant task is not used - Key: SM-386 URL: https://issues.apache.org/activemq/browse/SM-386 Project: ServiceMix Type: Bug Components: servicemix-core Versions: 3.0-M1, 3.0-M2, 3.0 Environment: All platforms Reporter: Nicolas Biri Assignee: Guillaume Nodet Fix For: 3.0-M1 Original Estimate: 2 minutes Remaining: 2 minutes Using ant task, the configuration of host, port and all jmx connection variables are not used. In JBITask.java, the JMX connexion is done in the init function. Instead, it must be done as the first step of the execute function, otherwise the attribute values of the ant task are useless. Consequently, the JUnit for the JBITask is wrong too: JMX connexion should not be done at init. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-387) JBI Spec - Resource Loading Styles not correctly implemented
[ https://issues.apache.org/activemq/browse/SM-387?page=comments#action_35993 ] Philippe Pinheiro commented on SM-387: -- I''m installing a JBI component that must load a configuration file with its classloader getResource. In the jbi.xml I set the component classpath : component-class-path path-elementlib/Install.jar/path-element path-elementconf.xml/path-element /component-class-path And I include the file conf.xml on the component jar. When the component start it doesn't found the resource conf.xml but it can load classes of Install.jar. If I manually put conf.xml on the folder servicemix/conf then the component found it. JBI Spec - Resource Loading Styles not correctly implemented Key: SM-387 URL: https://issues.apache.org/activemq/browse/SM-387 Project: ServiceMix Type: Bug Components: servicemix-core Versions: 3.0 Reporter: Philippe Pinheiro In the current version of ParentFirstClassLoader.java and SelfFirstClassLoader.java, the method getResource doesn't find a resource located on the classpath of the JBI component. The Class Loading Styles (self-first and parent-first) are correctly implemented but it should be not the Resource Loading. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-387) JBI Spec - Resource Loading Styles not correctly implemented
[ https://issues.apache.org/activemq/browse/SM-387?page=comments#action_35995 ] Guillaume Nodet commented on SM-387: Path elements are added to the classpath. A path element must specify a directory or a jar, not a single file. You can either put path-element./path-element, or put the conf.xml file in a directory. JBI Spec - Resource Loading Styles not correctly implemented Key: SM-387 URL: https://issues.apache.org/activemq/browse/SM-387 Project: ServiceMix Type: Bug Components: servicemix-core Versions: 3.0 Reporter: Philippe Pinheiro In the current version of ParentFirstClassLoader.java and SelfFirstClassLoader.java, the method getResource doesn't find a resource located on the classpath of the JBI component. The Class Loading Styles (self-first and parent-first) are correctly implemented but it should be not the Resource Loading. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SM-387) JBI Spec - Resource Loading Styles not correctly implemented
[ https://issues.apache.org/activemq/browse/SM-387?page=comments#action_35996 ] Philippe Pinheiro commented on SM-387: -- It's now working, thanks for your quick reply JBI Spec - Resource Loading Styles not correctly implemented Key: SM-387 URL: https://issues.apache.org/activemq/browse/SM-387 Project: ServiceMix Type: Bug Components: servicemix-core Versions: 3.0 Reporter: Philippe Pinheiro In the current version of ParentFirstClassLoader.java and SelfFirstClassLoader.java, the method getResource doesn't find a resource located on the classpath of the JBI component. The Class Loading Styles (self-first and parent-first) are correctly implemented but it should be not the Resource Loading. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (SM-387) JBI Spec - Resource Loading Styles not correctly implemented
[ https://issues.apache.org/activemq/browse/SM-387?page=all ] Philippe Pinheiro closed SM-387: Fix Version: 3.0 Resolution: Fixed JBI Spec - Resource Loading Styles not correctly implemented Key: SM-387 URL: https://issues.apache.org/activemq/browse/SM-387 Project: ServiceMix Type: Bug Components: servicemix-core Versions: 3.0 Reporter: Philippe Pinheiro Fix For: 3.0 In the current version of ParentFirstClassLoader.java and SelfFirstClassLoader.java, the method getResource doesn't find a resource located on the classpath of the JBI component. The Class Loading Styles (self-first and parent-first) are correctly implemented but it should be not the Resource Loading. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1809) Remove GBeanName
Remove GBeanName Key: GERONIMO-1809 URL: http://issues.apache.org/jira/browse/GERONIMO-1809 Project: Geronimo Type: Improvement Security: public (Regular issues) Reporter: Dain Sundstrom Assigned to: Dain Sundstrom Fix For: 1.1 GBeanName is now only used within the kernel itself. This class should be removed to avoid confusion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1809) Remove GBeanName
[ http://issues.apache.org/jira/browse/GERONIMO-1809?page=all ] Dain Sundstrom updated GERONIMO-1809: - Component: kernel Remove GBeanName Key: GERONIMO-1809 URL: http://issues.apache.org/jira/browse/GERONIMO-1809 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: kernel Reporter: Dain Sundstrom Assignee: Dain Sundstrom Fix For: 1.1 GBeanName is now only used within the kernel itself. This class should be removed to avoid confusion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1772) Application class loader should not see server classes
[ http://issues.apache.org/jira/browse/GERONIMO-1772?page=all ] Dain Sundstrom reassigned GERONIMO-1772: Assign To: Dain Sundstrom Application class loader should not see server classes -- Key: GERONIMO-1772 URL: http://issues.apache.org/jira/browse/GERONIMO-1772 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: core, deployment, kernel Versions: 1.0 Reporter: Aaron Mulder Assignee: Dain Sundstrom Fix For: 1.1, 1.2 By default, applications should have a parent class loader that just has the spec JARs -- not Spring, commons logging, Geronimo code, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1508) 1.1 won't accept plans with 1.0 configIds in references, parents, imports, etc.
[ http://issues.apache.org/jira/browse/GERONIMO-1508?page=all ] Dain Sundstrom updated GERONIMO-1508: - Summary: 1.1 won't accept plans with 1.0 configIds in references, parents, imports, etc. (was: 1.0.1 won't accept plans with 1.0 configIds in references, parents, imports, etc.) Fix Version: (was: 1.2) Assign To: David Jencks 1.1 won't accept plans with 1.0 configIds in references, parents, imports, etc. --- Key: GERONIMO-1508 URL: http://issues.apache.org/jira/browse/GERONIMO-1508 Project: Geronimo Type: Bug Security: public(Regular issues) Components: core Versions: 1.0 Reporter: Aaron Mulder Assignee: David Jencks Priority: Blocker Fix For: 1.1 If you try to deploy a plan with: parentId=geronimo/j2ee-server/1.0/car Under 1.0.1 as we have it right now, it won't work. Likewise for import or a GBean reference with a module or gbean-name and so on. This means all published examples that include configIds will cause errors, many plans written for 1.0 won't be able to be deployed under 1.0.1, etc. Need to discuss this on the mailing list but this issue is here to track the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-704) Can't set listen host/IP for RMI Registry
[ http://issues.apache.org/jira/browse/GERONIMO-704?page=all ] Dain Sundstrom reassigned GERONIMO-704: --- Assign To: Dain Sundstrom Can't set listen host/IP for RMI Registry - Key: GERONIMO-704 URL: http://issues.apache.org/jira/browse/GERONIMO-704 Project: Geronimo Type: Bug Components: core Versions: 1.0-M3 Reporter: Aaron Mulder Assignee: Dain Sundstrom Fix For: 1.2 The RMI Registry GBean has a configuration attribute for a port, but not for a listen hostname/IP. It should have attributes for both. The class in question is: geronimo/modules/system/src/java/org/apache/geronimo/system/rmi/RMIRegistryService.java When this change is made, the getAddress method should be changed to return the correct listen host/IP instead of 0.0.0.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1430) Create TimedConfigStore (config store that timestamps deployments)
[ http://issues.apache.org/jira/browse/GERONIMO-1430?page=all ] Dain Sundstrom reassigned GERONIMO-1430: Assign To: Dain Sundstrom Create TimedConfigStore (config store that timestamps deployments) -- Key: GERONIMO-1430 URL: http://issues.apache.org/jira/browse/GERONIMO-1430 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: core Versions: 1.0 Reporter: Aaron Mulder Assignee: Dain Sundstrom Fix For: 1.2 It would be helpful for the hot deploy directory if it could ask the config store for the last time a module was deployed/redeployed. That would let it calculate during startup whether a file was newer or not. After discussing this, it seems like this is not necessarily a requirement for all config stores, but would be easy enough to support in an optional extension for the config store. This issue is to create an additional interface to hold the new method (something like, public long getLastDeploymentTime(URI configId)), and implement it for the file-based config store. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1810) Improve the Error: Unable to distribute foo.ear: Cannot deploy the requested application module message
Improve the Error: Unable to distribute foo.ear: Cannot deploy the requested application module message - Key: GERONIMO-1810 URL: http://issues.apache.org/jira/browse/GERONIMO-1810 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: deployment Versions: 1.0 Reporter: John Sisson Assigned to: John Sisson Priority: Trivial Fix For: 1.1 Need to provide more information in the following error message, giving the user a bit more of a hint as to what the problem may be. C:\testgeronimo-1.0.1-SNAPSHOT\bin\deploy --user system --password manager deploy jstest.ear jstest.xml Using GERONIMO_BASE: C:\test\geronimo-1.0.1-SNAPSHOT Using GERONIMO_HOME: C:\test\geronimo-1.0.1-SNAPSHOT Using GERONIMO_TMPDIR: C:\test\geronimo-1.0.1-SNAPSHOT\var\temp Using JRE_HOME:C:\j2sdk1.4.2_10 Error: Unable to distribute jstest.ear: Cannot deploy the requested application module (planFile=C:\test\jstest.xml, moduleFile=C:\test\geronimo-1.0.1-SNAPSHOT\var\temp\geronimo-deployer59948.tmpdir\jstest.ear) In the case above it was due to my ear file accidentially having all the files under a directory. I propose we add the following to the end of the message: Check that the module file contains the expected deployment files and directory structure. If problems persist, ensure the appropriate module builder is running. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1575) JMX service doesn't start up when server hostname does not resolve correctly
[ http://issues.apache.org/jira/browse/GERONIMO-1575?page=all ] Dain Sundstrom reassigned GERONIMO-1575: Assign To: Dain Sundstrom JMX service doesn't start up when server hostname does not resolve correctly Key: GERONIMO-1575 URL: http://issues.apache.org/jira/browse/GERONIMO-1575 Project: Geronimo Type: Bug Security: public(Regular issues) Components: core Versions: 1.0 Environment: OS: Linux Fedora Core 3, Kernel 2.6.11-7 with SMP enabled (dual-core processor) Java: jdk 1.4.2_10 Network: DHCP network Hardware: 3Ghz dual-core pentium 4, 1Gb of RAM. Reporter: Timotej Ecimovic Assignee: Dain Sundstrom Priority: Minor Fix For: 1.2 This problem occurs ONLY when I am on the DHCP network. It does not happen when I'm off the network or on the static IP network. When I'm on the DHCP network (wired or wireless). I can't talk to JMX. Running: 'geronimo.sh stop' doesn't work as it says 'can't connect'. My startup geronimo.log shows: 08:26:57,700 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: objectName=geronimo.server:J2EEApplication=null,J2E EModule=geronimo/j2ee-security/1.0/car,J2EEServer=geronimo,j2eeType=GBean,name=JMXService java.io.IOException: javax.naming.CommunicationException [Root exception is java.rmi.ConnectIOException: Exception creating connection to: 192.168.8 1.141; nested exception is: java.net.NoRouteToHostException: No route to host] at mx4j.remote.resolver.rmi.Resolver.bindServer(Resolver.java:199) at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:152) at org.apache.geronimo.jmxremoting.JMXConnector.doStart(JMXConnector.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:936) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:325) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:110) at org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:132) at org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:537) at org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:208) at org.apache.geronimo.kernel.config.Configuration.startRecursiveGBeans(Configuration.java:315) at org.apache.geronimo.kernel.config.Configuration$$FastClassByCGLIB$$7f4b4a9b.invoke(generated) at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) So for some or another reason, JMX server tries to use the DHCP hostname in some way, which does not make it happy. When this happen, I can run: arp -a, and in my ARP table I see an 'incomplete' entry for my DHCP hostname which is the underlying problem. The workaround is to force your hostname to be localhost.localdomain or 127.0.0.1 or something like that. (run 'hostname localhost'). Other workaround is to delete the DHCP hostname specified with your DHCP configuration. Do note that everything else works ok. I can deploy the EAR through the admin console for example. I can run it normally. But the JMX part does not start up, so I can't deploy the ant through ant target. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1811) Improve the Error: Unable to distribute foo.ear: Cannot deploy the requested application module message
Improve the Error: Unable to distribute foo.ear: Cannot deploy the requested application module message - Key: GERONIMO-1811 URL: http://issues.apache.org/jira/browse/GERONIMO-1811 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: deployment Versions: 1.0 Reporter: John Sisson Assigned to: John Sisson Priority: Trivial Fix For: 1.1 Need to provide more information in the following error message, giving the user a bit more of a hint as to what the problem may be. C:\testgeronimo-1.0.1-SNAPSHOT\bin\deploy --user system --password manager deploy jstest.ear jstest.xml Using GERONIMO_BASE: C:\test\geronimo-1.0.1-SNAPSHOT Using GERONIMO_HOME: C:\test\geronimo-1.0.1-SNAPSHOT Using GERONIMO_TMPDIR: C:\test\geronimo-1.0.1-SNAPSHOT\var\temp Using JRE_HOME:C:\j2sdk1.4.2_10 Error: Unable to distribute jstest.ear: Cannot deploy the requested application module (planFile=C:\test\jstest.xml, moduleFile=C:\test\geronimo-1.0.1-SNAPSHOT\var\temp\geronimo-deployer59948.tmpdir\jstest.ear) In the case above it was due to my ear file accidentially having all the files under a directory. I propose we add the following to the end of the message: Check that the module file contains the expected deployment files and directory structure. If problems persist, ensure the appropriate module builder is running. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: InstanceAlreadyExistsException when creating Connections without start them
Which version of ActiveMQ are you using BTW? We did have some JMX-related bugs a while back that have been fixed. We now use different MBean names for each transport connection so you shouldn't receive this exception on 4.0-RC2 (I use JMX all the time with multiple transports on the broker and haven't seen this in a long while). Incidentally if ever you're having trouble with JMX its very easy to disable with the useJmx=false property on BrokerService or broker James On 4/6/06, Li, Fan [EMAIL PROTECTED] wrote: Hi: I am doing a test where I am creating a number of TopicConnections on different TCP port on my machine, in particular I am using the TransportConnector URIs: tcp://localhost:61616, tcp://localhost:61626, tcp://localhost:61636 and tcp://localhost:61646. I have started a BrokerService with these four TransportConnectors and I have created four TCP TopicConnections without starting any of them, as a result I am getting InstanceAlreadyExistsException from the registerMBean() method of ManagedTransportConnection class, with the stack trace similar to: 2006-04-05 18:35:53,474 [127.0.0.1:61616] WARN ActiveMQConnection - Async exception with no exception listener: java.net.SocketException: Connection reset java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:48) at org.apache.activemq.transport.tcp.TcpBufferedInputStream.read(TcpBufferedInputStream.java:55) at java.io.DataInputStream.readInt(DataInputStream.java:353) at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:270) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:135) at java.lang.Thread.run(Thread.java:595) 2006-04-05 18:35:53,477 [mazon.com:61616] ERROR TransportConnector - Could not accept connection: java.io.IOException: org.apache.activemq:BrokerName=localhost,Type=Connection,Connection=1 java.io.IOException: org.apache.activemq:BrokerName=localhost,Type=Connection,Connection=1 at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:36) at org.apache.activemq.broker.jmx.ManagedTransportConnection.registerMBean(ManagedTransportConnection.java:98) at org.apache.activemq.broker.jmx.ManagedTransportConnection.setConnectionId(ManagedTransportConnection.java:78) at org.apache.activemq.broker.jmx.ManagedTransportConnection.init(ManagedTransportConnection.java:57) at org.apache.activemq.broker.jmx.ManagedTransportConnector.createConnection(ManagedTransportConnector.java:60) at org.apache.activemq.broker.TransportConnector$1.onAccept(TransportConnector.java:135) at org.apache.activemq.transport.tcp.TcpTransportServer.run(TcpTransportServer.java:137) at java.lang.Thread.run(Thread.java:595) Caused by: javax.management.InstanceAlreadyExistsException: org.apache.activemq:BrokerName=localhost,Type=Connection,Connection=1 at com.sun.jmx.mbeanserver.RepositorySupport.addMBean(RepositorySupport.java:452) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerInterceptor.java:1410) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:936) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:337) at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:497) at org.apache.activemq.broker.jmx.ManagedTransportConnection.registerMBean(ManagedTransportConnection.java:95) ... 6 more Is it required in ActiveMQ to start a Connection right after its creation? It seems all instances of ManagedTransportConnector for a particular BrokerService share the same MBeanServer. When I run debugger on the registerMBean() method that throws the exception, the objects it tries to register with the MBeanServer appears to be different, but the name it tries to register them under seems to be the same org.apache.activemq:BrokerName=localhost,Connection=1,Type=Connection. Do anyone know what might be the cause of this? Thanks Fan -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (GERONIMO-1812) When already deployed application is hot deployed once gain , Server doesn't delete the module from hot deployed directory
When already deployed application is hot deployed once gain , Server doesn't delete the module from hot deployed directory -- Key: GERONIMO-1812 URL: http://issues.apache.org/jira/browse/GERONIMO-1812 Project: Geronimo Type: Bug Security: public (Regular issues) Components: Hot Deploy Dir Versions: 1.1 Environment: Win2k , JDK 1.4.2 Reporter: Mansoor Priority: Minor Hi , Problem : When already an application module say (hello.war) is deployed (either by using manually or hot deploy procedure ) , And when some one try to hot deploy the same application with same or different name ( say hello.war | hello2.war | hello2 directory ) , the server throws an exception saying there exists already an application deployed , But doesn't delete the module ( hello.war | hello2.war | hello2 directory) from hot deploy directory . Thus the next time the server starts , it tries to deploy the same module once again. Here i have a piece of code put into DirectoryHotDeployer.java file , which can solve the above issue. Basically it deletes the asset from deploy directory ,which got failed to hot deploy . -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-956) Remove global JNDI space
[ http://issues.apache.org/jira/browse/GERONIMO-956?page=all ] Dain Sundstrom closed GERONIMO-956: --- Resolution: Invalid We need to reinstate the Global JNDI context. Remove global JNDI space -- Key: GERONIMO-956 URL: http://issues.apache.org/jira/browse/GERONIMO-956 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: connector, naming Versions: 1.0-M4 Reporter: Aaron Mulder Assignee: David Jencks Fix For: 1.x Geronimo has a global JNDI space under geronimo:. However: - it's only used by connectors, not EJBs - it's not visible outside the current VM It doesn't seem like this is really benefitting anyone. The effort necessary to make it behave like JNDI behaves in other popular app servers seems to be significant. After talking on IRC, David J and I are soliciting feedback on removing this feature entirely for now. Note: this is different than the JNDI space that OpenEJB uses to expose EJBs to remote clients, which takes EJBs only and is obviously accessible to remote clients. We are not proposing to change that at this time. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1813) When already deployed application is hot deployed once gain , Server doesn't delete the module from hot deployed directory
When already deployed application is hot deployed once gain , Server doesn't delete the module from hot deployed directory -- Key: GERONIMO-1813 URL: http://issues.apache.org/jira/browse/GERONIMO-1813 Project: Geronimo Type: Bug Security: public (Regular issues) Components: Hot Deploy Dir Versions: 1.1 Environment: Win2k , JDK 1.4.2 Reporter: Mansoor Priority: Minor Hi , Problem : When already an application module say (hello.war) is deployed (either by using manually or hot deploy procedure ) , And when some one try to hot deploy the same application with same or different name ( say hello.war | hello2.war | hello2 directory ) , the server throws an exception saying there exists already an application deployed , But doesn't delete the module ( hello.war | hello2.war | hello2 directory) from hot deploy directory . Thus the next time the server starts , it tries to deploy the same module once again. Here i have a piece of code put into DirectoryHotDeployer.java file , which can solve the above issue and also to some extend users can get clean picture. Basically it deletes the asset from deploy directory ,which got failed to hot deploy -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-644) Serialized form of GBeans objects must each declare SUID
[ http://issues.apache.org/jira/browse/GERONIMO-644?page=all ] Dain Sundstrom updated GERONIMO-644: Component: kernel Fix Version: 1.1 (was: 1.x) Assign To: Dain Sundstrom (was: Jeremy Boynes) With the introduction of XML based configurations using XStream in 1.1 we no longer have a serialization issue. Regardless, we should be declaring serial version id on all classes that implement serialization. Serialized form of GBeans objects must each declare SUID Key: GERONIMO-644 URL: http://issues.apache.org/jira/browse/GERONIMO-644 Project: Geronimo Type: Bug Components: kernel Reporter: Tim Ellison Assignee: Dain Sundstrom Fix For: 1.1 Since Geronimo exchanges config information via serialized form of Java objects, its imperative that the serializable classes declare a serialVersionUID. If they don't then the serialized form is not necessarily compatible across Java implementations (or even Java compilers) [1]. The case in point is the wire format classes in ActiveMQ (e.g. org.codehaus.activemq.message.DefaultWireFormat) which are marked serializable and do not declare a static ID. I've tried raising this with ActiveMQ [2] but without success. I can provide the required SUID in each case, but it looks like I might need help to get it into the ActiveMQ code. [1] http://java.sun.com/j2se/1.3/docs/guide/serialization/spec/class.doc6.html#4100 [2] http://article.gmane.org/gmane.comp.java.activemq.devel/486 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1813) When already deployed application is hot deployed once gain , Server doesn't delete the module from hot deployed directory
[ http://issues.apache.org/jira/browse/GERONIMO-1813?page=all ] Mansoor updated GERONIMO-1813: -- Attachment: hotdeploy_patch1_06042006.txt The patch basically deletes the asset from deploy directory ,which got failed to hot deploy successfully , this can also give the clear view to users of geronimo application server When already deployed application is hot deployed once gain , Server doesn't delete the module from hot deployed directory -- Key: GERONIMO-1813 URL: http://issues.apache.org/jira/browse/GERONIMO-1813 Project: Geronimo Type: Bug Security: public(Regular issues) Components: Hot Deploy Dir Versions: 1.1 Environment: Win2k , JDK 1.4.2 Reporter: Mansoor Priority: Minor Attachments: hotdeploy_patch1_06042006.txt Hi , Problem : When already an application module say (hello.war) is deployed (either by using manually or hot deploy procedure ) , And when some one try to hot deploy the same application with same or different name ( say hello.war | hello2.war | hello2 directory ) , the server throws an exception saying there exists already an application deployed , But doesn't delete the module ( hello.war | hello2.war | hello2 directory) from hot deploy directory . Thus the next time the server starts , it tries to deploy the same module once again. Here i have a piece of code put into DirectoryHotDeployer.java file , which can solve the above issue and also to some extend users can get clean picture. Basically it deletes the asset from deploy directory ,which got failed to hot deploy -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
1.1 repo/configstore
So I just launched 1.1 and have a couple of questions... So it looks like the repository now hosts both configurations and runtime/user jars. This is really good but my concern is now that user apps are not located in a separate location and when looking for a given application I was overwhelmed and took me more time then it should to find my app. So the question is would it be possible to provide multiple repositories and configurations would be deployed to it? I'm not sure if this is possible or how complex it would be if it were possible and wether these multiple repo's could be made aware of each other. Secondly is there an equivalent to index.properties? If I wanted to uninstall an app, where can I find the fully qualified artifact ID? Second question is that in 1.0 web apps were exploded so users if wanted could easily modify running content if they wanted. This is no longer and I assume this is because both webcontainer have moved to using the configuation classloader is this assumption correct? Thanks. - sachin
Re: Geronimo peak performance
Matt, first of all sorry for confusion - all the throughput values should be divided by 60:). I've rerun both tests. The parameters for the run were the ones you've mentioned - 100 users with 10 ms delay for each request from a user. Also for the second scenario I've changed configuration to Direct Mode with 5000 Users and 1 quotes. Here is the data I've got: -- Example 1: PingServlet2SessionEJB Your data: 100 168 582 Mine: 100 472 145 About 6600 samples (66 requests per thread) were used - about 10 percents of responses had Non HTTP response code. The resulting throughput was calculated with 8754/60=145. --- Example 2: PingServlet2TwoPhase Your data: 100 2096 46 Mine: 100 3324 29 4000 samples were provided. But only ~10 percents of queries return 200OK, the rest - 500 Error. Here is a typical error log I was receiving from the server: *** java.lang.NullPointerException at org.apache.jsp.error_jsp._jspService(Ljavax.servlet.http.HttpServletR equest;Ljavax.servlet.http.HttpServletResponse;)V(org.apache.jsp.error_jsp:96) at org.apache.jasper.runtime.HttpJspBase.service(Ljavax.servlet.http.Htt pServletRequest;Ljavax.servlet.http.HttpServletResponse;)V(HttpJspBase.java:97) at javax.servlet.http.HttpServlet.service(Ljavax.servlet.ServletRequest; Ljavax.servlet.ServletResponse;)V(Optimized Method) at org.apache.jasper.servlet.JspServletWrapper.service(Ljavax.servlet.ht tp.HttpServletRequest;Ljavax.servlet.http.HttpServletResponse;Z)V(JspServletWrap per.java:322) at org.apache.jasper.servlet.JspServlet.serviceJspFile(Ljavax.servlet.ht tp.HttpServletRequest;Ljavax.servlet.http.HttpServletResponse;Ljava.lang.String; Ljava.lang.Throwable;Z)V(JspServlet.java:314) at org.apache.jasper.servlet.JspServlet.service(Ljavax.servlet.http.Http ServletRequest;Ljavax.servlet.http.HttpServletResponse;)V(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(Ljavax.servlet.ServletRequest; Ljavax.servlet.ServletResponse;)V(Optimized Method) at org.mortbay.jetty.servlet.ServletHolder.handle(Ljavax.servlet.Servlet Request;Ljavax.servlet.ServletResponse;)V(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(Ljavax.servlet.Se rvletRequest;Ljavax.servlet.ServletResponse;)V(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;)V(WebApplicationHa ndler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(Ljavax.servlet.Servle tRequest;Ljavax.servlet.ServletResponse;Ljavax.servlet.FilterChain;)V(JSR154Filt er.java:170) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;)V(WebApplicationHa ndler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(Ljava.lang.S tring;Ljavax.servlet.http.HttpServletRequest;Ljavax.servlet.http.HttpServletResp onse;Lorg.mortbay.jetty.servlet.ServletHolder;I)V(WebApplicationHandler.java:471 ) at org.mortbay.jetty.servlet.Dispatcher.dispatch(Ljavax.servlet.ServletR equest;Ljavax.servlet.ServletResponse;I)V(Dispatcher.java:283) at org.mortbay.jetty.servlet.Dispatcher.error(Ljavax.servlet.ServletRequ est;Ljavax.servlet.ServletResponse;)V(Dispatcher.java:179) at org.mortbay.jetty.servlet.ServletHttpResponse.sendError(ILjava.lang.S tring;)V(ServletHttpResponse.java:415) at javax.servlet.http.HttpServletResponseWrapper.sendError(ILjava.lang.S tring;)V(HttpServletResponseWrapper.java:107) at org.apache.geronimo.samples.daytrader.web.prims.PingServlet2TwoPhase. doGet(Ljavax.servlet.http.HttpServletRequest;Ljavax.servlet.http.HttpServletResp onse;)V(Optimized Method) at javax.servlet.http.HttpServlet.service(Ljavax.servlet.http.HttpServle tRequest;Ljavax.servlet.http.HttpServletResponse;)V(Optimized Method) at javax.servlet.http.HttpServlet.service(Ljavax.servlet.ServletRequest; Ljavax.servlet.ServletResponse;)V(Optimized Method) at org.mortbay.jetty.servlet.ServletHolder.handle(Ljavax.servlet.Servlet Request;Ljavax.servlet.ServletResponse;)V(ServletHolder.java:428) at org.apache.geronimo.jetty.JettyServletHolder.handle(Ljavax.servlet.Se rvletRequest;Ljavax.servlet.ServletResponse;)V(JettyServletHolder.java:99) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter( Ljavax.servlet.ServletRequest;Ljavax.servlet.ServletResponse;)V(WebApplicationHa ndler.java:830) at org.mortbay.jetty.servlet.JSR154Filter.doFilter(Ljavax.servlet.Servle tRequest;Ljavax.servlet.ServletResponse;Ljavax.servlet.FilterChain;)V(JSR154Filt er.java:170) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(
Re: 1.1 repo/configstore
And just so I get my terminology straight... is the term config- store obsolete now? Or is there still a technical distinction between a config-store and repository? - sachin On Apr 6, 2006, at 9:26 AM, Sachin Patel wrote: So I just launched 1.1 and have a couple of questions... So it looks like the repository now hosts both configurations and runtime/ user jars. This is really good but my concern is now that user apps are not located in a separate location and when looking for a given application I was overwhelmed and took me more time then it should to find my app. So the question is would it be possible to provide multiple repositories and configurations would be deployed to it? I'm not sure if this is possible or how complex it would be if it were possible and wether these multiple repo's could be made aware of each other. Secondly is there an equivalent to index.properties? If I wanted to uninstall an app, where can I find the fully qualified artifact ID? Second question is that in 1.0 web apps were exploded so users if wanted could easily modify running content if they wanted. This is no longer and I assume this is because both webcontainer have moved to using the configuation classloader is this assumption correct? Thanks. - sachin
Re: Tomcat access logs
+1 to leave it off. Generally folks will front end the AppServer with Apache HTTP and use that for their access logging. Jeff Genender wrote: A while back, someone had requested that the access logs for Tomcat be turned on by default in Geronimo. This basically involved enabling the Tomcat AccessLogValve, and this request was granted. Upon further review, it would seem that other application servers leave this off by default. In fact, Tomcat itself leaves this off by default. I suppose that the reason for this is most Java web implementations are front-ended by a web server such as httpd, and the web server handles these logs. Should we follow suit and by default keep the access logs turned off? This seems to make more sense. Thoughts and opinions on this matter? Jeff
Re: Tomcat access logs
+1 on the concept Can we leave the valve in place but with some flag set so requests pass through it but it just does nothing? It would be nice if the console could have an enable logging checkbox and nicer still if it could just toggle a property on the valve instead of needing to insert or remove valves in the chain. Like a loggingEnabled property or something. Thanks, Aaron On 4/6/06, Matt Hogstrom [EMAIL PROTECTED] wrote: +1 to leave it off. Generally folks will front end the AppServer with Apache HTTP and use that for their access logging. Jeff Genender wrote: A while back, someone had requested that the access logs for Tomcat be turned on by default in Geronimo. This basically involved enabling the Tomcat AccessLogValve, and this request was granted. Upon further review, it would seem that other application servers leave this off by default. In fact, Tomcat itself leaves this off by default. I suppose that the reason for this is most Java web implementations are front-ended by a web server such as httpd, and the web server handles these logs. Should we follow suit and by default keep the access logs turned off? This seems to make more sense. Thoughts and opinions on this matter? Jeff
Re: Tomcat access logs
Yep...great idea...I'll throw that flag in. Aaron Mulder wrote: +1 on the concept Can we leave the valve in place but with some flag set so requests pass through it but it just does nothing? It would be nice if the console could have an enable logging checkbox and nicer still if it could just toggle a property on the valve instead of needing to insert or remove valves in the chain. Like a loggingEnabled property or something. Thanks, Aaron On 4/6/06, Matt Hogstrom [EMAIL PROTECTED] wrote: +1 to leave it off. Generally folks will front end the AppServer with Apache HTTP and use that for their access logging. Jeff Genender wrote: A while back, someone had requested that the access logs for Tomcat be turned on by default in Geronimo. This basically involved enabling the Tomcat AccessLogValve, and this request was granted. Upon further review, it would seem that other application servers leave this off by default. In fact, Tomcat itself leaves this off by default. I suppose that the reason for this is most Java web implementations are front-ended by a web server such as httpd, and the web server handles these logs. Should we follow suit and by default keep the access logs turned off? This seems to make more sense. Thoughts and opinions on this matter? Jeff
Re: Tomcat access logs
Sounds like a good idea. Questions: - should the access logs for jetty also be disabled by default (for consistency) - how should the web access log viewer in the console react to this change? Paul On 4/5/06, Jeff Genender [EMAIL PROTECTED] wrote: A while back, someone had requested that the access logs for Tomcat be turned on by default in Geronimo. This basically involved enabling the Tomcat AccessLogValve, and this request was granted. Upon further review, it would seem that other application servers leave this off by default. In fact, Tomcat itself leaves this off by default. I suppose that the reason for this is most Java web implementations are front-ended by a web server such as httpd, and the web server handles these logs. Should we follow suit and by default keep the access logs turned off? This seems to make more sense. Thoughts and opinions on this matter? Jeff
Re: 1.1 repo/configstore
Doh I just realized that the .car files are now directories :), that answers my last question. So what I'd like to see in addition to keeping installed apps in a different repository is a solution to the server being shutdown when any configuration fails. I think if we keep user install configurations in a separate repository we could say any configurations that failed to start from the user repository should not force the server to shutdown. - sachin On Apr 6, 2006, at 9:55 AM, Sachin Patel wrote: And just so I get my terminology straight... is the term config- store obsolete now? Or is there still a technical distinction between a config-store and repository? - sachin On Apr 6, 2006, at 9:26 AM, Sachin Patel wrote: So I just launched 1.1 and have a couple of questions... So it looks like the repository now hosts both configurations and runtime/user jars. This is really good but my concern is now that user apps are not located in a separate location and when looking for a given application I was overwhelmed and took me more time then it should to find my app. So the question is would it be possible to provide multiple repositories and configurations would be deployed to it? I'm not sure if this is possible or how complex it would be if it were possible and wether these multiple repo's could be made aware of each other. Secondly is there an equivalent to index.properties? If I wanted to uninstall an app, where can I find the fully qualified artifact ID? Second question is that in 1.0 web apps were exploded so users if wanted could easily modify running content if they wanted. This is no longer and I assume this is because both webcontainer have moved to using the configuation classloader is this assumption correct? Thanks. - sachin
[jira] Commented: (SM-371) Support for HTTPS
[ https://issues.apache.org/activemq/browse/SM-371?page=comments#action_35997 ] Guillaume Nodet commented on SM-371: I have changed the patch a bit to support default properties from System.getProperty and added an HttpsInvoker (not needed if all configuration is done with system props). Author: gnodet Date: Thu Apr 6 07:40:38 2006 New Revision: 391997 URL: http://svn.apache.org/viewcvs?rev=391997view=rev Log: SM-371: support for https in servicemix-components Thanks to Mike Gerdes for the patch Added: incubator/servicemix/trunk/servicemix-components/src/main/java/org/apache/servicemix/components/http/HttpsConnector.java incubator/servicemix/trunk/servicemix-components/src/main/java/org/apache/servicemix/components/http/HttpsInvoker.java incubator/servicemix/trunk/servicemix-components/src/main/java/org/apache/servicemix/components/http/HttpsSoapConnector.java incubator/servicemix/trunk/servicemix-components/src/test/resources/org/apache/servicemix/components/http/client.keystore (with props) incubator/servicemix/trunk/servicemix-components/src/test/resources/org/apache/servicemix/components/http/server.keystore (with props) Modified: incubator/servicemix/trunk/servicemix-components/src/test/java/org/apache/servicemix/components/http/HttpTest.java incubator/servicemix/trunk/servicemix-components/src/test/resources/org/apache/servicemix/components/http/example.xml Support for HTTPS - Key: SM-371 URL: https://issues.apache.org/activemq/browse/SM-371 Project: ServiceMix Type: New Feature Components: servicemix-components Reporter: Mike Gerdes Attachments: HttpsConnector.java, HttpsSoapConnector.java The lightweight httpconnector component of SM enhanced with SSL support. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (SM-371) Support for HTTPS
[ https://issues.apache.org/activemq/browse/SM-371?page=all ] Guillaume Nodet resolved SM-371: Fix Version: 3.0-M1 Resolution: Fixed Assign To: Guillaume Nodet Support for HTTPS - Key: SM-371 URL: https://issues.apache.org/activemq/browse/SM-371 Project: ServiceMix Type: New Feature Components: servicemix-components Reporter: Mike Gerdes Assignee: Guillaume Nodet Fix For: 3.0-M1 Attachments: HttpsConnector.java, HttpsSoapConnector.java The lightweight httpconnector component of SM enhanced with SSL support. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (AMQ-679) ActiveMQ 4 exception with with DB2
ActiveMQ 4 exception with with DB2 Key: AMQ-679 URL: https://issues.apache.org/activemq/browse/AMQ-679 Project: ActiveMQ Type: Bug Components: Message Store Versions: 4.0 RC 2 Environment: IBM Blade JS20 AIX 5.3 DB2 DataBase 8.2 Driver 2.5.33 Configuration: jdbcPersistenceAdapter class=org.activemq.store.jdbc.adapter.DefaultJDBCAdapter dataSource= #db2-ds/ bean id=db2datasource class=org.apache.commons.dbcp.BasicDataSource property name=driverClassName value=com.ibm.db2.jcc.DB2Driver/ property name=url value=URL/ property name=username value=USER/ property name=password value=PASS/ /bean Reporter: klaus terjung Priority: Blocker If start broker i get this message: WARNING: Database driver NOT recognized: [ibm_db2_jdbc_universal_driver_architecture]. Will use default JDBC implementation. But this seems to be o.k. so far, because after starting the broker, two new tables (activemq_msgs/acks) get created. Testing a Consumer to receive Messages the broker throws this exception: 2006-04-05 17:13:03,304 [.168.1.52:52134] INFO Service- Sync error occurred: java.io.IOException: Non-atomic batch failure. The batch was submitted, but at least one exception occurred on an individual member of the batch. Use getNextException() to retrieve the exceptions for specific batched elements. java.io.IOException: Non-atomic batch failure. The batch was submitted, but at least one exception occurred on an individual member of the batch. Use getNextException() to retrieve the exceptions for specific batched elements. at org.apache.activemq.util.IOExceptionSupport.create(IOExceptionSupport.java:42) at org.apache.activemq.store.jdbc.TransactionContext.close(TransactionContext.java:125) at org.apache.activemq.store.jdbc.JDBCMessageStore.addMessage(JDBCMessageStore.java:73) at org.apache.activemq.store.memory.MemoryTransactionStore.addMessage(MemoryTransactionStore.java:223) at org.apache.activemq.store.memory.MemoryTransactionStore$1.addMessage(MemoryTransactionStore.java:116) at org.apache.activemq.broker.region.Queue.send(Queue.java:246) at org.apache.activemq.broker.region.AbstractRegion.send(AbstractRegion.java:196) at org.apache.activemq.broker.region.RegionBroker.send(RegionBroker.java:307) at org.apache.activemq.broker.TransactionBroker.send(TransactionBroker.java:192) at org.apache.activemq.broker.BrokerFilter.send(BrokerFilter.java:108) at org.apache.activemq.broker.CompositeDestinationBroker.send(CompositeDestinationBroker.java:97) at org.apache.activemq.broker.MutableBrokerFilter.send(MutableBrokerFilter.java:120) at org.apache.activemq.broker.AbstractConnection.processMessage(AbstractConnection.java:346) at org.apache.activemq.command.ActiveMQMessage.visit(ActiveMQMessage.java:590) at org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:196) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62) at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:88) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:70) at org.apache.activemq.transport.WireFormatNegotiator.onCommand(WireFormatNegotiator.java:114) at org.apache.activemq.transport.InactivityMonitor.onCommand(InactivityMonitor.java:122) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:87) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:136) at java.lang.Thread.run(Thread.java:570) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
New Feature Idea
support for sun jdk 1.5
Re: Questions about the packaging plugin
Dain, Thanks! I need to sort out the dependencies anyway. IIUC, currently we are including the dependencies referenced by the plans, i.e. the ones needed by GBeans. We are including few extra ones. The maven transitive dependency list is very large compared to what we add currently. I think we should only add the dependencies needed for the GBeans.For example if we have a GBean : gbean name=ConfigurationManager class=org.apache.geronimo.kernel.config.EditableConfigurationManagerImpl we should add geronimo-kernel as a dependency. Thanks Anita --- Dain Sundstrom [EMAIL PROTECTED] wrote: Branch 1.1 uses the m2 repository layout for the main geronimo repository, so you could grab the code from there. I personally would perfer if we could let this problem sit until we merge branch 1.1 into HEAD, since we made major changes to this code in branch 1.1. -dain On Apr 5, 2006, at 8:47 AM, anita kulshreshtha wrote: David J, o.a.g.system.repository.ReadOnlyRepository has a method 'public boolean hasURI(URI uri)', which is maven version dependent. Should I try to change it so that it works on both versions, i.e. m1 and m2? How is the implementation defined in the packaging plugin 'public class MavenRepository implements Repository' being used? Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: David, I am encountering a strange problem probably because I am doing something wrong. When I add commons-logging to the urls used for constructing the classloader for PackageBuilder. I get error : -- -- [ERROR] FATAL ERROR [INFO] -- -- [INFO] null Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. If I do not add it I get this error : [INFO] -- -- [ERROR] FATAL ERROR [INFO] -- -- [INFO] org/apache/commons/logging/LogFactory [INFO] -- -- [INFO] Trace java.lang.NoClassDefFoundError: org/apache/commons/logging/LogFactory at org.apache.geronimo.plugin.packaging.PackageBuilder.clinit (PackageBuilder.java:49) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance (NativeConstructorAccessorImpl.java: What is this due to? Thanks Anita --- anita kulshreshtha [EMAIL PROTECTED] wrote: David J, Thanks. Comments inline... --- David Jencks [EMAIL PROTECTED] wrote: anita kulshreshtha [EMAIL PROTECTED] wrote: Hi David, I have few questions related to geronimo-packaging-plugin: 1. The j2ee-server configuration has geronimo-gbean-deployer.car declared as a dependency whereas rmi-naming.car is an import. IIUC, the first one is a parent configuration and each additional parent is defined using import. Is this convention followed throughout? Why is it necessary to distinguish between the two? geronimo-gbean-deployer is a dependency because it is needed to run the packaging plugin for this plan. it is definitely NOT a parent, it is not needed to start a geronimo server that includes the j2ee-server configuration. I see.. a lot has changed from the days of o/a/g/Deployer etc. Now j2ee-server is the base configuration. What is j2ee-system-experimental configuration? Thnaks Anita 2. We add all the imports/dependencies to plan.xml for constructing the classpath. This classpath is used to package the car. Sometime the classpath is also put in MANIFEST.MF (for example j2ee-system). Why is this not done for j2ee-server? The entries in the manifest classpath are only needed for the root configurations that are used to boot a server. At present these are the j2ee-system and client-system (I might have forgotten something used for a tool, perhaps shutdown?) Currently the Daemon (and subclasses such as ClientCommandLine) clear the dependency list on any configurations they boot (start first). We've wanted for a long time to eliminate the need for the manifest classpath, and Dain has some ideas how to do it: basically we need to start up a boot repository. This will also let us remove a lot of the jars from lib. We are putting the dependencies into the plan mostly so that all the plans include their dependencies generated from project.xml, even thought they aren't being used for the boot configurations. 3. How is the generated plan.xml used later on? If we put
Re: New Feature Idea
We already support JDK 1.5 except for CORBA. Because of the CORBA limitation Geronimo can't be certified on JDK 1.5, but if you leave CORBA disabled (and turn off the DayTrader sample application) Geronimo should run fine on 1.5. Thanks, Aaron On 4/6/06, Christopher Stura [EMAIL PROTECTED] wrote: support for sun jdk 1.5
Re: Tomcat access logs
Yes, I think Jetty shoudl work the same way, and if we get a loggingEnabled flag in there or something similar, the console web access log can work the same way as the web statistics in that if it's not enabled it'll have a bit saying something to the effect of The web access log is currently disabled. Please consult your HTTP server log if Geronimo is running through e.g. Apache or IIS, or else [Enable Access Log] (that last bit a link or button). Thanks, Aaron On 4/6/06, Paul McMahan [EMAIL PROTECTED] wrote: Sounds like a good idea. Questions: - should the access logs for jetty also be disabled by default (for consistency) - how should the web access log viewer in the console react to this change? Paul On 4/5/06, Jeff Genender [EMAIL PROTECTED] wrote: A while back, someone had requested that the access logs for Tomcat be turned on by default in Geronimo. This basically involved enabling the Tomcat AccessLogValve, and this request was granted. Upon further review, it would seem that other application servers leave this off by default. In fact, Tomcat itself leaves this off by default. I suppose that the reason for this is most Java web implementations are front-ended by a web server such as httpd, and the web server handles these logs. Should we follow suit and by default keep the access logs turned off? This seems to make more sense. Thoughts and opinions on this matter? Jeff
Re: 1.1 repo/configstore
On Apr 6, 2006, at 6:26 AM, Sachin Patel wrote: So I just launched 1.1 and have a couple of questions... So it looks like the repository now hosts both configurations and runtime/ user jars. This is really good but my concern is now that user apps are not located in a separate location and when looking for a given application I was overwhelmed and took me more time then it should to find my app. So the question is would it be possible to provide multiple repositories and configurations would be deployed to it? I'm not sure if this is possible or how complex it would be if it were possible and wether these multiple repo's could be made aware of each other. We can organize the repos how every you want. Just propose what you want. Secondly is there an equivalent to index.properties? If I wanted to uninstall an app, where can I find the fully qualified artifact ID? No there is not an index.properties file. As for how you get the fully qualified artifact ID to uninstall an application, I think it depends on how you got the application in the first place. If you know the directory in the repo, then you can work out the application id from the directory structure. If you got the application from a running server, then you should already have the application id. Second question is that in 1.0 web apps were exploded so users if wanted could easily modify running content if they wanted. This is no longer and I assume this is because both webcontainer have moved to using the configuation classloader is this assumption correct? As you discovered they are directories. On Apr 6, 2006, at 6:55 AM, Sachin Patel wrote: And just so I get my terminology straight... is the term config- store obsolete now? Or is there still a technical distinction between a config-store and repository? At the filesystem level there is no config-store? At least there won't be one once someone mangages to remove it from the assembly plugin maven.xml file. -dain
RE: FW: InstanceAlreadyExistsException when creating Connections without start them
I am running only one broker and trying to make multiple connections to it. Thanks for commit the patch. Fan -Original Message- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Thursday, April 06, 2006 8:55 AM To: activemq-dev@geronimo.apache.org Subject: Re: FW: InstanceAlreadyExistsException when creating Connections without start them On 4/6/06, Li, Fan [EMAIL PROTECTED] wrote: This problem stops to appear if I change the variable nextConnectionId from long to static long, since it now generate different names for each Connection it tries to register with the MBeanServer. Ah I see. I've committed your patch to SVN HEAD which should fix this issue. I wonder, is your issue caused by running multiple brokers - or is it multiple connectors clashing? No worries though, this issue shouldn't occur again -- James --- http://radio.weblogs.com/0112098/
celtix-geronimo integration redux
Hi there, Right now I've got to the stage where I can, with a bit of tweaking of the config.xml, deploy Celtix to Geronimo and have it handle Web Service deployments. This is on 1.2 where the deployers for wars, ejb jars and webservices are all separate so it's pretty straightforward to change configuration so that a Celtix deployer is used. Thanks for the help in making that work. 1.0/1.1 is another story, though. Here, the j2ee-deployer directly configures the GBeans it uses for deploying web services etc. I've tried overriding the class for the WebServiceBuilder in the config.xml but it is ignored. In fact as the server is starting the config.xml is overwritten and my change is erased. In the config.xml, should be possible to change the name of the class that implements a particular GBean? Can I prevent a GBean from being loaded? thanks Conrad
Re: celtix-geronimo integration redux
You can prevent a GBean from being loded with the following: gbean name=whatever load=false / Conrad O'Dea wrote: Hi there, Right now I've got to the stage where I can, with a bit of tweaking of the config.xml, deploy Celtix to Geronimo and have it handle Web Service deployments. This is on 1.2 where the deployers for wars, ejb jars and webservices are all separate so it's pretty straightforward to change configuration so that a Celtix deployer is used. Thanks for the help in making that work. 1.0/1.1 is another story, though. Here, the j2ee-deployer directly configures the GBeans it uses for deploying web services etc. I've tried overriding the class for the WebServiceBuilder in the config.xml but it is ignored. In fact as the server is starting the config.xml is overwritten and my change is erased. In the config.xml, should be possible to change the name of the class that implements a particular GBean? Can I prevent a GBean from being loaded? thanks Conrad
Re: New Feature Idea
To be clear. The reason DayTrader has an issue is that it uses WebServices and specifically it has to do with the javax.xml.namespace.QName class has different serialization characteristics between 1.4 and 1.5. So, if someone wants to move back and forth between 1.4 and 1.5 and their using WebServices they'll still have issues. Aaron Mulder wrote: We already support JDK 1.5 except for CORBA. Because of the CORBA limitation Geronimo can't be certified on JDK 1.5, but if you leave CORBA disabled (and turn off the DayTrader sample application) Geronimo should run fine on 1.5. Thanks, Aaron On 4/6/06, Christopher Stura [EMAIL PROTECTED] wrote: support for sun jdk 1.5
Re: celtix-geronimo integration redux
Forgot to answer your other question. I don't know if you can change the class of a current named bean. Dain or David Jencks may be able to answer that. But I *think*, you can shut off the gbean as I explained in my last email, then redeclare it in the config.xml. Here is an example of a new ConnectorGBean that is declared in the Tomcat configuration section of the config.xml: gbean name=geronimo.server:J2EEApplication=null,J2EEModule=geronimo/tomcat/1.0/car,J2EEServer=geronimo,j2eeType=GBean,name=TomcatWebConnector-HTTP-MyNewHTTPListener gbeanInfo=org.apache.geronimo.tomcat.ConnectorGBean attribute name=protocolHTTP/attribute attribute name=host0.0.0.0/attribute attribute name=port9090/attribute attribute name=nameMyNewHTTPListener/attribute reference name=TomcatContainer patterngbean-namegeronimo.server:J2EEApplication=null,J2EEModule=geronimo/tomcat/1.0/car,J2EEServer=geronimo,j2eeType=GBean,name=TomcatWebContainer/gbean-name/pattern /reference /gbean I am sure the others may be able to tweak this, but this should be in the right general direction. Jeff Conrad O'Dea wrote: Hi there, Right now I've got to the stage where I can, with a bit of tweaking of the config.xml, deploy Celtix to Geronimo and have it handle Web Service deployments. This is on 1.2 where the deployers for wars, ejb jars and webservices are all separate so it's pretty straightforward to change configuration so that a Celtix deployer is used. Thanks for the help in making that work. 1.0/1.1 is another story, though. Here, the j2ee-deployer directly configures the GBeans it uses for deploying web services etc. I've tried overriding the class for the WebServiceBuilder in the config.xml but it is ignored. In fact as the server is starting the config.xml is overwritten and my change is erased. In the config.xml, should be possible to change the name of the class that implements a particular GBean? Can I prevent a GBean from being loaded? thanks Conrad
Re: 1.1 repo/configstore
I think having the index.properties to know what configurations will be started on launch was useful information. I'd like to see a replacement for this in some form or another, perhaps something like what we discussed on one of the other threads yesterday having an xml file perhaps listing useful information about each application like the full configID, state, messages, etc..., so rather having to go to the console we have single file that users could go to. In addition as far as the repo structure... I think something simple would suffice for now just to break apart user apps from system configuration and libraries. ../G11/repository/ ../G11/applications/ Perhaps there may be some value later down to break it down even further... as to seperate system stuff/users stuff/libraries/ configurations like so... ../G1.1/system/repository/ ../G1.1/system/applications/ ../G1.1/usr/repository (libraries) ../G1.1/usr/applications (actual configurations) I'm not completely thrilled on this structure but hopefully it will bring trigger other ideas.. thx - sachin On Apr 6, 2006, at 11:49 AM, Dain Sundstrom wrote: On Apr 6, 2006, at 6:26 AM, Sachin Patel wrote: So I just launched 1.1 and have a couple of questions... So it looks like the repository now hosts both configurations and runtime/user jars. This is really good but my concern is now that user apps are not located in a separate location and when looking for a given application I was overwhelmed and took me more time then it should to find my app. So the question is would it be possible to provide multiple repositories and configurations would be deployed to it? I'm not sure if this is possible or how complex it would be if it were possible and wether these multiple repo's could be made aware of each other. We can organize the repos how every you want. Just propose what you want. Secondly is there an equivalent to index.properties? If I wanted to uninstall an app, where can I find the fully qualified artifact ID? No there is not an index.properties file. As for how you get the fully qualified artifact ID to uninstall an application, I think it depends on how you got the application in the first place. If you know the directory in the repo, then you can work out the application id from the directory structure. If you got the application from a running server, then you should already have the application id. Second question is that in 1.0 web apps were exploded so users if wanted could easily modify running content if they wanted. This is no longer and I assume this is because both webcontainer have moved to using the configuation classloader is this assumption correct? As you discovered they are directories. On Apr 6, 2006, at 6:55 AM, Sachin Patel wrote: And just so I get my terminology straight... is the term config- store obsolete now? Or is there still a technical distinction between a config-store and repository? At the filesystem level there is no config-store? At least there won't be one once someone mangages to remove it from the assembly plugin maven.xml file. -dain
Re: Update: AMQ C++ Client: First working draft
Then that sounds like a problem. I'll look into it. On 4/6/06, Mats Forslöf [EMAIL PROTECTED] wrote: Hi Hiram, Yes, it is the content length but its value is always 4 less than the actual content length (calculated from the first content byte at position 5). Regards, Mats -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hiram Chirino Sent: den 5 april 2006 18:31 To: activemq-dev@geronimo.apache.org Subject: Re: Update: AMQ C++ Client: First working draft Hi Mats, Feature. Consider it to be like content-length Regards, Hiram On 4/5/06, Mats Forslöf [EMAIL PROTECTED] wrote: Hi, A new update has been uploaded to http://issues.apache.org/activemq/browse/AMQ-656, see issue for more details. When debugging the OpenWire protocol we've found an issue; the size counter (first 4 bytes) of all packages received from the server is always 4 numbers short of the actual package size (excluding the counter itself)!? Bug or feature?? :) Regards, Mats -- Regards, Hiram -- Regards, Hiram
[jira] Updated: (GERONIMO-1694) Improve Serviceability of Geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-1694?page=all ] Dain Sundstrom updated GERONIMO-1694: - Component: kernel Fix Version: 1.1 Assign To: Dain Sundstrom Improve Serviceability of Geronimo -- Key: GERONIMO-1694 URL: http://issues.apache.org/jira/browse/GERONIMO-1694 Project: Geronimo Type: Bug Security: public(Regular issues) Components: kernel Environment: All Reporter: Matt Hogstrom Assignee: Dain Sundstrom Fix For: 1.1 Currently Geronimo requires significant intervention on the part of the user when applying fixes to a Geronimo server instance. The interventions can range from something as simple as reading a set of iinstructions and making a manual change to haveing to rebuild the entire server to introduce a required fix into their environment. Geronimo needs a servicebility strategy that will allow fixes to be introduced to the users environment in the least disruptive way. This involves a number of elements like a fix installer, ability to know what service level Geronimo is at, attention to serialVersionUID issues, etc. This JIRA highlights a significant barrier to wide range adoption of Geronimo for users of a commercial nature in terms of disruption to production use when some fixes are introduced into the environment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-232) The ${geronimo.home}/config-store should be created if missing prior to deployment.
[ http://issues.apache.org/jira/browse/GERONIMO-232?page=all ]
Dain Sundstrom closed GERONIMO-232:
---
Fix Version: 1.1
(was: 1.x)
Resolution: Invalid
We no longer have a config-store directory
The ${geronimo.home}/config-store should be created if missing prior to
deployment.
Key: GERONIMO-232
URL: http://issues.apache.org/jira/browse/GERONIMO-232
Project: Geronimo
Type: Improvement
Reporter: Jason van Zyl
Fix For: 1.1
If you nuke the ${geronimo.home}/config-store directory to start afresh an
error occurs during subsequent deployments.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-241) GBean proxy code could use improvement
[ http://issues.apache.org/jira/browse/GERONIMO-241?page=all ] Dain Sundstrom updated GERONIMO-241: Component: kernel Fix Version: 1.1 (was: Wish List) Assign To: Dain Sundstrom GBean proxy code could use improvement -- Key: GERONIMO-241 URL: http://issues.apache.org/jira/browse/GERONIMO-241 Project: Geronimo Type: Improvement Components: kernel Versions: 1.0-M2 Reporter: Jeremy Boynes Assignee: Dain Sundstrom Fix For: 1.1 Added support for proxies that use reflection or cglib depending on ig cglib is available - there is a lot of redundent code that could be cleaned up -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-241) GBean proxy code could use improvement
[ http://issues.apache.org/jira/browse/GERONIMO-241?page=all ] Dain Sundstrom closed GERONIMO-241: --- Resolution: Fixed GBean proxy code could use improvement -- Key: GERONIMO-241 URL: http://issues.apache.org/jira/browse/GERONIMO-241 Project: Geronimo Type: Improvement Components: kernel Versions: 1.0-M2 Reporter: Jeremy Boynes Assignee: Dain Sundstrom Fix For: 1.1 Added support for proxies that use reflection or cglib depending on ig cglib is available - there is a lot of redundent code that could be cleaned up -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-1462) Finish implementing inverseClassloading attribute in plan schemas
[ http://issues.apache.org/jira/browse/GERONIMO-1462?page=all ] Dain Sundstrom closed GERONIMO-1462: Fix Version: 1.1 (was: 1.2) (was: 1.x) Resolution: Fixed Finish implementing inverseClassloading attribute in plan schemas - Key: GERONIMO-1462 URL: http://issues.apache.org/jira/browse/GERONIMO-1462 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.0 Reporter: Aaron Mulder Assignee: David Jencks Fix For: 1.1 The inverseClassloading attribute is declared in geronimo-config-1.0.xsd. It appears to be used in: - geronimo-application-1.0 - geronimo-connector-1.0 - geronimo-jetty-1.0 - openejb-jar-2.0 It should be added to: - geronimo-web-1.0 - geronimo-tomcat-1.0 - geronimo-application-client-1.0 (not totally sure about this one) However, we need to decide whether to rev the version numbers of those schemas when we make the change. I would be inclined to not change the namespace or version in the file name, but to add an internal version history in the header comment of the schemas. Mainly because that's how Sun does it with the J2EE schemas, and I think it would be a huge pain to try to get people to update their namespaces every time we have a tiny change. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: New Feature Idea
I didn't think there were problems with web services in Geronimo in general between 1.4 and 1.5 -- I thought it's only the fact that QNames are serialized that causes problem. I wouldn't expect to have a problem with an application that calls a web service or is called via a web service so long as it doesn't do any Java serialization involving QNames. Is that not correct? (Does Geronimo itself do the QName serialization for certain types of Web Services apps?) Thanks, Aaron On 4/6/06, Matt Hogstrom [EMAIL PROTECTED] wrote: To be clear. The reason DayTrader has an issue is that it uses WebServices and specifically it has to do with the javax.xml.namespace.QName class has different serialization characteristics between 1.4 and 1.5. So, if someone wants to move back and forth between 1.4 and 1.5 and their using WebServices they'll still have issues. Aaron Mulder wrote: We already support JDK 1.5 except for CORBA. Because of the CORBA limitation Geronimo can't be certified on JDK 1.5, but if you leave CORBA disabled (and turn off the DayTrader sample application) Geronimo should run fine on 1.5. Thanks, Aaron On 4/6/06, Christopher Stura [EMAIL PROTECTED] wrote: support for sun jdk 1.5
[jira] Updated: (GERONIMO-1492) Many org/apache/geronimo configIds still live in source tree
[ http://issues.apache.org/jira/browse/GERONIMO-1492?page=all ] Dain Sundstrom updated GERONIMO-1492: - Fix Version: (was: 1.2) Many org/apache/geronimo configIds still live in source tree -- Key: GERONIMO-1492 URL: http://issues.apache.org/jira/browse/GERONIMO-1492 Project: Geronimo Type: Bug Security: public(Regular issues) Versions: 1.0 Reporter: Aaron Mulder Fix For: 1.1 I created a couple separate issues, but beyond those a quick search brought up a few more in magic G ball and day trader -- I stopped before it went any further, but we should grep for that and try to eliminate all the references to old-style config IDs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1782) Properties File Login module fails after editing through Admin Console
[ http://issues.apache.org/jira/browse/GERONIMO-1782?page=all ]
Dain Sundstrom updated GERONIMO-1782:
-
Component: security
Properties File Login module fails after editing through Admin Console
--
Key: GERONIMO-1782
URL: http://issues.apache.org/jira/browse/GERONIMO-1782
Project: Geronimo
Type: Bug
Security: public(Regular issues)
Components: security
Versions: 1.0, 1.1, 1.2
Environment: Win XP, Sun JDK 1.4.2_08
Reporter: Vamsavardhana Reddy
Fix For: 1.1, 1.2
Geronimo-properties-realm fails to initialize after editing the realm thru
Admin Console.
Steps to reproduce the problem.
1. Open the Security Realms portlet in Admin Console.
2. Click on edit link provided next to geronimo-properties-realm.
3. Click on Save button in the next page. PS: No need to edit anything in
this page.
4. Restart the server.
5. Access Admin Console to notice that the realm nolonger works.
NOTE: To make the realm work again, stop the server and remove the following
xml fragment from var/config/config.xml
gbean
name=geronimo.server:J2EEApplication=null,J2EEModule=geronimo/j2ee-security/1.0/car,J2EEServer=geronimo,j2eeType=LoginModule,name=properties-login
attribute name=options{usersURI=var/security/users.properties,
groupsURI=var/security/groups.properties}/attribute
attribute name=serverSideTrue/attribute
attribute name=wrapPrincipalsFalse/attribute
attribute
name=loginModuleClassorg.apache.geronimo.security.realm.providers.PropertiesFileLoginModule/attribute
/gbean
At step 5, the following exception is logged to geronimo.log.
13:53:41,950 ERROR [PropertiesFileLoginModule] Initialization failed
java.lang.IllegalArgumentException: Both usersURI and groupsURI must be
provided!
at
org.apache.geronimo.security.realm.providers.PropertiesFileLoginModule.initialize(PropertiesFileLoginModule.java:77)
at
org.apache.geronimo.security.jaas.server.JaasLoginService.getServerLoginCallbacks(JaasLoginService.java:205)
at
org.apache.geronimo.security.jaas.server.JaasLoginService$$FastClassByCGLIB$$95b84fc9.invoke(generated)
at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
at
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38)
at
org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:800)
at
org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
at
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36)
at
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
at
org.apache.geronimo.security.jaas.server.JaasLoginServiceMBean$$EnhancerByCGLIB$$7dca63e6.getServerLoginCallbacks(generated)
at
org.apache.geronimo.security.jaas.client.ServerLoginProxy.login(ServerLoginProxy.java:68)
at
org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.performLogin(JaasLoginCoordinator.java:189)
at
org.apache.geronimo.security.jaas.client.JaasLoginCoordinator.login(JaasLoginCoordinator.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.invoke(Unknown Source)
at javax.security.auth.login.LoginContext.access$000(Unknown Source)
at javax.security.auth.login.LoginContext$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.login.LoginContext.invokeModule(Unknown Source)
at javax.security.auth.login.LoginContext.login(Unknown Source)
at
org.apache.geronimo.jetty.JAASJettyRealm.authenticate(JAASJettyRealm.java:94)
at
org.mortbay.jetty.servlet.FormAuthenticator$FormCredential.authenticate(FormAuthenticator.java:305)
at
org.mortbay.jetty.servlet.FormAuthenticator.authenticate(FormAuthenticator.java:148)
at
org.apache.geronimo.jetty.interceptor.SecurityContextBeforeAfter.obtainUser(SecurityContextBeforeAfter.java:282)
at
org.apache.geronimo.jetty.interceptor.SecurityContextBeforeAfter.checkSecurityConstraints(SecurityContextBeforeAfter.java:191)
at
org.apache.geronimo.jetty.JettyWebAppContext.checkSecurityConstraints(JettyWebAppContext.java:585)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:432)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568)
at
[jira] Updated: (GERONIMO-1808) Replace AbstractName with URI
[ http://issues.apache.org/jira/browse/GERONIMO-1808?page=all ] Dain Sundstrom updated GERONIMO-1808: - Component: kernel Replace AbstractName with URI - Key: GERONIMO-1808 URL: http://issues.apache.org/jira/browse/GERONIMO-1808 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: kernel Reporter: Dain Sundstrom Assignee: Dain Sundstrom Fix For: 1.2 Using a custom name class for Geronimo causes unnecessary extra dependencies on Geronimo jars. Instead of using a custom name class we can instead just encode our name into a URI. The following describes the current proposal: http://opensource.atlassian.com/confluence/oss/display/GERONIMO/Service+Names -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1636) Support optional version number on dependencies
[ http://issues.apache.org/jira/browse/GERONIMO-1636?page=all ] Dain Sundstrom updated GERONIMO-1636: - Component: kernel Support optional version number on dependencies --- Key: GERONIMO-1636 URL: http://issues.apache.org/jira/browse/GERONIMO-1636 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: kernel Versions: 1.0 Reporter: Dain Sundstrom Assignee: David Jencks Fix For: 1.1 Add support for making the version number of a dependency optional. In the case of a missing version number a pluggable strategy should choose the actual version to load. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-631) Package Derby tools with Geronimo
[ http://issues.apache.org/jira/browse/GERONIMO-631?page=all ] Dain Sundstrom updated GERONIMO-631: Component: databases Package Derby tools with Geronimo - Key: GERONIMO-631 URL: http://issues.apache.org/jira/browse/GERONIMO-631 Project: Geronimo Type: Improvement Components: databases Versions: 1.0-M4 Reporter: John Sisson Assignee: John Sisson Priority: Minor Fix For: 1.2 IBM now has donated the JDBC network driver code to the Derby project (as a patch) and it is under review (not committed). Once it has been accepted and included in a formal Derby release, it would be worthwhile including it with Geronimo, along with some simple scripts to invoke Derby's ij tool, so Geronimo users can easily manage the embedded Derby database(s). FYI.. the donated JDBC network driver supports XA. Here is a mail thread titled Provision of derby tools JAR and JDBC network driver JAR from the dev list... [EMAIL PROTECTED] wrote: If a Java application (not J2EE app) provides a database creation utility and expects to be able to use a JDBC network driver to connect to the Derby network server embedded in Geronimo, then currently the command line application (the database creation utility) needs access (assuming the IBM Universal Driver is used) to db2jcc.jar and db2jcc_license_c.jar . On the Derby lists I saw that IBM is planning on donating a JDBC network driver sometime in March. Q1. Would it make sense to place this driver jar and the derbytools jar in the geronimo/repository/incubator-derby/jars directory to accompany the other derby jars so we provide all the required jars needed for connecting to and administering the Derby database embedded in Geronimo (even though the driver or tools won't be loaded by Geronimo)? Yes - we already configure and start the network server so having the client jars available would make sense. These could also be used to connect to a Derby instance in a different JVM. Q2. Even if we do provide all the JARs in the repository, users of a command line Java application (running on the same machine) would probably have to edit their classpath to point to the correct version of JDBC driver that matches the version of Derby embedded in Geronimo. Any suggestions on how this could be automated (determining the version and getting the driver JAR)? I think it would depend on how the client app expected this to work and whether it relied on having them in the system classpath or did some fancy uber-jar type thing. One option would be to deploy the client along with the server (EAR) as a J2EE Application Client. IIRC the app client can have a plan associated with it where they can specify dependencies just like with server-side modules. -- Jeremy -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-624) WinXP: Testsuite: org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest failed
[ http://issues.apache.org/jira/browse/GERONIMO-624?page=all ] Dain Sundstrom closed GERONIMO-624: --- Resolution: Fixed I'm guessing this is no longer a problem since you haven't complained about it since summer of last year. WinXP: Testsuite: org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest failed Key: GERONIMO-624 URL: http://issues.apache.org/jira/browse/GERONIMO-624 Project: Geronimo Type: Bug Versions: 1.0-M4 Environment: Windows XP SP2 java version 1.4.2_06 Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03) Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode) Reporter: John Sisson Priority: Minor Fix For: Wish List At svn rev 159684. Was running maven with -X flag at the time trying to track down a different problem. Testsuite: org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest Tests run: 7, Failures: 0, Errors: 5, Time elapsed: 3.891 sec - Standard Error - log4j:WARN No appenders could be found for logger (org.axiondb.engine.BaseDatabase). log4j:WARN Please initialize the log4j system properly. - --- Testcase: testASetBNewAB(org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest): Caused an ERROR Access is denied java.io.IOException: Access is denied at java.io.WinNTFileSystem.createFileExclusively(Native Method) at java.io.File.checkAndCreate(File.java:1314) at java.io.File.createTempFile(File.java:1402) at java.io.File.createTempFile(File.java:1439) at org.apache.geronimo.deployment.util.DeploymentUtil.createTempDir(DeploymentUtil.java:58) at org.openejb.deployment.entity.cmp.cmr.AbstractCMRTest.setUp(AbstractCMRTest.java:176) at org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest.setUp(OneToOneTest.java:617) Testcase: testBSetANewAB(org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest): Caused an ERROR A kernel is already running this kernel name: bar java.lang.IllegalStateException: A kernel is already running this kernel name: bar at org.apache.geronimo.kernel.Kernel.boot(Kernel.java:437) at org.openejb.deployment.KernelHelper.getPreparedKernel(KernelHelper.java:48) at org.openejb.deployment.DeploymentHelper.setUpKernelWithTransactionManager(DeploymentHelper.java:118) at org.openejb.deployment.entity.cmp.cmr.AbstractCMRTest.setUp(AbstractCMRTest.java:157) at org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest.setUp(OneToOneTest.java:617) Testcase: testASetBExistingBNewA(org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest): Caused an ERROR A kernel is already running this kernel name: bar java.lang.IllegalStateException: A kernel is already running this kernel name: bar at org.apache.geronimo.kernel.Kernel.boot(Kernel.java:437) at org.openejb.deployment.KernelHelper.getPreparedKernel(KernelHelper.java:48) at org.openejb.deployment.DeploymentHelper.setUpKernelWithTransactionManager(DeploymentHelper.java:118) at org.openejb.deployment.entity.cmp.cmr.AbstractCMRTest.setUp(AbstractCMRTest.java:157) at org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest.setUp(OneToOneTest.java:617) Testcase: testBSetAExistingBNewA(org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest): Caused an ERROR A kernel is already running this kernel name: bar java.lang.IllegalStateException: A kernel is already running this kernel name: bar at org.apache.geronimo.kernel.Kernel.boot(Kernel.java:437) at org.openejb.deployment.KernelHelper.getPreparedKernel(KernelHelper.java:48) at org.openejb.deployment.DeploymentHelper.setUpKernelWithTransactionManager(DeploymentHelper.java:118) at org.openejb.deployment.entity.cmp.cmr.AbstractCMRTest.setUp(AbstractCMRTest.java:157) at org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest.setUp(OneToOneTest.java:617) Testcase: testCascadeDelete(org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest): Caused an ERROR A kernel is already running this kernel name: bar java.lang.IllegalStateException: A kernel is already running this kernel name: bar at org.apache.geronimo.kernel.Kernel.boot(Kernel.java:437) at org.openejb.deployment.KernelHelper.getPreparedKernel(KernelHelper.java:48) at org.openejb.deployment.DeploymentHelper.setUpKernelWithTransactionManager(DeploymentHelper.java:118) at org.openejb.deployment.entity.cmp.cmr.AbstractCMRTest.setUp(AbstractCMRTest.java:157) at org.openejb.deployment.entity.cmp.cmr.onetoone.OneToOneTest.setUp(OneToOneTest.java:617) -- This message is automatically generated by
[jira] Assigned: (GERONIMO-1483) During Undeploy entry in config.xml is not removed
[ http://issues.apache.org/jira/browse/GERONIMO-1483?page=all ] Dain Sundstrom reassigned GERONIMO-1483: Assign To: Aaron Mulder Can you verify that this has been fixed once you get the console working. During Undeploy entry in config.xml is not removed -- Key: GERONIMO-1483 URL: http://issues.apache.org/jira/browse/GERONIMO-1483 Project: Geronimo Type: Bug Security: public(Regular issues) Environment: WinXP, JDK1.4.2_09 X86 Intel Reporter: Manu T George Assignee: Aaron Mulder Priority: Minor Suppose I have two modules A and B and A is dependant on B. Usually we first remove A and then B . This works fine. If we remove B and then A then the entry in config.xml is not removed and the server does not allow me to again deploy the module A. This problem was noticed on running the deploy command. from console -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: New Feature Idea
Shouldn't update our QName implementation to be compatiable with 1.5? Also, if we do ship with the XStream based configs on we no longer will have this problem. -dain On Apr 6, 2006, at 11:45 AM, Aaron Mulder wrote: I didn't think there were problems with web services in Geronimo in general between 1.4 and 1.5 -- I thought it's only the fact that QNames are serialized that causes problem. I wouldn't expect to have a problem with an application that calls a web service or is called via a web service so long as it doesn't do any Java serialization involving QNames. Is that not correct? (Does Geronimo itself do the QName serialization for certain types of Web Services apps?) Thanks, Aaron On 4/6/06, Matt Hogstrom [EMAIL PROTECTED] wrote: To be clear. The reason DayTrader has an issue is that it uses WebServices and specifically it has to do with the javax.xml.namespace.QName class has different serialization characteristics between 1.4 and 1.5. So, if someone wants to move back and forth between 1.4 and 1.5 and their using WebServices they'll still have issues. Aaron Mulder wrote: We already support JDK 1.5 except for CORBA. Because of the CORBA limitation Geronimo can't be certified on JDK 1.5, but if you leave CORBA disabled (and turn off the DayTrader sample application) Geronimo should run fine on 1.5. Thanks, Aaron On 4/6/06, Christopher Stura [EMAIL PROTECTED] wrote: support for sun jdk 1.5
[jira] Updated: (GERONIMO-1483) During Undeploy entry in config.xml is not removed
[ http://issues.apache.org/jira/browse/GERONIMO-1483?page=all ] Dain Sundstrom updated GERONIMO-1483: - Component: console deployment During Undeploy entry in config.xml is not removed -- Key: GERONIMO-1483 URL: http://issues.apache.org/jira/browse/GERONIMO-1483 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console, deployment Environment: WinXP, JDK1.4.2_09 X86 Intel Reporter: Manu T George Assignee: Aaron Mulder Priority: Minor Suppose I have two modules A and B and A is dependant on B. Usually we first remove A and then B . This works fine. If we remove B and then A then the entry in config.xml is not removed and the server does not allow me to again deploy the module A. This problem was noticed on running the deploy command. from console -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1655) Daytrader MDBs do not start properly
[ http://issues.apache.org/jira/browse/GERONIMO-1655?page=all ] Dain Sundstrom updated GERONIMO-1655: - Component: sample apps Daytrader MDBs do not start properly Key: GERONIMO-1655 URL: http://issues.apache.org/jira/browse/GERONIMO-1655 Project: Geronimo Type: Bug Security: public(Regular issues) Components: sample apps Versions: 1.1 Environment: All (j2ee-jetty-server and j2ee-tomcat-server, rev 380210) Reporter: Anita Kulshreshtha Fix For: 1.1 The following MDBs of Daytrader application do not start during startup of the server : . WARNING: Some GBeans were not started successfully: TradeStreamerMDB (starting) TradeBrokerMDB (starting) This affects both jetty and tomcat servers. These are waiting for MdbContainer to start, which in turn is waiting for Timers . All the timers NonTransactionalThreadPooledTimer etc are being started properly, but MdbContainer is looking for non existent GBeans, i.e. the name part of the reference is NonTransactionalThreadPooledTimer,* Here is an example : 13:00:24,437 DEBUG [GBeanSingleReference] Waiting to start geronimo.server:J2EEApplication=null,J2EEModule=geronimo/openejb/1.1-SNAPSHOT/car,J2EEServer=geronimo,j2eeType=MdbContainer,name=MdbEjbContainer because no targets are running for reference NontransactedTimer matching the patterns geronimo.server:J2EEApplication=null,J2EEServer=geronimo,j2eeType=GBean,name=NonTransactionalThreadPooledTimer,* -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1731) Module migration to Maven2: jetty
[ http://issues.apache.org/jira/browse/GERONIMO-1731?page=all ] Dain Sundstrom updated GERONIMO-1731: - Component: buildsystem Module migration to Maven2: jetty - Key: GERONIMO-1731 URL: http://issues.apache.org/jira/browse/GERONIMO-1731 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Versions: 1.x Reporter: Jacek Laskowski Assignee: Prasad Kashyap Attachments: jetty.patch It's a task to keep track of the progress of the module build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1725) Module migration to Maven 2: client-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1725?page=all ] Dain Sundstrom updated GERONIMO-1725: - Component: buildsystem Module migration to Maven 2: client-builder --- Key: GERONIMO-1725 URL: http://issues.apache.org/jira/browse/GERONIMO-1725 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Versions: 1.x Reporter: Jacek Laskowski Assignee: Prasad Kashyap Attachments: pom.xml It's a task to help keep track of the progress of the module build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1654) Itests in M2 (for openejb and others too)
[ http://issues.apache.org/jira/browse/GERONIMO-1654?page=all ] Dain Sundstrom updated GERONIMO-1654: - Component: buildsystem Itests in M2 (for openejb and others too) - Key: GERONIMO-1654 URL: http://issues.apache.org/jira/browse/GERONIMO-1654 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Reporter: Prasad Kashyap Assignee: Jacek Laskowski Attachments: itests.zip -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1665) Module migration to Maven2: axis
[ http://issues.apache.org/jira/browse/GERONIMO-1665?page=all ] Dain Sundstrom updated GERONIMO-1665: - Component: buildsystem Module migration to Maven2: axis Key: GERONIMO-1665 URL: http://issues.apache.org/jira/browse/GERONIMO-1665 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Reporter: Henri Yandell Attachments: GERONIMO-1665.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1698) Module migration to Maven2: hot-deploy
[ http://issues.apache.org/jira/browse/GERONIMO-1698?page=all ] Dain Sundstrom updated GERONIMO-1698: - Component: buildsystem Module migration to Maven2: hot-deploy -- Key: GERONIMO-1698 URL: http://issues.apache.org/jira/browse/GERONIMO-1698 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Reporter: Rakesh Ranjan Priority: Minor Attachments: pom.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1659) Module migration to Maven 2: system
[ http://issues.apache.org/jira/browse/GERONIMO-1659?page=all ] Dain Sundstrom updated GERONIMO-1659: - Component: buildsystem Module migration to Maven 2: system --- Key: GERONIMO-1659 URL: http://issues.apache.org/jira/browse/GERONIMO-1659 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Reporter: Anders Hessellund Jensen Assignee: Jacek Laskowski Attachments: maven-timestamp-plugin.zip, org.apache.geronimo.system.serverinfo.ServerInfoTest.txt, pom.patch, system-m2-migration-new.patch, system-m2-migration.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1785) Application migration to Maven 2: magicGball
[ http://issues.apache.org/jira/browse/GERONIMO-1785?page=all ] Dain Sundstrom updated GERONIMO-1785: - Component: buildsystem Application migration to Maven 2: magicGball Key: GERONIMO-1785 URL: http://issues.apache.org/jira/browse/GERONIMO-1785 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Reporter: Prasad Kashyap Assignee: Prasad Kashyap Attachments: magicGball.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1730) Module migration to Maven 2: interop
[ http://issues.apache.org/jira/browse/GERONIMO-1730?page=all ] Dain Sundstrom updated GERONIMO-1730: - Component: buildsystem Module migration to Maven 2: interop Key: GERONIMO-1730 URL: http://issues.apache.org/jira/browse/GERONIMO-1730 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Versions: 1.x Reporter: Jacek Laskowski Assignee: Jacek Laskowski It's a task to keep track of the progress of the module build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1693) Module migration to Maven2: j2ee-schema
[ http://issues.apache.org/jira/browse/GERONIMO-1693?page=all ] Dain Sundstrom updated GERONIMO-1693: - Component: buildsystem Module migration to Maven2: j2ee-schema --- Key: GERONIMO-1693 URL: http://issues.apache.org/jira/browse/GERONIMO-1693 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Reporter: Anita Kulshreshtha Assignee: Anita Kulshreshtha Priority: Blocker Attachments: pom.patch, pom.patch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1773) Automatic driver download is duplicated
[ http://issues.apache.org/jira/browse/GERONIMO-1773?page=all ] Dain Sundstrom updated GERONIMO-1773: - Component: console Automatic driver download is duplicated --- Key: GERONIMO-1773 URL: http://issues.apache.org/jira/browse/GERONIMO-1773 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.0 Reporter: Yiannis Mavroukakis Priority: Trivial If the page times out during the download and is refreshed, a second download is initiated. This doesn't impact the installation of the driver. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1732) Module migration to Maven 2: jetty-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1732?page=all ] Dain Sundstrom updated GERONIMO-1732: - Component: buildsystem Module migration to Maven 2: jetty-builder -- Key: GERONIMO-1732 URL: http://issues.apache.org/jira/browse/GERONIMO-1732 Project: Geronimo Type: Sub-task Security: public(Regular issues) Components: buildsystem Versions: 1.x Reporter: Jacek Laskowski Assignee: Prasad Kashyap Attachments: jetty-builder-apply-me.patch, jetty-builder.patch It's a task to keep track of the progress of the module build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1781) FileSystemRepository not able to handle entry with version number which is a single digit
[ http://issues.apache.org/jira/browse/GERONIMO-1781?page=all ] Dain Sundstrom updated GERONIMO-1781: - Component: kernel Assign To: Dain Sundstrom FileSystemRepository not able to handle entry with version number which is a single digit - Key: GERONIMO-1781 URL: http://issues.apache.org/jira/browse/GERONIMO-1781 Project: Geronimo Type: Bug Security: public(Regular issues) Components: kernel Versions: 1.0, 1.1, 1.2 Reporter: Vamsavardhana Reddy Assignee: Dain Sundstrom Priority: Minor Fix For: 1.1 I see the following in FileSystemRepository.java Pattern.compile((.+)/(.+)s/(.+)-([0-9].+)\\.([^0-9]+)); This reqular expression is not matching an entry like the following. group/jars/artifact-1.jar Here the version number is 1, a single digit. FIX: Change to Pattern.compile((.+)/(.+)s/(.+)-([0-9].*)\\.([^0-9]+)) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1783) Welcome application i18n
[ http://issues.apache.org/jira/browse/GERONIMO-1783?page=all ] Dain Sundstrom updated GERONIMO-1783: - Component: console sample apps Fix Version: 1.2 Welcome application i18n Key: GERONIMO-1783 URL: http://issues.apache.org/jira/browse/GERONIMO-1783 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: console, sample apps Reporter: Yeray Cabrera Santana Priority: Minor Fix For: 1.2 Attachments: patch.txt, welcome.diff Patch for Welcome app includes i18n and Spanish translation. This patch depends on taglibs-i18n-1.0.jar which is not available on any maven repo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1686) Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work
[ http://issues.apache.org/jira/browse/GERONIMO-1686?page=all ] Dain Sundstrom updated GERONIMO-1686: - Component: specs Fix Version: 1.2 Servlet 2.5 and JSP 2.1 api jars for JavaEE 5 work -- Key: GERONIMO-1686 URL: http://issues.apache.org/jira/browse/GERONIMO-1686 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: specs Reporter: Bill Dudney Assignee: Jeff Genender Priority: Minor Fix For: 1.2 Attachments: jee5_exp.patch, jee5_exp_servlet.patch, servlet_fixes.patch I'm typing in the Servlet 2.5 and JSP 2.1 api's and will post a patch the week of 3/6/06. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1664) Export / Import configurations capability
[ http://issues.apache.org/jira/browse/GERONIMO-1664?page=all ] Dain Sundstrom updated GERONIMO-1664: - Component: console Assign To: Aaron Mulder Export / Import configurations capability - Key: GERONIMO-1664 URL: http://issues.apache.org/jira/browse/GERONIMO-1664 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: console Versions: 1.0 Reporter: Hernan Cunico Assignee: Aaron Mulder Priority: Minor Fix For: 1.2 It would be nice to have the option to export (from both command line and Admin Console) applications as well as any other configuration (connection pools, security realms, entire server configuration, etc). Having the export capability will provide an alternative method for moving applications and configurations across Geronimo servers. It would also support/promote a standard procedure for backup and restore. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1703) ServerInfo.getBaseDirectory() returns null
[ http://issues.apache.org/jira/browse/GERONIMO-1703?page=all ] Dain Sundstrom updated GERONIMO-1703: - Component: console Assign To: Aaron Mulder My guess is this has already been fixed in 1.1 ServerInfo.getBaseDirectory() returns null -- Key: GERONIMO-1703 URL: http://issues.apache.org/jira/browse/GERONIMO-1703 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.0, 1.1, 1.2 Environment: Sun JDK 1.4.2_08, Win XP, Geronimo-Tomcat Reporter: Vamsavardhana Reddy Assignee: Aaron Mulder Priority: Minor Fix For: 1.2 Attachments: ServerInfoWebApp.war Calling getBaseDirectory on org.apache.geronimo.system.serverinfo.ServerInfo returned by KernelManagementHelper.getServerInfo() returns null instead of Geronimo Base Directory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1532) NullPointerException when a badly named jar is put into repository directory
[ http://issues.apache.org/jira/browse/GERONIMO-1532?page=all ] Dain Sundstrom updated GERONIMO-1532: - Component: console Fix Version: 1.1 Assign To: Aaron Mulder My guess is you have already fixed this. NullPointerException when a badly named jar is put into repository directory Key: GERONIMO-1532 URL: http://issues.apache.org/jira/browse/GERONIMO-1532 Project: Geronimo Type: Bug Security: public(Regular issues) Components: console Versions: 1.0 Reporter: Heikki Linnakangas Assignee: Aaron Mulder Priority: Minor Fix For: 1.1 Attachments: listURIs.diff I copied a JDBC driver jar to geronimo/repository-directory, thinking that geronimo would pick it up from there. What I didn't know, is that jars in the repository need to be named in a particular way. I then tried to add a Database pool using the wizard. I filled the name and type in step 1, and clicked next. Instead of step 2, I got a blank screen, and this stack trace in the log: 14:30:33,322 ERROR [DatabasePoolPortlet] Unable to render portlet java.lang.NullPointerException at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.loadDriverJARList(DatabasePoolPortlet.java:750) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.renderBasicParams(DatabasePoolPortlet.java:721) at org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.doView(DatabasePoolPortlet.java:625) at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250) at javax.portlet.GenericPortlet.render(GenericPortlet.java:178) ... The culprit seems to be the FileSystemRepository.listURIs-method, that doesn't handle invalid filenames properly, but returns nulls in the array it returns instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1472) packaging plugin creates client cars with wrong version
[ http://issues.apache.org/jira/browse/GERONIMO-1472?page=all ] Dain Sundstrom updated GERONIMO-1472: - Component: deployment packaging plugin creates client cars with wrong version --- Key: GERONIMO-1472 URL: http://issues.apache.org/jira/browse/GERONIMO-1472 Project: Geronimo Type: Bug Security: public(Regular issues) Components: deployment Versions: 1.1, 1.2 Reporter: David Jencks Assignee: David Jencks Fix For: 1.1, 1.2 In branch 1.0.1-SNAPSHOT, starting with daytrader ear 1.0, we get the main car at 1.0.1-SNAPSHOT but the client car at 1.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
G1.1 testing - default applications
The welcome app, servlets-examples, jsp-examples and ldap-demo work fine (unchanged) for both tomcat and jetty with the latest G1.1 build.. Will now try the clustering example and others.. -Dave-
[jira] Updated: (GERONIMO-1697) Can't set listen host/IP for Sun CORBA Name Service GBean
[ http://issues.apache.org/jira/browse/GERONIMO-1697?page=all ] Dain Sundstrom updated GERONIMO-1697: - Component: CORBA Can't set listen host/IP for Sun CORBA Name Service GBean - Key: GERONIMO-1697 URL: http://issues.apache.org/jira/browse/GERONIMO-1697 Project: Geronimo Type: Bug Security: public(Regular issues) Components: CORBA Reporter: Aaron Mulder The Sun CORBA Name Service wrapper GBean lets you specify the port, but not the listen hostname/IP. It should let you specify both. The class in question is: geronimo/openejb/modules/core/src/java/org/openejb/corba/SunNameService.java When this is done, the getAddress() method should be updated to return the proper listen address instead of 0.0.0.0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1574) Spring integration with Geronimo Transaction Manager
[ http://issues.apache.org/jira/browse/GERONIMO-1574?page=all ] Dain Sundstrom updated GERONIMO-1574: - Summary: Spring integration with Geronimo Transaction Manager (was: Spring integration -- wrap our components in spring interfaces) Component: transaction manager Spring integration with Geronimo Transaction Manager Key: GERONIMO-1574 URL: http://issues.apache.org/jira/browse/GERONIMO-1574 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: transaction manager Versions: 1.2 Reporter: David Jencks Assignee: David Jencks Fix For: 1.2 For a reasonable spring integration, we need to expose some of our components wrapped in spring interfaces. The most obvious is the transaction manager. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1488) externalize sensitive data out of the deployment plans
[ http://issues.apache.org/jira/browse/GERONIMO-1488?page=all ] Dain Sundstrom updated GERONIMO-1488: - Component: security Fix Version: 1.2 externalize sensitive data out of the deployment plans -- Key: GERONIMO-1488 URL: http://issues.apache.org/jira/browse/GERONIMO-1488 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: security Versions: 1.2 Reporter: simon godik Fix For: 1.2 externalize sensitive data out of deployment plans. Reference secure-vault gbean and grant gbean permission to read vault for the given alias; Gbean-permission is granted in the deployment plan; deployment plan syntax needs to be extended to support gbean permissions -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-557) smooth application upgrade/versioning
[ http://issues.apache.org/jira/browse/GERONIMO-557?page=all ] Dain Sundstrom updated GERONIMO-557: Component: deployment kernel smooth application upgrade/versioning - Key: GERONIMO-557 URL: http://issues.apache.org/jira/browse/GERONIMO-557 Project: Geronimo Type: New Feature Components: deployment, kernel Reporter: David Jencks Fix For: 1.2 There have been several requests for the ability to change fairly fundamental bits of application configuration at runtime, such as which resource a resource-ref points to. Currently the only way to do this is to redeploy the reconfigured application, and changing this would break a lot of our implementation and some of our philosophy. Perhaps a better way to approach this kind of problem is to version applications, and have a process for seamlessly switching between versions of an application. So, to change the target of a resource-ref, you'd configure a new copy of your app with the new target, deploy it, and undeploy the old version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-927) Provide a statement cache for TranQL for JDBCs drivers that don't inherintly provide this functionality.
[ http://issues.apache.org/jira/browse/GERONIMO-927?page=all ] Dain Sundstrom updated GERONIMO-927: Component: connector databases Provide a statement cache for TranQL for JDBCs drivers that don't inherintly provide this functionality. Key: GERONIMO-927 URL: http://issues.apache.org/jira/browse/GERONIMO-927 Project: Geronimo Type: New Feature Security: public(Regular issues) Components: connector, databases Versions: 1.0-M4 Environment: All Reporter: Matt Hogstrom Assignee: Matt Hogstrom Fix For: 1.1 Not all JDBC providers currently provide a statement cache on a per connection basis. This can be a very expensive operation that impacts performance of not only Geronimo but of the database being used. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: JCA Flow
I have tried but doesn't work... take a look at my XML: ?xml version=1.0 encoding=ISO-8859-1? beans xmlns=http://xbean.org/schemas/spring/1.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:sm=http://servicemix.apache.org/config/1.0; xmlns:spring=http://xbean.org/schemas/spring/1.0; xsi:schemaLocation=http://xbean.org/schemas/spring/1.0 spring-beans.xsd http://servicemix.apache.org/config/1.0 servicemix.xsd sm:container transactionManager=#transactionManager rootDir=../server createMBeanServer=false useMBeanServer=true flowName=jca MBeanServer=#mbeanServer name=jbi spring:id=jbi sm:activationSpecs/ /sm:container bean class=org.springframework.jmx.support.MBeanServerFactoryBean id=mbeanServer/ bean class=org.jencks.factory.TransactionContextManagerFactoryBean id=transactionContextManager/ bean class=org.jencks.factory.GeronimoTransactionManagerFactoryBean id=transactionManager/ /beans -- View this message in context: http://www.nabble.com/JCA-Flow-t1405473.html#a3791374 Sent from the ServiceMix - Dev forum at Nabble.com.
[jira] Closed: (GERONIMO-1611) Apache Geronimo Web site update
[ http://issues.apache.org/jira/browse/GERONIMO-1611?page=all ] Hernan Cunico closed GERONIMO-1611: --- Resolution: Fixed site updated to new template. Apache Geronimo Web site update --- Key: GERONIMO-1611 URL: http://issues.apache.org/jira/browse/GERONIMO-1611 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: website Reporter: Hernan Cunico Assignee: Hernan Cunico Attachments: site.06-02-22.zip, site.06-02-24.diff, site.diff.06-02-13.zip, site.diff.06-02-14.zip, site.diff.06-02-22.diff, site.images.06-02-13.zip, sites_geronimo.06-02-08.zip, sites_geronimo.06-02-09.zip, sites_geronimo.06-02-10.zip, sites_geronimo.06-02-13.zip, sites_geronimo.06-02-17.zip I have updated the template of the current Apache Geronimo Web site to use the one proposed from EPIQ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1357) Apache Geronimo V1.0 Documentation Draft
[ http://issues.apache.org/jira/browse/GERONIMO-1357?page=all ] Hernan Cunico resolved GERONIMO-1357: - Resolution: Fixed doc included in Geronimo release 1.0 Apache Geronimo V1.0 Documentation Draft Key: GERONIMO-1357 URL: http://issues.apache.org/jira/browse/GERONIMO-1357 Project: Geronimo Type: Improvement Security: public(Regular issues) Components: documentation Versions: 1.0 Environment: All Reporter: Hernan Cunico Assignee: Hernan Cunico Attachments: GDoc_2005_12_15.zip, GDoc_2005_12_16.zip, GERONIMO_DOC_2005_12_13.zip Better later than never, here is the updated HTML documentation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1814) Add version number XStream serialized configuration files
Add version number XStream serialized configuration files - Key: GERONIMO-1814 URL: http://issues.apache.org/jira/browse/GERONIMO-1814 Project: Geronimo Type: Improvement Security: public (Regular issues) Components: kernel Reporter: Dain Sundstrom Assigned to: Dain Sundstrom Fix For: 1.1 We should a version number on the serialized configurations so we can detect changes in the format in future version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1815) Remove empty config-store directory
Remove empty config-store directory --- Key: GERONIMO-1815 URL: http://issues.apache.org/jira/browse/GERONIMO-1815 Project: Geronimo Type: Bug Security: public (Regular issues) Components: buildsystem, Maven Plugins for G Reporter: Dain Sundstrom Fix For: 1.1 The assembly and installer plugins are creating an empty config-store directory. We no longer use a config-store directory so this code should be removed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1816) XML based serialized configurations
XML based serialized configurations --- Key: GERONIMO-1816 URL: http://issues.apache.org/jira/browse/GERONIMO-1816 Project: Geronimo Type: New Feature Security: public (Regular issues) Components: kernel Reporter: Dain Sundstrom Assigned to: Dain Sundstrom Fix For: 1.1 Configurations should be stored in an XML format instead of using Java Object Serialization. This will provide the maximum flexibility and make our configuration more future proof. It also allows an admin to directly modify the server in the case of a production outage. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Cannot build 1.1 on Windows - long file paths
The long file path problem on the windows platform isn't limited to building G1.1 on this platform. The current images are incompatible with windows even when the images are generated on a different platform.. Specifically, I built G1.1 on linux and then FTP'd the generated windows image (geronimo-tomcat-j2ee-1.1-SNAPSHOT.zip) to a windows machine.. The resulting image can't unzip on the windows platform due to the path length problem.. :( e.g. C:\z\geronimo-1.1-SNAPSHOT\repository\geronimo\webconsole-tomcat\1.1-SNAPSHOT\webconsole-tomcat-1.1-SNAPSHOT.car\geronimo-console-standard-1.1-SNAPSHOT.war\WEB-INF\classes\org\apache\geronimo\console\securitymanager\realm\SecurityRealmPortlet$ExistingRealm.class Guess this is obvious in hindsight, though was thinking it was strictly a build issue.. This absolutely needs to get fixed.. -Dave- Joe Bohn wrote: You beat me to it John I'm hitting the exact same problem. Joe John Sisson wrote: I had issues relating to long file paths when building 1.1 from my C:\dev\asf\geronimo\branches\1.1 directory, so I tried building from a shorter directory ( C:\geronimo1.1 ) and still have issues (see below). I haven't had a chance to look into this yet but I consider this to be a blocker. Once we can build on windows we then need to test that Geronimo can be installed in common locations on windows (e.g. under C:\Program Files\Geronimo-1.1 ) without encountering file path length issues. The following path (from the output below) is 317 bytes long: C:\geronimo1.1\assemblies\j2ee-installer\target\geronimo-1.1-SNAPSHOT\repository\geronimo\daytrader-derby-jetty\1.1-SNAPSHOT\daytrader-derby-jetty-1.1-SNAPSHOT.car\daytrader-web-1.1-SNAPSHOT.war\META-INF\geronimo-generated\org\apache\geronimo\axis\client\GenericServiceEndpointWrapper$$EnhancerByCGLIB$$2ae63e1d.class See http://issues.apache.org/jira/browse/GERONIMO-1790 for more info on the long file path issue. John izpack:izpack-installer-build: [echo] IZPack installer build is running. [echo] IZPack Version is 3.8.0 [java] [java] .:: IzPack - Version 3.8.0 ::. [java] [java] compiler specifications version : 1.0 [java] [java] - Copyright (C) 2001-2005 Julien Ponge [java] - Visit http://www.izforge.com/ for the latests releases [java] - Released under the terms of the Apache Software License version 2.0. [java] [java] - Processing : C:\geronimo1.1\assemblies\j2ee-installer/target/geronimo-1.1-SNAPSHOT/geronimo-izpack.xml [java] - Output : C:\geronimo1.1\assemblies\j2ee-installer/target/geronimo-installer-1.1-SNAPSHOT.jar [java] - Base path : . [java] - Kind: standard [java] - Compression : default [java] - Compr. level: -1 [java] [java] Adding resource: IzPack.uninstaller [java] Setting the installer information [java] Setting the GUI preferences [java] Adding langpack: eng [java] Adding resource: flag.eng [java] Adding resource: Installer.image [java] Adding resource: LicencePanel.licence [java] Adding resource: InfoPanel.info [java] Adding resource: userInputSpec.xml [java] Adding resource: ProcessPanel.Spec.xml [java] Adding resource: ImgPacksPanel.img.0 [java] Adding resource: ImgPacksPanel.img.1 [java] Adding resource: ImgPacksPanel.img.2 [java] Adding resource: ImgPacksPanel.img.3 [java] Adding resource: ImgPacksPanel.img.4 [java] Adding resource: ImgPacksPanel.img.5 [java] Adding resource: ImgPacksPanel.img.6 [java] Adding resource: ImgPacksPanel.img.7 [java] Adding resource: ImgPacksPanel.img.8 [java] Adding resource: ImgPacksPanel.img.9 [java] Adding resource: ImgPacksPanel.img.10 [java] Adding resource: ImgPacksPanel.img.11 [java] Adding resource: ImgPacksPanel.img.12 [java] Adding resource: ImgPacksPanel.img.13 [java] Adding resource: ImgPacksPanel.img.14 [java] Adding resource: ImgPacksPanel.img.15 [java] Adding resource: ImgPacksPanel.img.16 [java] Adding resource: ImgPacksPanel.img.17 [java] Adding resource: ImgPacksPanel.img.18 [java] Adding resource: ImgPacksPanel.img.19 [java] Adding resource: ImgPacksPanel.img.20 [java] Adding content of jar: file:/C:/Documents%20and%20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/standal one-compiler-custom-3.8.0.jar!/bin/panels/HelloPanel.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/standal one-compiler-custom-3.8.0.jar!/bin/panels/LicencePanel.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/standal one-compiler-custom-3.8.0.jar!/bin/panels/TargetPanel.jar [java] Adding content of jar: file:/C:/Documents%20and%20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/standal one-compiler-custom-3.8.0.jar!/bin/panels/ImgPacksPanel.jar [java] Adding
Re: Cannot build 1.1 on Windows - long file paths
What if you unpack with jar -xf? -dain On Apr 6, 2006, at 1:07 PM, Dave Colasurdo wrote: The long file path problem on the windows platform isn't limited to building G1.1 on this platform. The current images are incompatible with windows even when the images are generated on a different platform.. Specifically, I built G1.1 on linux and then FTP'd the generated windows image (geronimo-tomcat-j2ee-1.1-SNAPSHOT.zip) to a windows machine.. The resulting image can't unzip on the windows platform due to the path length problem.. :( e.g. C:\z\geronimo-1.1-SNAPSHOT\repository\geronimo\webconsole- tomcat\1.1-SNAPSHOT\webconsole-tomcat-1.1-SNAPSHOT.car\geronimo- console-standard-1.1-SNAPSHOT.war\WEB-INF\classes\org\apache \geronimo\console\securitymanager\realm\SecurityRealmPortlet $ExistingRealm.class Guess this is obvious in hindsight, though was thinking it was strictly a build issue.. This absolutely needs to get fixed.. -Dave- Joe Bohn wrote: You beat me to it John I'm hitting the exact same problem. Joe John Sisson wrote: I had issues relating to long file paths when building 1.1 from my C:\dev\asf\geronimo\branches\1.1 directory, so I tried building from a shorter directory ( C:\geronimo1.1 ) and still have issues (see below). I haven't had a chance to look into this yet but I consider this to be a blocker. Once we can build on windows we then need to test that Geronimo can be installed in common locations on windows (e.g. under C: \Program Files\Geronimo-1.1 ) without encountering file path length issues. The following path (from the output below) is 317 bytes long: C:\geronimo1.1\assemblies\j2ee-installer\target\geronimo-1.1- SNAPSHOT\repository\geronimo\daytrader-derby-jetty\1.1-SNAPSHOT \daytrader-derby-jetty-1.1-SNAPSHOT.car\daytrader-web-1.1- SNAPSHOT.war\META-INF\geronimo-generated\org\apache\geronimo\axis \client\GenericServiceEndpointWrapper$$EnhancerByCGLIB$ $2ae63e1d.class See http://issues.apache.org/jira/browse/GERONIMO-1790 for more info on the long file path issue. John izpack:izpack-installer-build: [echo] IZPack installer build is running. [echo] IZPack Version is 3.8.0 [java] [java] .:: IzPack - Version 3.8.0 ::. [java] [java] compiler specifications version : 1.0 [java] [java] - Copyright (C) 2001-2005 Julien Ponge [java] - Visit http://www.izforge.com/ for the latests releases [java] - Released under the terms of the Apache Software License version 2.0. [java] [java] - Processing : C:\geronimo1.1\assemblies\j2ee- installer/target/geronimo-1.1-SNAPSHOT/geronimo-izpack.xml [java] - Output : C:\geronimo1.1\assemblies\j2ee- installer/target/geronimo-installer-1.1-SNAPSHOT.jar [java] - Base path : . [java] - Kind: standard [java] - Compression : default [java] - Compr. level: -1 [java] [java] Adding resource: IzPack.uninstaller [java] Setting the installer information [java] Setting the GUI preferences [java] Adding langpack: eng [java] Adding resource: flag.eng [java] Adding resource: Installer.image [java] Adding resource: LicencePanel.licence [java] Adding resource: InfoPanel.info [java] Adding resource: userInputSpec.xml [java] Adding resource: ProcessPanel.Spec.xml [java] Adding resource: ImgPacksPanel.img.0 [java] Adding resource: ImgPacksPanel.img.1 [java] Adding resource: ImgPacksPanel.img.2 [java] Adding resource: ImgPacksPanel.img.3 [java] Adding resource: ImgPacksPanel.img.4 [java] Adding resource: ImgPacksPanel.img.5 [java] Adding resource: ImgPacksPanel.img.6 [java] Adding resource: ImgPacksPanel.img.7 [java] Adding resource: ImgPacksPanel.img.8 [java] Adding resource: ImgPacksPanel.img.9 [java] Adding resource: ImgPacksPanel.img.10 [java] Adding resource: ImgPacksPanel.img.11 [java] Adding resource: ImgPacksPanel.img.12 [java] Adding resource: ImgPacksPanel.img.13 [java] Adding resource: ImgPacksPanel.img.14 [java] Adding resource: ImgPacksPanel.img.15 [java] Adding resource: ImgPacksPanel.img.16 [java] Adding resource: ImgPacksPanel.img.17 [java] Adding resource: ImgPacksPanel.img.18 [java] Adding resource: ImgPacksPanel.img.19 [java] Adding resource: ImgPacksPanel.img.20 [java] Adding content of jar: file:/C:/Documents%20and% 20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/ standal one-compiler-custom-3.8.0.jar!/bin/panels/HelloPanel.jar [java] Adding content of jar: file:/C:/Documents%20and% 20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/ standal one-compiler-custom-3.8.0.jar!/bin/panels/LicencePanel.jar [java] Adding content of jar: file:/C:/Documents%20and% 20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/ standal one-compiler-custom-3.8.0.jar!/bin/panels/TargetPanel.jar [java] Adding content of jar: file:/C:/Documents%20and%
Re: Cannot build 1.1 on Windows - long file paths
I am having basically the same issue building directly on Windows. When the build gets to the izpack section it fails. I check the assemblies\j2ee-installer\target directory and it cascades recursively, in fact I am not able to delete that directory (yet). Any subsequent build attempts will also fail since maven will fail to delete the target directory. Cheers! Hernan Dain Sundstrom wrote: What if you unpack with jar -xf? -dain On Apr 6, 2006, at 1:07 PM, Dave Colasurdo wrote: The long file path problem on the windows platform isn't limited to building G1.1 on this platform. The current images are incompatible with windows even when the images are generated on a different platform.. Specifically, I built G1.1 on linux and then FTP'd the generated windows image (geronimo-tomcat-j2ee-1.1-SNAPSHOT.zip) to a windows machine.. The resulting image can't unzip on the windows platform due to the path length problem.. :( e.g. C:\z\geronimo-1.1-SNAPSHOT\repository\geronimo\webconsole- tomcat\1.1-SNAPSHOT\webconsole-tomcat-1.1-SNAPSHOT.car\geronimo- console-standard-1.1-SNAPSHOT.war\WEB-INF\classes\org\apache \geronimo\console\securitymanager\realm\SecurityRealmPortlet $ExistingRealm.class Guess this is obvious in hindsight, though was thinking it was strictly a build issue.. This absolutely needs to get fixed.. -Dave- Joe Bohn wrote: You beat me to it John I'm hitting the exact same problem. Joe John Sisson wrote: I had issues relating to long file paths when building 1.1 from my C:\dev\asf\geronimo\branches\1.1 directory, so I tried building from a shorter directory ( C:\geronimo1.1 ) and still have issues (see below). I haven't had a chance to look into this yet but I consider this to be a blocker. Once we can build on windows we then need to test that Geronimo can be installed in common locations on windows (e.g. under C: \Program Files\Geronimo-1.1 ) without encountering file path length issues. The following path (from the output below) is 317 bytes long: C:\geronimo1.1\assemblies\j2ee-installer\target\geronimo-1.1- SNAPSHOT\repository\geronimo\daytrader-derby-jetty\1.1-SNAPSHOT \daytrader-derby-jetty-1.1-SNAPSHOT.car\daytrader-web-1.1- SNAPSHOT.war\META-INF\geronimo-generated\org\apache\geronimo\axis \client\GenericServiceEndpointWrapper$$EnhancerByCGLIB$ $2ae63e1d.class See http://issues.apache.org/jira/browse/GERONIMO-1790 for more info on the long file path issue. John izpack:izpack-installer-build: [echo] IZPack installer build is running. [echo] IZPack Version is 3.8.0 [java] [java] .:: IzPack - Version 3.8.0 ::. [java] [java] compiler specifications version : 1.0 [java] [java] - Copyright (C) 2001-2005 Julien Ponge [java] - Visit http://www.izforge.com/ for the latests releases [java] - Released under the terms of the Apache Software License version 2.0. [java] [java] - Processing : C:\geronimo1.1\assemblies\j2ee- installer/target/geronimo-1.1-SNAPSHOT/geronimo-izpack.xml [java] - Output : C:\geronimo1.1\assemblies\j2ee- installer/target/geronimo-installer-1.1-SNAPSHOT.jar [java] - Base path : . [java] - Kind: standard [java] - Compression : default [java] - Compr. level: -1 [java] [java] Adding resource: IzPack.uninstaller [java] Setting the installer information [java] Setting the GUI preferences [java] Adding langpack: eng [java] Adding resource: flag.eng [java] Adding resource: Installer.image [java] Adding resource: LicencePanel.licence [java] Adding resource: InfoPanel.info [java] Adding resource: userInputSpec.xml [java] Adding resource: ProcessPanel.Spec.xml [java] Adding resource: ImgPacksPanel.img.0 [java] Adding resource: ImgPacksPanel.img.1 [java] Adding resource: ImgPacksPanel.img.2 [java] Adding resource: ImgPacksPanel.img.3 [java] Adding resource: ImgPacksPanel.img.4 [java] Adding resource: ImgPacksPanel.img.5 [java] Adding resource: ImgPacksPanel.img.6 [java] Adding resource: ImgPacksPanel.img.7 [java] Adding resource: ImgPacksPanel.img.8 [java] Adding resource: ImgPacksPanel.img.9 [java] Adding resource: ImgPacksPanel.img.10 [java] Adding resource: ImgPacksPanel.img.11 [java] Adding resource: ImgPacksPanel.img.12 [java] Adding resource: ImgPacksPanel.img.13 [java] Adding resource: ImgPacksPanel.img.14 [java] Adding resource: ImgPacksPanel.img.15 [java] Adding resource: ImgPacksPanel.img.16 [java] Adding resource: ImgPacksPanel.img.17 [java] Adding resource: ImgPacksPanel.img.18 [java] Adding resource: ImgPacksPanel.img.19 [java] Adding resource: ImgPacksPanel.img.20 [java] Adding content of jar: file:/C:/Documents%20and% 20Settings/sissonj/.geronimo-1.1.x-maven/repository/geronimo/jars/ standal one-compiler-custom-3.8.0.jar!/bin/panels/HelloPanel.jar [java] Adding content of jar: file:/C:/Documents%20and%
