date:20060607


On 6/7/06, Donald Woods <[EMAIL PROTECTED]> wrote:

Why shouldn't the Plugin support be as robust as module dependencies and
allow the user providing the plugin to decide if they can support
geronimo_version=*, 1.* or 1.1* ?  Limiting the plugins to only support
predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to
me and doesn't follow previous email threads about not deviating from
Maven2 versioning behavior...


But what you've said here is "why shouldn't the plugin support be as
robust as A and allow B" where A != B.  Module dependencies let you
specify an exact version or no version.  Plugin dependencies also let
you specify an exact version or no version.  Neither of these support
1.* or 1.1*.


Just as with the Tomcat JSP/Servlet Examples, you could easily provide a
Plugin which should work on all 1.x releases


My preference it to opt-in supported version, not opt-out unsupported
versions.  So I'd like the plugin developer to try a plugin on a
Geronimo version and if it works, list that version as supported.  The
alternative will most likely lead to Geronimo being willing to install
a plugin but the plugin not working.  If we get fancier version
dependencies we can consider things like "1.1.*" but I'm not sure I
like that.  I'm willing to be convinced, but I'd want to hear from
more plugin developers/maintainers.

Thanks,
   Aaron

[jira] Resolved: (GERONIMO-2054) http://geronimo.apache.org/xml/ns/j2ee/web-1.0 name spaces are not upgraded by Upgrade1_0To1_1

2006-06-07 Thread Kevan Miller (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-2054?page=all ]
 
Kevan Miller resolved GERONIMO-2054:


Fix Version: 1.1
 (was: 1.2)
 Resolution: Fixed

Fix was applied to both branches/1.1 and trunk

> http://geronimo.apache.org/xml/ns/j2ee/web-1.0 name spaces are not upgraded 
> by Upgrade1_0To1_1
> --
>
>  Key: GERONIMO-2054
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2054
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
> Versions: 1.1
> Reporter: Kevan Miller
> Assignee: Kevan Miller
>  Fix For: 1.1

>
> Upgrade1_0To1_1.java is missing a rule to upgrade 
> http://geronimo.apache.org/xml/ns/j2ee/web-1.0 to 
> http://geronimo.apache.org/xml/ns/j2ee/web-1.1
> This means that some geronimo web plans will not be upgraded properly.

-- 
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: Please reverse these commits...Re: svn commit: r412604 - in /geronimo/branches/1.1: applications/console-standard/src/java/org/apache/geronimo/console/car/ assemblies/j2ee-jetty-server/src/var/con

t;Unable to save plugin metadata for
>> "+metadata.getModuleId(), e);
>>  }
>> -Document doc = writePluginMetadata(metadata);
>> -TransformerFactory xfactory =
>> TransformerFactory.newInstance();
>> -Transformer xform = xfactory.newTransformer();
>> -xform.setOutputProperty(OutputKeys.INDENT, "yes");
>> -
>> xform.setOutputProperty("{http://xml.apache.org/xslt}indent-amount";,
>> "2");
>> -xform.transform(new DOMSource(doc), new StreamResult(xml));
>> -} catch (Exception e) {
>> -log.error("Unable to save plugin metadata for
>> "+metadata.getModuleId(), e);
>>  }
>>  }
>>
>> @@ -1522,10 +1585,14 @@
>>  copy.appendChild(doc.createTextNode(file.getSourceFile()));
>>  config.appendChild(copy);
>>  }
>> -for (int i = 0; i < data.getConfigXmls().length; i++) {
>> -GBeanOverride override = data.getConfigXmls()[i];
>> -Element gbean = override.writeXml(doc, config);
>> -gbean.setAttribute("xmlns",
>> "http://geronimo.apache.org/xml/ns/attributes-1.1";);
>> +if(data.getConfigXmls().length > 0) {
>> +Element content = doc.createElement("config-xml-content");
>> +for (int i = 0; i < data.getConfigXmls().length; i++) {
>> +GBeanOverride override = data.getConfigXmls()[i];
>> +Element gbean = override.writeXml(doc, content);
>> +gbean.setAttribute("xmlns",
>> "http://geronimo.apache.org/xml/ns/attributes-1.1";);
>> +}
>> +config.appendChild(content);
>>  }
>>  return doc;
>>  }
>>
>> Modified:
>> 
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/plugin/PluginRepositoryDownloader.java
>>
>> URL:
>> 
http://svn.apache.org/viewvc/geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/plugin/PluginRepositoryDownloader.java?rev=412604&r1=412603&r2=412604&view=diff
>>
>> 
==
>>
>> ---
>> 
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/plugin/PluginRepositoryDownloader.java
>> (original)
>> +++
>> 
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/plugin/PluginRepositoryDownloader.java
>> Wed Jun  7 15:56:52 2006
>> @@ -76,7 +76,7 @@
>>  for (int i = 0; i < downloadRepositories.size(); i++) {
>>  String url = (String) downloadRepositories.get(i);
>>  try {
>> -list.add(new URL(url));
>> +list.add(new URL(url.trim()));
>>  } catch (MalformedURLException e) {
>>  log.error("Unable to format plugin repository URL
>> "+url, e);
>>  }
>> @@ -84,7 +84,7 @@
>>  for (int i = 0; i < userRepositories.size(); i++) {
>>  String url = (String) userRepositories.get(i);
>>  try {
>> -list.add(new URL(url));
>> +list.add(new URL(url.trim()));
>>  } catch (MalformedURLException e) {
>>  log.error("Unable to format plugin repository URL
>> "+url, e);
>>  }
>>
>> Modified:
>> 
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/util/PluginRepositoryExporter.java
>>
>> URL:
>> 
http://svn.apache.org/viewvc/geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/util/PluginRepositoryExporter.java?rev=412604&r1=412603&r2=412604&view=diff
>>
>> 
==
>>
>> ---
>> 
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/util/PluginRepositoryExporter.java
>> (original)
>> +++
>> 
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/util/PluginRepositoryExporter.java
>> Wed Jun  7 15:56:52 2006
>> @@ -26,6 +26,8 @@
>>  import java.util.SortedSet;
>>  import java.util.Properties;
>>  import java.util.HashMap;
>> +import java.util.List;
>> +import java.util.ArrayList;
>>  import javax.xml.parsers.DocumentBuilder;
>>  import javax.xml.parsers.DocumentBuilderFactory;
>>  import javax.xml.parsers.ParserConfigurati

[jira] Resolved: (GERONIMO-1774) baseDir NPE in org.apache.geronimo.deployment.DeploymentContext

 [ http://issues.apache.org/jira/browse/GERONIMO-1774?page=all ]
 
Aaron Mulder resolved GERONIMO-1774:


Resolution: Cannot Reproduce

Haven't seen this in 1.1.  Please reopen if you see it again.

> baseDir NPE in org.apache.geronimo.deployment.DeploymentContext
> ---
>
>  Key: GERONIMO-1774
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1774
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: buildsystem, deployment
>  Environment: Windows XP
> Reporter: John Sisson
> Priority: Minor
>  Fix For: 1.1

>
> Sometimes get this problem when doing a "maven new3 new4 new5" on 1.0 branch 
> rev 379335.
> The work in the 1.1 branch may fix this problem.  Recording problem for 
> future reference.
> C:\dev\asf\geronimo\branches\1.0>SET MAVEN_OPTS=%MAVEN_OPTS% -ea
> C:\dev\asf\geronimo\branches\1.0>SET 
> ASSEMBLY_OPTS=-Dgeronimo.assembly.zip=true -Dgeronimo.assembly.tar=false
> C:\dev\asf\geronimo\branches\1.0>maven new3 new4 new5 -Dmaven.test.skip=true 
> -Dmaven.home.local="C:\Documents and Settings\sissonj\.geronimo-1.0.x-maven" 
> -Dmaven.itest.skip=true %ASSEMBLY_OPTS% %1 %2 %3 %4 %5 %6
> 
> +
> | configurations Daytrader using derby deployed on jetty
> | Memory: 46M/59M
> +
> DEPRECATED: the default goal should be specified in the  section of 
> project.xml instead of maven.xml
> DEPRECATED: the default goal should be specified in the  section of 
> project.xml instead of maven.xml
> build:end:
> You are working offline so the build will continue, but 
> geronimo-daytrader-derby-db-1.0.1-SNAPSHOT.jar may be out of date!
> You are working offline so the build will continue, but 
> daytrader-ear-1.0.1-SNAPSHOT.ear may be out of date!
> build:start:
> multiproject:install-callback:
> [echo] Running car:install for Daytrader using derby deployed on jetty
> Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'.
> 51476 [main] ERROR org.apache.geronimo.deployment.Deployer  - Deployment 
> failed due to
> java.lang.AssertionError: baseDir is null
> at 
> org.apache.geronimo.deployment.DeploymentContext.(DeploymentContext.java:89)
> at 
> org.apache.geronimo.deployment.DeploymentContext.(DeploymentContext.java:85)
> at 
> org.apache.geronimo.j2ee.deployment.EARContext.(EARContext.java:60)
> at 
> org.apache.geronimo.client.builder.AppClientModuleBuilder.addGBeans(AppClientModuleBuilder.java:348)
> at 
> org.apache.geronimo.client.builder.AppClientModuleBuilder$$FastClassByCGLIB$$93137659.invoke()
> 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.j2ee.deployment.ModuleBuilder$$EnhancerByCGLIB$$6586a92e.addGBeans()
> at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:402)
> at 
> org.apache.geronimo.j2ee.deployment.EARConfigBuilder$$FastClassByCGLIB$$38e56ec6.invoke()
> 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.deployment.ConfigurationBuilder$$EnhancerByCGLIB$$7173b1a0.buildConfiguration()
> at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:279)
> at 
> org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke()
> 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 
> or

[jira] Commented: (GERONIMO-1887) Remove unneeded jars from console WEB-INF/lib directories

[ 
http://issues.apache.org/jira/browse/GERONIMO-1887?page=comments#action_12415269
 ] 

Aaron Mulder commented on GERONIMO-1887:


The Jasper dependencies seem to be gone, but not the Castor dependencies

> Remove unneeded jars from console WEB-INF/lib directories
> -
>
>  Key: GERONIMO-1887
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1887
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.x
> Reporter: Paul McMahan
> Assignee: Aaron Mulder
> Priority: Minor
>  Fix For: 1.1

>
> Several of the jars in the console's WEB-INF/lib directories are unneeded
> -  both copies of jasper-compiler-5.5.12.jar (400K each)
> -  both copies of jasper-runtime-5.5.12.jar (80K each)
> -  the copy of castor-0.9.5.3.jar in console-standard (1.7M)
> Removing these jars will decrease the server footprint and binary image 
> download size.

-- 
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-1950) Plugins should be able to specify config.xml settings to include explicitly

 [ http://issues.apache.org/jira/browse/GERONIMO-1950?page=all ]
 
Aaron Mulder resolved GERONIMO-1950:


Resolution: Fixed

Previously fixed

> Plugins should be able to specify config.xml settings to include explicitly
> ---
>
>  Key: GERONIMO-1950
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1950
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Minor
>  Fix For: 1.1

>
> When a plugin is deployed, it should be possible for it to indicate that 
> certain settings should be displayed in config.xml.  This would be used for 
> settings that are most likely to be overridden, such as a network port, 
> working directory on disk, 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] Resolved: (GERONIMO-1993) Build failure during assembly of j2ee-installer

 [ http://issues.apache.org/jira/browse/GERONIMO-1993?page=all ]
 
Aaron Mulder resolved GERONIMO-1993:


Resolution: Cannot Reproduce

> Build failure during assembly of j2ee-installer
> ---
>
>  Key: GERONIMO-1993
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1993
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: installer
> Versions: 1.1
>  Environment: Win XP
> Reporter: Anita Kulshreshtha
> Assignee: Anita Kulshreshtha
> Priority: Minor
>  Fix For: 1.1
>  Attachments: j2ee-installer.patch
>
> The build is failing during the assembly of j2ee-installer. The installer 
> still allows the jsp-examples-* and servlet-examples-* cars to be 
> installed in the server repository. The other servers i.e. j2ee-*-server do 
> not install these configurations anymore. We should remove these from the 
> installer as well. This may not be an issue on linux machines.
> ..
>[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/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/HelloPanel.jar
> [java] Adding content of jar: 
> file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/LicencePanel.jar
> [java] Adding content of jar: 
> file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/TargetPanel.jar
> [java] Adding content of jar: 
> file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ImgPacksPanel.jar
> [java] Adding content of jar: 
> file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar
> [java] Adding content of jar: 
> file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar
> [java] Adding content of jar: 
> file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar
> [java] Adding content of jar: 
> file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar
> [java] Adding content of jar: 
> file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar
> [java] Adding content of jar: 
> file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar
> [java] Adding content of jar: 
> file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar
> [java] Adding content of jar: 
> file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar
> [java] Adding content of jar: 
> file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar
> [java] Adding content of jar: 
> file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar
> [java] Adding content of jar: 
> file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ValidatePackSelections.jar
> [java] Adding content of jar: 
> file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/InstallPanel.jar
> [java] Adding content of jar: 
> file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/ProcessPanel.jar
> [java] Adding content of jar: 
> file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/InfoPanel.jar
> [java] Adding content of jar: 
> file:/C:/Documents%20and%20Settings/User/.maven/repository/geronim
> o/jars/standalone-compiler-custom-3.8.0.jar!/bin/panels/FinishPanel.jar
> [java] -> Fatal error :
> [java]
> D:\X\geronimo\geronimo-1.1\assemblies\j2ee-insta

[jira] Updated: (GERONIMO-2054) http://geronimo.apache.org/xml/ns/j2ee/web-1.0 name spaces are not upgraded by Upgrade1_0To1_1

 [ http://issues.apache.org/jira/browse/GERONIMO-2054?page=all ]

Aaron Mulder updated GERONIMO-2054:
---

Fix Version: 1.2
 (was: 1.1)

> http://geronimo.apache.org/xml/ns/j2ee/web-1.0 name spaces are not upgraded 
> by Upgrade1_0To1_1
> --
>
>  Key: GERONIMO-2054
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2054
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
> Versions: 1.1
> Reporter: Kevan Miller
> Assignee: Kevan Miller
>  Fix For: 1.2

>
> Upgrade1_0To1_1.java is missing a rule to upgrade 
> http://geronimo.apache.org/xml/ns/j2ee/web-1.0 to 
> http://geronimo.apache.org/xml/ns/j2ee/web-1.1
> This means that some geronimo web plans will not be upgraded properly.

-- 
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-2024) namespace updates were turned off in 1.1

 [ http://issues.apache.org/jira/browse/GERONIMO-2024?page=all ]
 
Aaron Mulder resolved GERONIMO-2024:


Resolution: Fixed

I haven't noticed any bad effects.  :)

> namespace updates were turned off in 1.1
> 
>
>  Key: GERONIMO-2024
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2024
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: deployment
> Versions: 1.1
> Reporter: David Jencks
> Assignee: David Jencks
>  Fix For: 1.1

>
> apparently early in the 1.1 branch namespace conversions were turned off in 
> org.apache.geronimo.deployment.xmlbeans.XmlBeansUtil line 112.  I'm going to 
> turn them back on this is a notice to watch if anything bad happens.

-- 
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] Commented: (GERONIMO-1984) New Keystore portlet - Add Trust Certificate throws exception

[ 
http://issues.apache.org/jira/browse/GERONIMO-1984?page=comments#action_12415266
 ] 

Aaron Mulder commented on GERONIMO-1984:


Can you post a sample certificate that demonstrates the problem?

> New Keystore portlet - Add Trust Certificate throws exception
> -
>
>  Key: GERONIMO-1984
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1984
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: console
> Versions: 1.1
>  Environment: Win XP, Sun JDK 1.4.2_08
> Reporter: Vamsavardhana Reddy
>  Fix For: 1.1

>
> "Add Trust Certificate" function in the new KeyStore portlet is throwing 
> exception upon selecting the certificate file and clicking "Review 
> Certificate" button.  Log entry is given below.
> 14:48:45,617 ERROR [MultiPagePortlet] Unable to render portlet
> java.io.FileNotFoundException: C: (Access is denied)
>   at java.io.FileInputStream.open(Native Method)
>   at java.io.FileInputStream.(Unknown Source)
>   at java.io.FileInputStream.(Unknown Source)
>   at 
> org.apache.geronimo.console.keystores.ConfirmCertificateHandler.renderView(ConfirmCertificateHandler.java:61)
>   at 
> org.apache.geronimo.console.MultiPagePortlet.doView(MultiPagePortlet.java:146)
>   at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:250)
>   at javax.portlet.GenericPortlet.render(GenericPortlet.java:178)
>   at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:218)
>   at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>   at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
>   at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
>   at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.render(PortletInvokerImpl.java:73)
>   at 
> org.apache.pluto.PortletContainerImpl.renderPortlet(PortletContainerImpl.java:119)
>   at 
> org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.renderPortlet(PortletContainerWrapperImpl.java:70)
>   at 
> org.apache.pluto.portalImpl.aggregation.PortletFragment.service(PortletFragment.java:168)
>   at 
> org.apache.jsp.WEB_002dINF.aggregation.ColumnFragment_jsp._jspService(ColumnFragment_jsp.java:60)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
>   at 
> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
>   at 
> org.apache.jsp.WEB_002dINF.aggregation.RowFragment_jsp._jspService(RowFragment_jsp.java:57)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
>   at 
> org.apache.pluto.portalImpl.aggregation.AbstractFragment.service(AbstractFragment.java:112)
>   at 
> org.apache.jsp.WEB_002dINF.aggregation.PageFragment_jsp._jspService(PageFragment_jsp.java:61)
>   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)

[jira] Resolved: (GERONIMO-2023) Improve sample app install process

 [ http://issues.apache.org/jira/browse/GERONIMO-2023?page=all ]
 
Aaron Mulder resolved GERONIMO-2023:


Resolution: Fixed
 Assign To: Aaron Mulder

Previously fixed.

> Improve sample app install process
> --
>
>  Key: GERONIMO-2023
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2023
>  Project: Geronimo
> Type: Improvement
> Security: public(Regular issues) 
>   Components: sample apps
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
>  Fix For: 1.1

>
> It could have a nicer download page, and should show some kind of feedback 
> while downloading/installing (ideally AJAX, but at least printouts to stdout).

-- 
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-2090) Confirm that if version N is deployed, you can distribute version N+1 and later start it somehow

Confirm that if version N is deployed, you can distribute version N+1 and later 
start it somehow


 Key: GERONIMO-2090
 URL: http://issues.apache.org/jira/browse/GERONIMO-2090
 Project: Geronimo
Type: Bug
Security: public (Regular issues) 
  Components: kernel  
Versions: 1.1
Reporter: Aaron Mulder
 Fix For: 1.1.1


Let's say you deploy foo/MyApp/1.1/war, to 10 identical servers.

Now you have version 1.2 ready.

It would be nice if you could distribute 1.2 to all 10 servers (while 1.1 is 
still running).  Then you'd have to be able to run a command to essentially say 
"switch off 1.1 and switch on 1.2" in one shot (perhaps using a sticky load 
balancer to upgrade part of the cluster and let the rest of the cluster handle 
old sessions until they're finished).  This isn't precisely a redeploy (the 
stuff is already distributed, whereas a redeploy expects to send the new 
files).  More of a "cutover" command.

I suspect there may be bugs in the console and/or tool that manifest if you 
have two different versions of the same module installed simultaneously.  The 
deploy tool may also not let you distribute a second version of the same 
module.  But we also need a new command to do the cutover.

-- 
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-1992) Exception in ConfigManager during redeploy

 [ http://issues.apache.org/jira/browse/GERONIMO-1992?page=all ]
 
Aaron Mulder resolved GERONIMO-1992:


Resolution: Cannot Reproduce

Currently, if you redeploy version N+1, then the contents of the version N 
directory in the repository are deleted.

> Exception in ConfigManager during redeploy
> --
>
>  Key: GERONIMO-1992
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1992
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: kernel
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
>  Fix For: 1.1

>
> If you deploy version 1 of an app, then redeploy version 2, you end up with 
> version 1 in the repository (unloaded) and version 2 in the repository 
> (loaded and running).
> Then if you redeploy version 3, it dies.  I assume it's dying trying to 
> interact with the unloaded version 1.  The stack trace is:
>  org.apache.geronimo.kernel.proxy.DeadProxyException: Proxy is no longer valid
> at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:87)
> at 
> org.apache.geronimo.kernel.config.Configuration$$EnhancerByCGLIB$$2c5e9c59.getId()
> at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.getResolvedParentIds(SimpleConfigurationManager.java:1133)
> at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.reloadConfiguration(SimpleConfigurationManager.java:721)
> at
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.reloadConfiguration(SimpleConfigurationManager.java:709)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager$$FastClassByCGLIB$$ce77a924.invoke()
> A similar problem comes up in the console, presumably also trying to deal 
> with the unloaded module:
> org.apache.geronimo.kernel.proxy.DeadProxyException: Proxy is no longer valid
>   at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:87)
>   at 
> org.apache.geronimo.kernel.config.Configuration$$EnhancerByCGLIB$$d92f9886.getGBeans()
>   at 
> org.apache.geronimo.kernel.config.Configuration.findGBeanDatas(Configuration.java:692)
>   at 
> org.apache.geronimo.kernel.config.Configuration.findGBeanData(Configuration.java:625)
>   at 
> org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:610)
>   at 
> org.apache.geronimo.kernel.config.Configuration.findGBean(Configuration.java:589)
>   at 
> org.apache.geronimo.console.util.KernelManagementHelper.getModuleForConfiguration(KernelManagementHelper.java:527)
>   at 
> org.apache.geronimo.console.util.PortletManager.getModule(PortletManager.java:374)
>   at 
> org.apache.geronimo.console.configmanager.ConfigManagerPortlet.doView(ConfigManagerPortlet.java:141)
> To replicate this, deploy an application with no version in the module ID, 
> copy the directory for it out of the repository, redeploy it to a newer 
> version, and then copy the old version back into the repository (so it's in 
> the repo but the server is not aware of it per se).

-- 
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-1906) Cannot add a new connector using ActiveMQManagerGBean

 [ http://issues.apache.org/jira/browse/GERONIMO-1906?page=all ]
 
Aaron Mulder closed GERONIMO-1906:
--

Resolution: Duplicate

> Cannot add a new connector using ActiveMQManagerGBean
> -
>
>  Key: GERONIMO-1906
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1906
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: ActiveMQ
> Versions: 1.1
>  Environment: Geronimo 1.1 build, rev 396619;  activemq_version=3.2.4-SNAPSHOT
> Reporter: Paul McMahan
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.1
>  Attachments: ACTIVEMQ-gbeaninfo.diff
>
> Calling this API:
> myJMSManager.addConnector( myJMSBroker, name, protocol, host, port );
> Produces the following ST:
> java.lang.AssertionError: javax.management.MalformedObjectNameException: 
> Invalid value: 
> geronimo/activemq-broker/1.1-SNAPSHOT/car?ServiceModule=geronimo/activemq-broker/1.1-SNAPSHOT/car,j2eeType=JMSServer,name=ActiveMQ.activeio.0.0.0.0.61616-test
>   at 
> org.apache.geronimo.kernel.Jsr77Naming.createObjectName(Jsr77Naming.java:98)
>   at 
> org.apache.geronimo.kernel.Jsr77Naming.createChildName(Jsr77Naming.java:66)
>   at 
> org.apache.geronimo.kernel.Jsr77Naming.createChildName(Jsr77Naming.java:54)
>   at 
> org.activemq.gbean.management.ActiveMQManagerGBean.addConnector(ActiveMQManagerGBean.java:179)
>   at 
> org.activemq.gbean.management.ActiveMQManagerGBean$$FastClassByCGLIB$$a78b116e.invoke()
>   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:122)
>   at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:816)
>   at 
> org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57)
>   at 
> org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:35)
>   at 
> org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96)
>   at 
> org.activemq.gbean.ActiveMQManager$$EnhancerByCGLIB$$2bdd185c.addConnector()
>   at 
> org.apache.geronimo.console.util.PortletManager.createJMSConnector(PortletManager.java:274)
>   at 
> org.apache.geronimo.console.jmsmanager.server.JMSConnectorPortlet.processAction(JMSConnectorPortlet.java:80)
>   at 
> org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229)
>   at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>   at org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:574)
>   at 
> org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:499)
>   at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
>   at 
> org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
>   at 
> org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164)
>   at 
> org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82)
>   at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:688)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
>   at 
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
>   at 
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
>   at 
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
>   at 
> org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:52)
>   at 
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:482)
>   at 
> org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:336)
>   at 
> org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31)
>   at

[jira] Resolved: (GERONIMO-1990) Change "configuration" to "module" in welcome app

 [ http://issues.apache.org/jira/browse/GERONIMO-1990?page=all ]
 
Aaron Mulder resolved GERONIMO-1990:


Resolution: Invalid

There's no more "configuration" in the welcome app

> Change "configuration" to "module" in welcome app
> -
>
>  Key: GERONIMO-1990
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1990
>  Project: Geronimo
> Type: Sub-task
> Security: public(Regular issues) 
>   Components: sample apps
> Reporter: Dain Sundstrom
> Assignee: Aaron Mulder
>  Fix For: 1.1

>


-- 
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-1989) Change "configuration" to "module" in server startup

 [ http://issues.apache.org/jira/browse/GERONIMO-1989?page=all ]
 
Aaron Mulder resolved GERONIMO-1989:


Resolution: Cannot Reproduce

Says module now

> Change "configuration" to "module" in server startup
> 
>
>  Key: GERONIMO-1989
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1989
>  Project: Geronimo
> Type: Sub-task
> Security: public(Regular issues) 
>   Components: deployment
> Versions: 1.0
> Reporter: Dain Sundstrom
> Assignee: Aaron Mulder
>  Fix For: 1.1

>
> The "java -jar server.jar --long" command causes geronimo to print the 
> following:
> Configuration geronimo/rmi-naming/1.1-SNAPSHOT/car started in  1/20   1s 
> We should simply drop the word "Configuration"

-- 
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-1821) "maven new4" in 1.1 leaves loads of /tmp/packageNNNNN.tmpdir directories behind

 [ http://issues.apache.org/jira/browse/GERONIMO-1821?page=all ]
 
Aaron Mulder resolved GERONIMO-1821:


Resolution: Cannot Reproduce
 Assign To: Aaron Mulder

Doesn't happen any more

> "maven new4" in 1.1 leaves loads of /tmp/packageN.tmpdir directories 
> behind
> ---
>
>  Key: GERONIMO-1821
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1821
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: buildsystem, Maven Plugins for G
> Versions: 1.1
>  Environment: Linux
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
>  Fix For: 1.1

>
> After a few days of development, these (and other Geronimo temp) directories 
> were consuming 2.4 GB.  This is with the server shut down, so it's not like 
> they were just going to be deleted later.  We should clean up after ourselves 
> better.

-- 
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

Plugin versioning problems

2006-06-07 Thread Donald Woods

Why shouldn't the Plugin support be as robust as module dependencies and 
allow the user providing the plugin to decide if they can support 
geronimo_version=*, 1.* or 1.1* ?  Limiting the plugins to only support 
predefined 1.1, 1.2, 1.2-betaN and 1.2-rcN labels seems like a hack to 
me and doesn't follow previous email threads about not deviating from 
Maven2 versioning behavior...

Just as with the Tomcat JSP/Servlet Examples, you could easily provide a 
Plugin which should work on all 1.x releases

-Donald

Aaron Mulder wrote:

On 6/7/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:

Aaron,

Joe put out a thread about the interpretation of versions which I 
think is exactly this problem.  If
we have a well understood algorithm for Versions that includes several 
aspects of the final qualifer
(if present) this would solve the issue.  So releases is just one of 
many possible uses.   Others

include patched versions, SNAPSHOTS, etc.

Does this sound right to you?

Well, only a little.  I would rather agree to use well-defined
releases beta1-netaN followed by rc1-rcN followed by a final release.
I don't want to say a plugin will support arbitrary releases
designated by whatever token someone feels like using so long as it's
valid according to our version calculation rules -- that seems likely
to be problematic.  But in the plugin context, I'm only talking about
the "Geronimo version", not the version of individual components like
geronimo/jetty/1.1.3-patch5/car.  I agree that Joe's discussion needs
to happen in relation to dependencies and versions of specific
components *within* Geronimo.

I guess I better propose my release versioning issue in a separate
thread for 1.1.N/1.2.

Thanks,
   Aaron

Aaron Mulder wrote:
> OK, so we have a small issue with the plugins.
>
> They currently list the supported versions of Geronimo in their
> metadata.  The idea is that we don't state that a plugin will run in
> *any* version of Geronimo, we instead add each supported version as it
> is released.  Currently that list only contains 1.1-SNAPSHOT.
>
> Now I can go add 1.1-20060607 to the list of supported versions for
> the 1.1 plugins, but we'll never be able to do that in advance.  It
> would be nicer if the release candidates had more predictable names
> (rc1, rc2, rc3, etc.) so we could add them to the supported version
> list ahead of time.
>
> We also have to decide how to handle SNAPSHOT versions of Geronimo.  I
> don't really think we want the released 1.1 plugins to claim that they
> support 1.2-SNAPSHOT, which may or may not be true depending on the
> extent of the changes.  I'm currently planning to have a different
> plugin repository for each major version of Geronimo, so the 1.1
> plugin repository will be fairly stable and the 1.2 plugin repository
> may need to be rebuilt a lot and won't likely have a very complete set
> of plugins until the release.
>
> Thanks,
>Aaron
>
> On 6/7/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
>> Geronimo Users and Developers,
>>
>> We've been busy little beavers this evening and would like to share
>> the fruits of our labor.
>>
>> First, may we present the candidate build of Geronimo in Octographic
>> quality.  We have big builds,
>> little builds, some for Windows and others for Unix and of course the
>> ever enjoyable Tomcat and
>> Jetty versions.  Please take some time to take these builds and verify
>> that they meet your exacting
>> standards for a Geronimo Release.  As we like to say, "Big G, Little G
>> and things that rhyme with G."
>>
>> *Jetty*
>> 
http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.tar.gz 

>>
>> 
http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.zip 

>>
>> 
http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.tar.gz 

>>
>> 
http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.zip 

>>
>>
>> *Tomcat*
>> 
http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.tar.gz 

>>
>> 
http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.zip 

>>
>> 
http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.tar.gz 

>>
>> 
http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.zip 

>>
>>
>>
>> Remaining items.
>>
>> 1. We need the ActiveMQ 3.2.4 to be released.
>> 2. Finalize release notes (Hernan...can you pick this one up?  A set
>> for today would be good)
>> 3. Move the remainging JIRAs out of 1.1.  (Aaron, Dain, an

[jira] Resolved: (GERONIMO-1483) During Undeploy entry in config.xml is not removed

 [ http://issues.apache.org/jira/browse/GERONIMO-1483?page=all ]
 
Aaron Mulder resolved GERONIMO-1483:


Resolution: Invalid

The current (near-1.1) behavior if you uninstall B is that A is stopped, B is 
uninstalled, and the entries for both A and B in config.xml are marked as 
load=false.  B is no longer listed (e.g. in the console) as available, though A 
is.  If you then try to start A, it fails with a lifecycle failure caused by a 
missing dependency exception.  But if you install B again, then both A and B 
can be started as expected.

While this does not have the effect that the submitter seems to be after (both 
A and B uninstalled and config.xml entries deleted), I think it's correct, and 
therefore this is not really an issue.


> 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: Critical
>  Fix For: 1.1

>
> 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] Resolved: (GERONIMO-1933) Database pool usage doesn't include mandatory dependency

 [ http://issues.apache.org/jira/browse/GERONIMO-1933?page=all ]
 
Aaron Mulder resolved GERONIMO-1933:


Resolution: Fixed

Seems to have been fixed already.

> Database pool usage doesn't include mandatory dependency
> 
>
>  Key: GERONIMO-1933
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1933
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: console, databases
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Critical
>  Fix For: 1.1

>
> Sample geronimo-web.xml plan is this (note no dependency on database pool):
> 
>  xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1";>
> 
>   
> MyWebApp
>   
> 
> /MyWebApp
> true
> 
> 
> jdbc/MyDataSource
> LaptopStorePool
> 
> 

-- 
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: Please reverse these commits...Re: svn commit: r412604 - in /geronimo/branches/1.1: applications/console-standard/src/java/org/apache/geronimo/console/car/ assemblies/j2ee-jetty-server/src/var/con

;
+for (int i = 0; i < data.getConfigXmls().length; i++) {
+GBeanOverride override = data.getConfigXmls()[i];
+Element gbean = override.writeXml(doc, content);
+gbean.setAttribute("xmlns", 
"http://geronimo.apache.org/xml/ns/attributes-1.1";);

+}
+config.appendChild(content);
 }
 return doc;
 }

Modified: 
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/plugin/PluginRepositoryDownloader.java 

URL: 
http://svn.apache.org/viewvc/geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/plugin/PluginRepositoryDownloader.java?rev=412604&r1=412603&r2=412604&view=diff 

== 

--- 
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/plugin/PluginRepositoryDownloader.java 
(original)
+++ 
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/plugin/PluginRepositoryDownloader.java 
Wed Jun  7 15:56:52 2006

@@ -76,7 +76,7 @@
 for (int i = 0; i < downloadRepositories.size(); i++) {
 String url = (String) downloadRepositories.get(i);
 try {
-list.add(new URL(url));
+list.add(new URL(url.trim()));
 } catch (MalformedURLException e) {
 log.error("Unable to format plugin repository URL 
"+url, e);

 }
@@ -84,7 +84,7 @@
 for (int i = 0; i < userRepositories.size(); i++) {
 String url = (String) userRepositories.get(i);
 try {
-list.add(new URL(url));
+list.add(new URL(url.trim()));
 } catch (MalformedURLException e) {
 log.error("Unable to format plugin repository URL 
"+url, e);

 }

Modified: 
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/util/PluginRepositoryExporter.java 

URL: 
http://svn.apache.org/viewvc/geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/util/PluginRepositoryExporter.java?rev=412604&r1=412603&r2=412604&view=diff 

== 

--- 
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/util/PluginRepositoryExporter.java 
(original)
+++ 
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/util/PluginRepositoryExporter.java 
Wed Jun  7 15:56:52 2006

@@ -26,6 +26,8 @@
 import java.util.SortedSet;
 import java.util.Properties;
 import java.util.HashMap;
+import java.util.List;
+import java.util.ArrayList;
 import javax.xml.parsers.DocumentBuilder;
 import javax.xml.parsers.DocumentBuilderFactory;
 import javax.xml.parsers.ParserConfigurationException;
@@ -40,6 +42,7 @@
 import org.apache.geronimo.kernel.repository.Version;
 import 
org.apache.geronimo.system.configuration.RepositoryConfigurationStore;

 import org.apache.geronimo.system.configuration.ConfigurationStoreUtil;
+import org.apache.geronimo.system.configuration.GBeanOverride;
 import org.apache.geronimo.system.repository.Maven1Repository;
 import org.apache.geronimo.system.repository.Maven2Repository;
 import org.apache.geronimo.system.repository.CopyArtifactTypeHandler;
@@ -53,16 +56,48 @@
 import org.w3c.dom.NodeList;
 import org.w3c.dom.Text;
 import org.xml.sax.SAXException;
-import org.xml.sax.EntityResolver;
-import org.xml.sax.InputSource;
 
 /**

- * A utility that exports a repository of plugins.
+ * A utility that exports a repository of plugins.  To use this:
+ *
+ * 1) Clear out your Maven repo
+ * 2) Build Geronimo or any plugins
+ * 3) Create an output repo
+ * 4) Rsync the current plugin site to the output repo
+ * 5) Run this against your Maven repo and the output repo
+ * 6) Rsync the output repo to the plugin site
+ *
+ * It will migrate all the plugins from the Maven repo location to 
the output
+ * location, updating the supported Geronimo versions for any that 
declare only
+ * a snapshot release (using the map below), and calculating hashes 
for all the
+ * plugins.  It will update the master plugin metadata file and the 
Maven

+ * metadata file for each artifact directory.
  *
  * @version $Rev$ $Date$
  */
 public class PluginRepositoryExporter {
 private final static String NAMESPACE = 
"http://geronimo.apache.org/xml/ns/plugins-1.1";;

+private final static Map VERSION_MAP = new HashMap();
+static {
+List list = new ArrayList();
+list.add("1.1-SNAPSHOT");
+list.add("1.1-20060607");
+list.add("1.1-rc1");
+list.add("1.1-rc2");
+list.add("1.1-rc3");
+list.add("1.1");
+VERSION_MAP.put("1.1-SNAPSHOT", list);
+list = new ArrayList();
+list.add("1.2-SNAPSHOT");
+list.add("1.2

Re: svn commit: r412255 - /geronimo/trunk/etc/project.properties

Thanks for catching this Aaron.  The procedure to release to Codehaus has become manual and I missed 
this step.  My bad.  I've posted the rars.


Matt

Aaron Mulder wrote:

-1 There is no tranql-connector-1.3-SNAPSHOT.rar available.  Please
post it or revert this.

Thanks,
Aaron

On 6/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Author: hogstrom
Date: Tue Jun  6 19:14:55 2006
New Revision: 412255

URL: http://svn.apache.org/viewvc?rev=412255&view=rev
Log:
Updated to new TranQL Versions

Modified:
geronimo/trunk/etc/project.properties

Modified: geronimo/trunk/etc/project.properties
URL: 
http://svn.apache.org/viewvc/geronimo/trunk/etc/project.properties?rev=412255&r1=412254&r2=412255&view=diff 

== 


--- geronimo/trunk/etc/project.properties (original)
+++ geronimo/trunk/etc/project.properties Tue Jun  6 19:14:55 2006
@@ -91,8 +91,8 @@
 activemq_version=3.2.4-SNAPSHOT
 geronimo_version=1.2-SNAPSHOT
 openejb_version=2.1-SNAPSHOT
-tranql_version=1.3-SNAPSHOT
-tranql_connector_version=1.2-SNAPSHOT
+tranql_version=1.4-SNAPSHOT
+tranql_connector_version=1.3-SNAPSHOT
 tranql_vendors_version=1.1
 release_notes_version=1.0

[jira] Commented: (GERONIMO-2071) Move Geronimo build to M2 (new 1.2 trunk)

2006-06-07 Thread Anita Kulshreshtha (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-2071?page=comments#action_12415254
 ] 

Anita Kulshreshtha commented on GERONIMO-2071:
--

Thanks! David. I did not see g-dependency.xml for axis, tomcat  in rev 412630 
and openejb/modules/core. 

> Move Geronimo build to M2 (new 1.2 trunk)
> -
>
>  Key: GERONIMO-2071
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2071
>  Project: Geronimo
> Type: New Feature
> Security: public(Regular issues) 
>   Components: buildsystem
> Versions: 1.2
> Reporter: Prasad Kashyap
> Assignee: Jacek Laskowski
>  Fix For: 1.2
>  Attachments: applications.patch, applications.patch.zip, configs.log, 
> configs.log, configs.patch, configs.patch, deploy-tool.patch, 
> deploy-tool.patch, deployment-plugin.patch, deployment-plugin.patch, 
> geronimo-deployment-plugin-RTC-VOTE.2.patch, 
> geronimo-deployment-plugin-RTC-VOTE.patch, geronimo.patch, geronimo.patch, 
> geronimo.patch, m2-plugins.patch, modules.patch, modules.patch, mvn.log, 
> openejb.log, openejb.patch, openejb.patch, openejb.patch, openejb.patch, 
> openejb.patch, openejb.patch, pom.xml, pom.xml
>
> A lot of work for moving Geronimo build to M2 was done under G-851. 
> (http://issues.apache.org/jira/browse/GERONIMO-851) 
> The old trunk was renamed as dead-1.2. The new trunk was created from 1.1 and 
> hence the migration work needs to be done here again. This JIRA will seek to 
> consolidate the work that was done under G-851 and all it's subtasks. 
> The patch(es) here will be submitted under the RTC guidelines. Future patches 
> for migration will have to be applied on top of this one. This patch will 
> contain the parent pom, modules, openejb, configs, m2-plugins
> Any issues/concerns about migrating some pieces are well documented in G-851 
> with links to dev list archives.

-- 
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: [RTC] move geronimo/site to a trunk & branch


+1 - I wanted to update the events page and this was a problem.

Aaron Mulder wrote:

Currently, the code checked in to the geronimo/site repo does not (and
should not) correspond to our live web site.  My understanding is that
Hernan has a newer revision that he has not checked in (but it can be
seen at http://people.apache.org/~hcunico/newsite/)

I want to update the news and events on the current site to move the
expired events, add some 1.1 information, etc.  I want to do that to
the site as it exists on geronimo.apache.org site today, until we're
in agreement about what it should look like next.  Currently I can't
do that unless I edit the HTML on minotaur directly and lose any
Subversion history (I believe the content on minotaur is as of
just-before-rev-411192).

I propose we:
- move geronimo/site to geronimo/site/branches/may2006
- copy geronimo/site revision 411191 to geronimo/site/trunk
- update the site sync script on minotaur to pull from geronimo/site/trunk

Then Hernan can check his pending changes into the new branch and I
can check my news and event updates into both the branch and trunk and
sync minotaur from trunk.  When we're all agreed that the branch
content is what we want, we can either merge it to trunk or move trunk
away and move the branch to be the new trunk.

I'm taking the slightly unusual step of not attaching a patch since I
think the description above is much more meaningful than the
equivalent tremendously large patch.  Here's my +1, can I get 3 more?

Thanks,
   Aaron

Re: Please reverse these commits...Re: svn commit: r412604 - in /geronimo/branches/1.1: applications/console-standard/src/java/org/apache/geronimo/console/car/ assemblies/j2ee-jetty-server/src/var/con

java/org/apache/geronimo/system/util/PluginRepositoryExporter.java?rev=412604&r1=412603&r2=412604&view=diff
> ==
> --- 
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/util/PluginRepositoryExporter.java
 (original)
> +++ 
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/util/PluginRepositoryExporter.java
 Wed Jun  7 15:56:52 2006
> @@ -26,6 +26,8 @@
>  import java.util.SortedSet;
>  import java.util.Properties;
>  import java.util.HashMap;
> +import java.util.List;
> +import java.util.ArrayList;
>  import javax.xml.parsers.DocumentBuilder;
>  import javax.xml.parsers.DocumentBuilderFactory;
>  import javax.xml.parsers.ParserConfigurationException;
> @@ -40,6 +42,7 @@
>  import org.apache.geronimo.kernel.repository.Version;
>  import org.apache.geronimo.system.configuration.RepositoryConfigurationStore;
>  import org.apache.geronimo.system.configuration.ConfigurationStoreUtil;
> +import org.apache.geronimo.system.configuration.GBeanOverride;
>  import org.apache.geronimo.system.repository.Maven1Repository;
>  import org.apache.geronimo.system.repository.Maven2Repository;
>  import org.apache.geronimo.system.repository.CopyArtifactTypeHandler;
> @@ -53,16 +56,48 @@
>  import org.w3c.dom.NodeList;
>  import org.w3c.dom.Text;
>  import org.xml.sax.SAXException;
> -import org.xml.sax.EntityResolver;
> -import org.xml.sax.InputSource;
>
>  /**
> - * A utility that exports a repository of plugins.
> + * A utility that exports a repository of plugins.  To use this:
> + *
> + * 1) Clear out your Maven repo
> + * 2) Build Geronimo or any plugins
> + * 3) Create an output repo
> + * 4) Rsync the current plugin site to the output repo
> + * 5) Run this against your Maven repo and the output repo
> + * 6) Rsync the output repo to the plugin site
> + *
> + * It will migrate all the plugins from the Maven repo location to the output
> + * location, updating the supported Geronimo versions for any that declare 
only
> + * a snapshot release (using the map below), and calculating hashes for all 
the
> + * plugins.  It will update the master plugin metadata file and the Maven
> + * metadata file for each artifact directory.
>   *
>   * @version $Rev$ $Date$
>   */
>  public class PluginRepositoryExporter {
>  private final static String NAMESPACE = 
"http://geronimo.apache.org/xml/ns/plugins-1.1";;
> +private final static Map VERSION_MAP = new HashMap();
> +static {
> +List list = new ArrayList();
> +list.add("1.1-SNAPSHOT");
> +list.add("1.1-20060607");
> +list.add("1.1-rc1");
> +list.add("1.1-rc2");
> +list.add("1.1-rc3");
> +list.add("1.1");
> +VERSION_MAP.put("1.1-SNAPSHOT", list);
> +list = new ArrayList();
> +list.add("1.2-SNAPSHOT");
> +list.add("1.2-beta1");
> +list.add("1.2-beta2");
> +list.add("1.2-beta3");
> +list.add("1.2-rc1");
> +list.add("1.2-rc2");
> +list.add("1.2-rc3");
> +list.add("1.2");
> +VERSION_MAP.put("1.2-SNAPSHOT", list);
> +}
>  private Maven1Repository sourceRepo;
>  private Maven2Repository destRepo;
>  private Map targetVersions;
> @@ -196,6 +231,7 @@
>  if(!artifactDir.isDirectory() || !artifactDir.canRead()) 
{
>  throw new IllegalStateException("Failed to located group/artifact dir for 
"+artifact+" (got "+artifactDir.getAbsolutePath()+")");
>  }
> +updatePluginMetadata(artifact);
>  updateMavenMetadata(artifactDir, artifact);
>  }
>  }
> @@ -217,6 +253,42 @@
>
>  }
>
> +private void updatePluginMetadata(Artifact artifact) {
> +PluginMetadata data = installer.getPluginMetadata(artifact);
> +if(data == null) {
> +return;
> +}
> +if(data.getGeronimoVersions() != null && data.getGeronimoVersions().length 
== 1 &&
> +VERSION_MAP.containsKey(data.getGeronimoVersions()[0])) {
> +data.setGeronimoVersions((String[]) ((List) 
VERSION_MAP.get(data.getGeronimoVersions()[0])).toArray(new String[0]));
> +if(data.getHash() != null) {
> +data = copy(data);
> +}
> +installer.updatePluginMetadata(data);
> +}
> +}
> +
> +

Re: Maven Repo Woes - Temporary resolution in place

Not to pass the buck but we in Geronimo are using Maven I think the way it was intended to be used. 
 Certainly there are issues that are becoming apparent.  Aaron put out a good summary of the 
problem that we are experiencing.

I think this is certainly important feedback for the Maven team as well.  If we can improve our 
process then I trust that the Maven team will provide their input.

Matt

Joshua Slive wrote:

On 6/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote:

On 6/7/06, Joshua Slive <[EMAIL PROTECTED]> wrote:
> On 6/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > On 6/7/06, Joshua Slive <[EMAIL PROTECTED]> wrote:
> >
> > > And in any case, I believe that much of the problem
> > > is not with maven per se, but with how it is being used.
> >
> > How exactly?
> >
> > Cocoon/Geronimo have both hit the same problem.  The factor would 
seem

> > to be having a lot of components in your build - which I can't see as
> > being a mis-use.
>
> The part about pointing to people.apache.org as a maven repository is
> not a design flaw in maven.  The part about maven gobbling up way more
> resources than necessary probably is.

Geronimo/Cocoon and other projects did not set up the maven snapshot
repository at the ASF, they're using what has been in place for a long
time.

Perhaps you are misunderstanding my intentions.  I am not trying to
blame anybody for the current situation and ask them to do penance.
I'm trying to get them to change what they do for future releases.
What exists now and in the past and who created it has nothing to do
with that.  The fact that a maven repository exists in a particular
location does not mean it must be used.

Joshua.

[jira] Work started: (AMQ-737) for consumers especially but for producers too, it'd be good to do a brief summary on the command line of the throughput

2006-06-07 Thread Adrian Co (JIRA)

 [ https://issues.apache.org/activemq/browse/AMQ-737?page=all ]
 
Work on AMQ-737 started by Adrian Co

> for consumers especially but for producers too, it'd be good to do a brief 
> summary on the command line of the throughput
> 
>
>  Key: AMQ-737
>  URL: https://issues.apache.org/activemq/browse/AMQ-737
>  Project: ActiveMQ
> Type: Improvement

>   Components: Performance Test
> Versions: 4.0
> Reporter: james strachan
> Assignee: Adrian Co
>  Fix For: 4.1

>
>
> e.g. after running
> mvn activemq-perf:consumer
> it'd be nice to output a little summary something like
> Average throughtput: 1234.45 message/second.
> For average calulation it might be nice to ignore the first couple or the 
> highest & lowest values or something.
> Also for multiple consumers inside the JVM it might be nice to show something 
> like...
> Average throughput : 5000 msg/sec. Average per consumer: 1000 msg/sec, Min 
> consumer: 200 msg/sec, Max consumer: 1400 msg/sec
> so its easy at a glance to get a feel for the results if you are running the 
> tests from a command line

-- 
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

Please reverse these commits...Re: svn commit: r412604 - in /geronimo/branches/1.1: applications/console-standard/src/java/org/apache/geronimo/console/car/ assemblies/j2ee-jetty-server/src/var/config/

or("Unable to format plugin repository URL "+url, e);
 }
@@ -84,7 +84,7 @@
 for (int i = 0; i < userRepositories.size(); i++) {
 String url = (String) userRepositories.get(i);
 try {
-list.add(new URL(url));
+list.add(new URL(url.trim()));
 } catch (MalformedURLException e) {
 log.error("Unable to format plugin repository URL "+url, e);
 }

Modified: 
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/util/PluginRepositoryExporter.java
URL: 
http://svn.apache.org/viewvc/geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/util/PluginRepositoryExporter.java?rev=412604&r1=412603&r2=412604&view=diff
==
--- 
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/util/PluginRepositoryExporter.java
 (original)
+++ 
geronimo/branches/1.1/modules/system/src/java/org/apache/geronimo/system/util/PluginRepositoryExporter.java
 Wed Jun  7 15:56:52 2006
@@ -26,6 +26,8 @@
 import java.util.SortedSet;
 import java.util.Properties;
 import java.util.HashMap;
+import java.util.List;
+import java.util.ArrayList;
 import javax.xml.parsers.DocumentBuilder;
 import javax.xml.parsers.DocumentBuilderFactory;
 import javax.xml.parsers.ParserConfigurationException;
@@ -40,6 +42,7 @@
 import org.apache.geronimo.kernel.repository.Version;
 import org.apache.geronimo.system.configuration.RepositoryConfigurationStore;
 import org.apache.geronimo.system.configuration.ConfigurationStoreUtil;
+import org.apache.geronimo.system.configuration.GBeanOverride;
 import org.apache.geronimo.system.repository.Maven1Repository;
 import org.apache.geronimo.system.repository.Maven2Repository;
 import org.apache.geronimo.system.repository.CopyArtifactTypeHandler;
@@ -53,16 +56,48 @@
 import org.w3c.dom.NodeList;
 import org.w3c.dom.Text;
 import org.xml.sax.SAXException;
-import org.xml.sax.EntityResolver;
-import org.xml.sax.InputSource;
 
 /**

- * A utility that exports a repository of plugins.
+ * A utility that exports a repository of plugins.  To use this:
+ *
+ * 1) Clear out your Maven repo
+ * 2) Build Geronimo or any plugins
+ * 3) Create an output repo
+ * 4) Rsync the current plugin site to the output repo
+ * 5) Run this against your Maven repo and the output repo
+ * 6) Rsync the output repo to the plugin site
+ *
+ * It will migrate all the plugins from the Maven repo location to the output
+ * location, updating the supported Geronimo versions for any that declare only
+ * a snapshot release (using the map below), and calculating hashes for all the
+ * plugins.  It will update the master plugin metadata file and the Maven
+ * metadata file for each artifact directory.
  *
  * @version $Rev$ $Date$
  */
 public class PluginRepositoryExporter {
 private final static String NAMESPACE = 
"http://geronimo.apache.org/xml/ns/plugins-1.1";;
+private final static Map VERSION_MAP = new HashMap();
+static {
+List list = new ArrayList();
+list.add("1.1-SNAPSHOT");
+list.add("1.1-20060607");
+list.add("1.1-rc1");
+list.add("1.1-rc2");
+list.add("1.1-rc3");
+list.add("1.1");
+VERSION_MAP.put("1.1-SNAPSHOT", list);
+list = new ArrayList();
+list.add("1.2-SNAPSHOT");
+list.add("1.2-beta1");
+list.add("1.2-beta2");
+list.add("1.2-beta3");
+list.add("1.2-rc1");
+list.add("1.2-rc2");
+list.add("1.2-rc3");
+list.add("1.2");
+VERSION_MAP.put("1.2-SNAPSHOT", list);
+}
 private Maven1Repository sourceRepo;
 private Maven2Repository destRepo;
 private Map targetVersions;
@@ -196,6 +231,7 @@
 if(!artifactDir.isDirectory() || !artifactDir.canRead()) {
 throw new IllegalStateException("Failed to located group/artifact dir for 
"+artifact+" (got "+artifactDir.getAbsolutePath()+")");
 }
+updatePluginMetadata(artifact);
 updateMavenMetadata(artifactDir, artifact);
 }
 }
@@ -217,6 +253,42 @@
 
 }
 
+private void updatePluginMetadata(Artifact artifact) {

+PluginMetadata data = installer.getPluginMetadata(artifact);
+if(data == null) {
+return;
+}
+if(data.getGeronimoVersions() != null && data.getGeronimoVersions().length == 
1 &&
+VERSION_MAP.containsKey(data.getGeronimoVersions()[0])) {
+data.setGeronimoVersions((String[]) ((List) 
VERSION_MAP.get(data.getGeronimoVersions()[0])).toArray

Re: [RTC] move geronimo/site to a trunk & branch


Good idea

+1

-dain

On Jun 7, 2006, at 5:38 PM, Aaron Mulder wrote:


Currently, the code checked in to the geronimo/site repo does not (and
should not) correspond to our live web site.  My understanding is that
Hernan has a newer revision that he has not checked in (but it can be
seen at http://people.apache.org/~hcunico/newsite/)

I want to update the news and events on the current site to move the
expired events, add some 1.1 information, etc.  I want to do that to
the site as it exists on geronimo.apache.org site today, until we're
in agreement about what it should look like next.  Currently I can't
do that unless I edit the HTML on minotaur directly and lose any
Subversion history (I believe the content on minotaur is as of
just-before-rev-411192).

I propose we:
- move geronimo/site to geronimo/site/branches/may2006
- copy geronimo/site revision 411191 to geronimo/site/trunk
- update the site sync script on minotaur to pull from geronimo/ 
site/trunk


Then Hernan can check his pending changes into the new branch and I
can check my news and event updates into both the branch and trunk and
sync minotaur from trunk.  When we're all agreed that the branch
content is what we want, we can either merge it to trunk or move trunk
away and move the branch to be the new trunk.

I'm taking the slightly unusual step of not attaching a patch since I
think the description above is much more meaningful than the
equivalent tremendously large patch.  Here's my +1, can I get 3 more?

Thanks,
   Aaron

[RTC] move geronimo/site to a trunk & branch


Currently, the code checked in to the geronimo/site repo does not (and
should not) correspond to our live web site.  My understanding is that
Hernan has a newer revision that he has not checked in (but it can be
seen at http://people.apache.org/~hcunico/newsite/)

I want to update the news and events on the current site to move the
expired events, add some 1.1 information, etc.  I want to do that to
the site as it exists on geronimo.apache.org site today, until we're
in agreement about what it should look like next.  Currently I can't
do that unless I edit the HTML on minotaur directly and lose any
Subversion history (I believe the content on minotaur is as of
just-before-rev-411192).

I propose we:
- move geronimo/site to geronimo/site/branches/may2006
- copy geronimo/site revision 411191 to geronimo/site/trunk
- update the site sync script on minotaur to pull from geronimo/site/trunk

Then Hernan can check his pending changes into the new branch and I
can check my news and event updates into both the branch and trunk and
sync minotaur from trunk.  When we're all agreed that the branch
content is what we want, we can either merge it to trunk or move trunk
away and move the branch to be the new trunk.

I'm taking the slightly unusual step of not attaching a patch since I
think the description above is much more meaningful than the
equivalent tremendously large patch.  Here's my +1, can I get 3 more?

Thanks,
   Aaron

[jira] Resolved: (GERONIMO-2042) ConfigurationAwareReference needs Serial Version UID

 [ http://issues.apache.org/jira/browse/GERONIMO-2042?page=all ]
 
Aaron Mulder resolved GERONIMO-2042:


Resolution: Fixed
 Assign To: Aaron Mulder

> ConfigurationAwareReference needs Serial Version UID
> 
>
>  Key: GERONIMO-2042
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2042
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: kernel
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
> Priority: Blocker
>  Fix For: 1.1

>
> Just had a plugin fail to install because the serial version of 
> ConfigurationAwareReference didn't match.  Needless to say we want to avoid 
> problems causing plugins to fail to install on slightly newer Geroinmo 
> platforms wherever possible.  Maybe we should look at related code for 
> missing UIDs while we're in there.
> Caused by: java.io.IOException: Unable to deserialize GBeanData 
> geronimo/welcome-jetty/1.1-SNAPSHOT/car?J2EEApplication=null,j2eeType=WebModule,name=geronimo/welcome-jetty/1.1-SNAPSHOT/car,
>  attribute: componentContext
> at 
> org.apache.geronimo.gbean.GBeanData.readExternal(GBeanData.java:239)
> ... 64 more
> Caused by: java.io.InvalidClassException: 
> org.apache.geronimo.naming.reference.ConfigurationAwareReference; local class 
> incompatible: stream classdesc serialVersionUID = 7210513100515482358, local 
> class serialVersionUID = 283358809226901462

-- 
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-2076) Must edit config.xml to provide custom plugin install source

 [ http://issues.apache.org/jira/browse/GERONIMO-2076?page=all ]

Aaron Mulder updated GERONIMO-2076:
---

Fix Version: 1.1.1
 (was: 1.1)
   Priority: Major  (was: Critical)

> Must edit config.xml to provide custom plugin install source
> 
>
>  Key: GERONIMO-2076
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2076
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: Plugins
> Versions: 1.1
> Reporter: Aaron Mulder
>  Fix For: 1.1.1

>
> Currently we (Apache) can add new plugin install sources.  But an end user 
> cannot manually add a plugin install source without editing config.xml.  In 
> particular, you can't use the server cloning feature without editing 
> config.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] Commented: (GERONIMO-2076) Must edit config.xml to provide custom plugin install source

[ 
http://issues.apache.org/jira/browse/GERONIMO-2076?page=comments#action_12415239
 ] 

Aaron Mulder commented on GERONIMO-2076:


Added the required settings to config.xml so at least you have a place to put 
them.

> Must edit config.xml to provide custom plugin install source
> 
>
>  Key: GERONIMO-2076
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2076
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: Plugins
> Versions: 1.1
> Reporter: Aaron Mulder
> Priority: Critical
>  Fix For: 1.1.1

>
> Currently we (Apache) can add new plugin install sources.  But an end user 
> cannot manually add a plugin install source without editing config.xml.  In 
> particular, you can't use the server cloning feature without editing 
> config.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] Resolved: (GERONIMO-2089) Plugin exporter omits copy file and config.xml blocks

 [ http://issues.apache.org/jira/browse/GERONIMO-2089?page=all ]
 
Aaron Mulder resolved GERONIMO-2089:


Resolution: Fixed

> Plugin exporter omits copy file and config.xml blocks
> -
>
>  Key: GERONIMO-2089
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2089
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: Plugins
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
>  Fix For: 1.1

>


-- 
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-2088) Plugin installer writes bad XML for config.xml content

 [ http://issues.apache.org/jira/browse/GERONIMO-2088?page=all ]
 
Aaron Mulder resolved GERONIMO-2088:


Resolution: Fixed

> Plugin installer writes bad XML for config.xml content
> --
>
>  Key: GERONIMO-2088
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2088
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: Plugins
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
>  Fix For: 1.1

>
> It writes gbean elements without a surrounding config-xml-content element.

-- 
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: svn commit: r412255 - /geronimo/trunk/etc/project.properties


-1 There is no tranql-connector-1.3-SNAPSHOT.rar available.  Please
post it or revert this.

Thanks,
Aaron

On 6/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

Author: hogstrom
Date: Tue Jun  6 19:14:55 2006
New Revision: 412255

URL: http://svn.apache.org/viewvc?rev=412255&view=rev
Log:
Updated to new TranQL Versions

Modified:
geronimo/trunk/etc/project.properties

Modified: geronimo/trunk/etc/project.properties
URL: 
http://svn.apache.org/viewvc/geronimo/trunk/etc/project.properties?rev=412255&r1=412254&r2=412255&view=diff
==
--- geronimo/trunk/etc/project.properties (original)
+++ geronimo/trunk/etc/project.properties Tue Jun  6 19:14:55 2006
@@ -91,8 +91,8 @@
 activemq_version=3.2.4-SNAPSHOT
 geronimo_version=1.2-SNAPSHOT
 openejb_version=2.1-SNAPSHOT
-tranql_version=1.3-SNAPSHOT
-tranql_connector_version=1.2-SNAPSHOT
+tranql_version=1.4-SNAPSHOT
+tranql_connector_version=1.3-SNAPSHOT
 tranql_vendors_version=1.1
 release_notes_version=1.0

Re: Maven Repo Woes - Temporary resolution in place

Just for the record, whatever our temporary solution is, it's not
working.  I'm running an online build and it's been hung for like 5
minutes trying to download an ActiveMQ JAR from mortbay.org, and now
it's moved on to the next ActiveMQ JAR and it's hung again.  I had to
whack mortbay from the list to get it to move at all.

I think the only way to avoid this with Maven 1 is to put everything
in one repository and make that the only entry in our repo list.
While it's nice to have backup sites in theory, if mortbay.org is
causing timeouts, if I understand this right we're going to suffer
that lag on every SNAPSHOT (which is 99% of our downloads --
geronimo*SNAPSHOT*) since I believe for a SNAPSHOT Maven checks all
the repositories in the list.

Will the infrastructure team be peeved if we put everything in our
Solaris zone and make that the sole build repository for Geronimo?  I
don't know if the objection is to the level of traffic directed to
people.apache.org or the level of traffic in general.

Craig, to clear this up for you, in a typical Geronimo build, we
create over 100 artifacts, which are all SNAPSHOTS.  Every artifact
has at least one other module that depends on it.  With Maven
1.1-beta-2, the first time in a build that Maven finds a SNAPSHOT that
it hasn't already downloaded in the current build, it tries to
download the latest from (if I'm right above) all defined
repositories.  It does not understand that it just built that module,
it tries to download it anyway.  So we are guaranteed 100+ download
attempts, times 5 repositories, or 500+ snapshot downloads per online
build.  Often, a repository (like mortbay above) is down in such a way
to cause timeouts, which are on the order of minutes (there are
apparently some retries involved), and you get that timeout for all
100+ snapshot downloads (making for a several hundred minute delay
time on top of the normal build time).  We can't remove everything but
ibiblio from our list because we normally depend on SNAPSHOT releases
of openejb, axis, activemq, tranql, jetty, and more, and those aren't
in any one repo (certainly not on ibiblio).  We also can't expect all
Geronimo developers to maintain and build all those projects in order
to build Geronimo.

It seems like Maven 2 will help somewhat, between reduced SNAPSHOT
downloads and mirror capability.

Still, it's extremely unfortunate that your very first build as a
developer is the absolute worst-case scenario.  It would be very nice
to have an updated "Maven repo bundle" that a new developer could
download (or check out) and unpack to get all the dependencies in one
shot so their first build could be offline (or at least faster).

Thanks,
Aaron

On 6/7/06, Craig L Russell <[EMAIL PROTECTED]> wrote:

Apologies in advance if this is noisy. I've been using maven for only
a year, so I don't understand all the issues.

Maven will cache artifacts locally and if you have a dependency on a
non-snapshot version of the artifact, it only ever gets downloaded
once. From then on, it assumes that the version in your local
repository is current. Right?

If you have a dependency on a snapshot version it will attempt to
download it from a remote repository, which you can define to be e.g.
ibiblio to completely bypass any use of apache resources. (Of course,
this means that it increases the load on ibiblio but they've signed
up to be an apache mirror so they presumably know the drill).

The way we use maven is that the snapshot version dependencies are on
artifacts that can be built locally; that is, they just don't exist
on the remote repository, so maven can't find them remotely. This
can't be much of a load. Returning a 440 reply to a maven request
isn't expensive... Right?

I'm sure I'm missing something obvious, and I would like to know
where I've gone off the rails...

Thanks,

Craig

On Jun 7, 2006, at 12:57 PM, Henri Yandell wrote:

> On 6/7/06, Joshua Slive <[EMAIL PROTECTED]> wrote:
>> On 6/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
>> > On 6/7/06, Joshua Slive <[EMAIL PROTECTED]> wrote:
>> >
>> > > And in any case, I believe that much of the problem
>> > > is not with maven per se, but with how it is being used.
>> >
>> > How exactly?
>> >
>> > Cocoon/Geronimo have both hit the same problem.  The factor
>> would seem
>> > to be having a lot of components in your build - which I can't
>> see as
>> > being a mis-use.
>>
>> The part about pointing to people.apache.org as a maven repository is
>> not a design flaw in maven.  The part about maven gobbling up way
>> more
>> resources than necessary probably is.
>
> Geronimo/Cocoon and other projects did not set up the maven snapshot
> repository at the ASF, they're using what has been in place for a long
> time.
>
> Hen

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

[jira] Closed: (XBEAN-14) Add support for spring 2.0

2006-06-07 Thread Guillaume Nodet (JIRA)

 [ http://issues.apache.org/jira/browse/XBEAN-14?page=all ]
 
Guillaume Nodet closed XBEAN-14:


Resolution: Fixed

> Add support for spring 2.0
> --
>
>  Key: XBEAN-14
>  URL: http://issues.apache.org/jira/browse/XBEAN-14
>  Project: XBean
> Type: Improvement

>   Components: spring
> Reporter: Guillaume Nodet
> Assignee: Guillaume Nodet
>  Fix For: 2.4

>


-- 
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-2088) Plugin installer writes bad XML for config.xml content

 [ http://issues.apache.org/jira/browse/GERONIMO-2088?page=all ]

Aaron Mulder updated GERONIMO-2088:
---

Component: Plugins

> Plugin installer writes bad XML for config.xml content
> --
>
>  Key: GERONIMO-2088
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2088
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: Plugins
> Versions: 1.1
> Reporter: Aaron Mulder
> Assignee: Aaron Mulder
>  Fix For: 1.1

>
> It writes gbean elements without a surrounding config-xml-content element.

-- 
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-2089) Plugin exporter omits copy file and config.xml blocks

Plugin exporter omits copy file and config.xml blocks
-

 Key: GERONIMO-2089
 URL: http://issues.apache.org/jira/browse/GERONIMO-2089
 Project: Geronimo
Type: Bug
Security: public (Regular issues) 
  Components: Plugins  
Versions: 1.1
Reporter: Aaron Mulder
 Assigned to: Aaron Mulder 
 Fix For: 1.1




-- 
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: Maven Repo Woes - Temporary resolution in place

2006-06-07 Thread Craig L Russell

Apologies in advance if this is noisy. I've been using maven for only  
a year, so I don't understand all the issues.

Maven will cache artifacts locally and if you have a dependency on a  
non-snapshot version of the artifact, it only ever gets downloaded  
once. From then on, it assumes that the version in your local  
repository is current. Right?

If you have a dependency on a snapshot version it will attempt to  
download it from a remote repository, which you can define to be e.g.  
ibiblio to completely bypass any use of apache resources. (Of course,  
this means that it increases the load on ibiblio but they've signed  
up to be an apache mirror so they presumably know the drill).

The way we use maven is that the snapshot version dependencies are on  
artifacts that can be built locally; that is, they just don't exist  
on the remote repository, so maven can't find them remotely. This  
can't be much of a load. Returning a 440 reply to a maven request  
isn't expensive... Right?

I'm sure I'm missing something obvious, and I would like to know  
where I've gone off the rails...

Thanks,

Craig

On Jun 7, 2006, at 12:57 PM, Henri Yandell wrote:

On 6/7/06, Joshua Slive <[EMAIL PROTECTED]> wrote:

On 6/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> On 6/7/06, Joshua Slive <[EMAIL PROTECTED]> wrote:
>
> > And in any case, I believe that much of the problem
> > is not with maven per se, but with how it is being used.
>
> How exactly?
>
> Cocoon/Geronimo have both hit the same problem.  The factor  
would seem
> to be having a lot of components in your build - which I can't  
see as

> being a mis-use.

The part about pointing to people.apache.org as a maven repository is
not a design flaw in maven.  The part about maven gobbling up way  
more

resources than necessary probably is.

Geronimo/Cocoon and other projects did not set up the maven snapshot
repository at the ASF, they're using what has been in place for a long
time.

Hen

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

smime.p7s
Description: S/MIME cryptographic signature

Re: Maven Repo Woes - Temporary resolution in place

On 6/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote:

On 6/7/06, Joshua Slive <[EMAIL PROTECTED]> wrote:
> On 6/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> > On 6/7/06, Joshua Slive <[EMAIL PROTECTED]> wrote:
> >
> > > And in any case, I believe that much of the problem
> > > is not with maven per se, but with how it is being used.
> >
> > How exactly?
> >
> > Cocoon/Geronimo have both hit the same problem.  The factor would seem
> > to be having a lot of components in your build - which I can't see as
> > being a mis-use.
>
> The part about pointing to people.apache.org as a maven repository is
> not a design flaw in maven.  The part about maven gobbling up way more
> resources than necessary probably is.

Geronimo/Cocoon and other projects did not set up the maven snapshot
repository at the ASF, they're using what has been in place for a long
time.

Perhaps you are misunderstanding my intentions.  I am not trying to
blame anybody for the current situation and ask them to do penance.
I'm trying to get them to change what they do for future releases.
What exists now and in the past and who created it has nothing to do
with that.  The fact that a maven repository exists in a particular
location does not mean it must be used.

Joshua.

[jira] Created: (GERONIMO-2088) Plugin installer writes bad XML for config.xml content

Plugin installer writes bad XML for config.xml content
--

 Key: GERONIMO-2088
 URL: http://issues.apache.org/jira/browse/GERONIMO-2088
 Project: Geronimo
Type: Bug
Security: public (Regular issues) 
Versions: 1.1
Reporter: Aaron Mulder
 Assigned to: Aaron Mulder 
 Fix For: 1.1


It writes gbean elements without a surrounding config-xml-content element.

-- 
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] Commented: (GERONIMO-2071) Move Geronimo build to M2 (new 1.2 trunk)

2006-06-07 Thread David Jencks (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-2071?page=comments#action_12415217
 ] 

David Jencks commented on GERONIMO-2071:


Following a suggestion from anita I moved the location of the source m2 files 
to not conflict with m1.  Committed in rev 412575.  Files are in src/resources2

> Move Geronimo build to M2 (new 1.2 trunk)
> -
>
>  Key: GERONIMO-2071
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2071
>  Project: Geronimo
> Type: New Feature
> Security: public(Regular issues) 
>   Components: buildsystem
> Versions: 1.2
> Reporter: Prasad Kashyap
> Assignee: Jacek Laskowski
>  Fix For: 1.2
>  Attachments: applications.patch, applications.patch.zip, configs.log, 
> configs.log, configs.patch, configs.patch, deploy-tool.patch, 
> deploy-tool.patch, deployment-plugin.patch, deployment-plugin.patch, 
> geronimo-deployment-plugin-RTC-VOTE.2.patch, 
> geronimo-deployment-plugin-RTC-VOTE.patch, geronimo.patch, geronimo.patch, 
> geronimo.patch, m2-plugins.patch, modules.patch, modules.patch, mvn.log, 
> openejb.log, openejb.patch, openejb.patch, openejb.patch, openejb.patch, 
> openejb.patch, openejb.patch, pom.xml, pom.xml
>
> A lot of work for moving Geronimo build to M2 was done under G-851. 
> (http://issues.apache.org/jira/browse/GERONIMO-851) 
> The old trunk was renamed as dead-1.2. The new trunk was created from 1.1 and 
> hence the migration work needs to be done here again. This JIRA will seek to 
> consolidate the work that was done under G-851 and all it's subtasks. 
> The patch(es) here will be submitted under the RTC guidelines. Future patches 
> for migration will have to be applied on top of this one. This patch will 
> contain the parent pom, modules, openejb, configs, m2-plugins
> Any issues/concerns about migrating some pieces are well documented in G-851 
> with links to dev list archives.

-- 
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: cwiki.apache.org [longish]

2006-06-07 Thread Erin Mulder

Hernan Cunico wrote:
> Hi All,
> I have enabled public signup so now you can register and contribute
> directly to the documentation.

Thanks for setting this up!  I just signed up, but once I was logged in,
I could no longer see most of the Geronimo spaces.  Is it possible that
permissions have been set for Anonymous, but not for confluence-users
(or whatever the equivalent role is in this installation)?

When I'm logged out, I see:

Apache Geronimo Documentation  (geronimo)   
Apache Geronimo Project Management (GMOxPMGT)   
Apache Geronimo SandBox (GMOxSBOX)  
Apache Geronimo v1.0 (GMOxDOC10)
Apache Geronimo v1.1 (GMOxDOC11)

When I'm logged in, I see:

Apache Geronimo v1.0  (GMOxDOC10)   
Cayenne Documentation (cayenne) 
Demonstration Space (ds)
Test Space (test)

Cheers,
Erin

Re: Directory module broken in 1.1

2006-06-07 Thread David Jencks



On Jun 7, 2006, at 2:30 PM, Dain Sundstrom wrote:


On Jun 7, 2006, at 2:25 PM, Aaron Mulder wrote:

I just tried installing and starting the Directory module and I  
get this:


17:18:15,580 ERROR [GBeanInstanceState] Error while starting;  
GBean is

now in the FAILED state:
abstractName="geronimo/directory/1.1-SNAPSHOT/car? 
configurationName=geronimo/directory/1.1-SNAPSHOT/car"

org.apache.geronimo.kernel.config.InvalidConfigException: New GBeans
must be specified with a GBeanInfo and a full AbstractName
configuration=geronimo/directory/1.1-SNAPSHOT/car
gbeanName=geronimo.server:name=DirectoryService
   at  
org.apache.geronimo.system.configuration.LocalAttributeManager.applyO 
verrides(LocalAttributeManager.java:140)
   at  
org.apache.geronimo.system.configuration.LocalAttributeManager$ 
$FastClassByCGLIB$$b20ef545.invoke()


It seems to be caused by this entry in
assemblies/j2ee-jetty-server/src/var/config/config.xml:

   load="false">

   
   ${PlanServerHostname}
   ${PlanLdapPort}
   
   

I think we should remove this from the config.xml in 1.1 and put it
into the directory plugin instead (sans load=false).


I agree.  We shouldn't include stuff in the config.xml for stuff we  
don't ship with the server.


Agree.



Still, the main
question is, what is the correct GBean name of the DirectoryService?
It looks like it should just be name="DirectoryService" to me.


I think it should be just DirectoryService also.

correct
Are there other entries in the config.xml in the object name  
format?  IIRC everything should be in the simple name style.


My checking is obviously not very good, I missed this one.  More eyes  
needed.


thanks
david jencks



-dain

Re: Directory module broken in 1.1


On Jun 7, 2006, at 2:25 PM, Aaron Mulder wrote:

I just tried installing and starting the Directory module and I get  
this:


17:18:15,580 ERROR [GBeanInstanceState] Error while starting; GBean is
now in the FAILED state:
abstractName="geronimo/directory/1.1-SNAPSHOT/car? 
configurationName=geronimo/directory/1.1-SNAPSHOT/car"

org.apache.geronimo.kernel.config.InvalidConfigException: New GBeans
must be specified with a GBeanInfo and a full AbstractName
configuration=geronimo/directory/1.1-SNAPSHOT/car
gbeanName=geronimo.server:name=DirectoryService
   at  
org.apache.geronimo.system.configuration.LocalAttributeManager.applyOv 
errides(LocalAttributeManager.java:140)
   at  
org.apache.geronimo.system.configuration.LocalAttributeManager$ 
$FastClassByCGLIB$$b20ef545.invoke()


It seems to be caused by this entry in
assemblies/j2ee-jetty-server/src/var/config/config.xml:

   load="false">

   
   ${PlanServerHostname}
   ${PlanLdapPort}
   
   

I think we should remove this from the config.xml in 1.1 and put it
into the directory plugin instead (sans load=false).


I agree.  We shouldn't include stuff in the config.xml for stuff we  
don't ship with the server.



Still, the main
question is, what is the correct GBean name of the DirectoryService?
It looks like it should just be name="DirectoryService" to me.


I think it should be just DirectoryService also.  Are there other  
entries in the config.xml in the object name format?  IIRC everything  
should be in the simple name style.


-dain

cwiki.apache.org [longish]

2006-06-07 Thread Hernan Cunico


Hi All,
I have enabled public signup so now you can register and contribute directly to 
the documentation.

The list of spaces for Geronimo are listed in geronimo.apache.org/documentation/
There you will find a breakdown into 4 initial sections. The first two focuses on Geronimo 
"software" documentation, the third focuses on the project development process and status (not a 
development guide). The last section should hold "everything else", this section will be a good 
place to put the historical and/or still valid data from the old wiki that does not fit in any of 
the other spaces.


1. Apache Geronimo v1.0
   Apache Geronimo v1.0 - User's Guide
   Apache Geronimo v1.0 - Developer's Guide

2. Apache Geronimo v1.1
   Apache Geronimo v1.1 - User's Guide

3. Apache Geronimo Project Management
   Apache Geronimo Development Process
   Apache Geronimo Development Status

4. Apache Geronimo SandBox

Not sure if this organization calls for a vote but is pretty close to what we have been discussing 
from the beginning for organizing the documentation.


As I already mentioned, the pointers to these documentation spaces are available from 
geronimo.apache.org/documentation/ and hopefully soon at geronimo.apache.org/documentation.html.


Given that we have all the documentation organized in different spaces now I created a new one to 
consolidate all the pointers to the other spaces, cwiki.apache.org/geronimo


Comments welcome!


Cheers!
Hernan

Re: Request to release ActriveMQ 3.2.4

2006-06-07 Thread Christoph Sturm


sorry :)

its https://svn.codehaus.org/activemq/trunk/activemq/

regards
chris

On 6/7/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:

On 6/7/06, Christoph Sturm <[EMAIL PROTECTED]> wrote:
> try http://svn.activemq.codehaus.org/

Nope.  First, I assume that committers don't use HTTP.  Second, that's
Fisheye, and if you point SVN to it, you get

svn: PROPFIND request failed on '/'
svn: PROPFIND of '/': 501
Method+PROPFIND+is+not+defined+in+RFC+2068+and+is+not+supported+by+the+Servlet+API+
(http://svn.activemq.codehaus.org)

Thanks,
Aaron

> On 6/6/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
> > What's the best way to get the ActiveMQ 3.2.4 code?
> >
> > I tried to update
> > 
svn+ssh://svn.activemq.codehaus.org/svnroot/activemq/branches/activemq-3/activemq
> > and it didn't take my password (even the one that beaver.codehaus.org
> > says is my new SVN password).
> >
> > Then I tried to check out
> > svn+ssh://svn.activemq.org/scm/activemq/branches/activemq-3/activemq
> > and it doesn't prompt for a password and doesn't let me on with my
> > public key.
> >
> > Thanks,
> > Aaron
> >
> > On 6/6/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> > > I resolved 1, and commented on the other issue.
> > >
> > > On 6/6/06, Paul McMahan <[EMAIL PROTECTED]> wrote:
> > > > Just wanted to send a reminder that there are a couple of patches
> > > > waiting to be applied to AMQ 3.2.4 that address problems with creating
> > > > connectors from the console.
> > > >
> > > > https://issues.apache.org/activemq/browse/AMQ-727
> > > > http://issues.apache.org/jira/browse/GERONIMO-1451
> > > >
> > > > Actually, it's possible they have been applied without closing the
> > > > JIRAs but I wasn't able to connect to svn.activemq.org to check.
> > > >
> > > >
> > > > Best wishes,
> > > > Paul
> > > >
> > > >
> > > > On 6/5/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
> > > > > Hiram / James,
> > > > >
> > > > > Currently we are running off 3.2.4-SNAPSHOT.  Can you release an 
official version?  I'd like to get
> > > > > the official G RC out tomorrow.
> > > > >
> > > > > thanks
> > > > >
> > > > > Matt
> > > > >
> > > > > Hiram Chirino wrote:
> > > > > > Howdy Folks,
> > > > > >
> > > > > > I was planing to work on a patch that takes that gbean related 
modules
> > > > > > in ActiveMQ puts them in
> > > > > > geronimo.  I just wanted to make sure that there are no objections 
to
> > > > > > this.  Those gbean modules are mostly just gbean related glue code
> > > > > > which I think make more sense living in Geronimo.  No one else 
outside
> > > > > > of the geronimo project is interested in the activemq gbean modules.
> > > > > >
> > > > > > Once that part is done, then I'll start to work on merging/modifying
> > > > > > the port to activemq 4.x that was done the 1.2-dead branch.
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Regards,
> > > Hiram
> > >
> >
>
>
> --
> [EMAIL PROTECTED]
>




--
[EMAIL PROTECTED]

Directory module broken in 1.1


I just tried installing and starting the Directory module and I get this:

17:18:15,580 ERROR [GBeanInstanceState] Error while starting; GBean is
now in the FAILED state:
abstractName="geronimo/directory/1.1-SNAPSHOT/car?configurationName=geronimo/directory/1.1-SNAPSHOT/car"
org.apache.geronimo.kernel.config.InvalidConfigException: New GBeans
must be specified with a GBeanInfo and a full AbstractName
configuration=geronimo/directory/1.1-SNAPSHOT/car
gbeanName=geronimo.server:name=DirectoryService
   at 
org.apache.geronimo.system.configuration.LocalAttributeManager.applyOverrides(LocalAttributeManager.java:140)
   at 
org.apache.geronimo.system.configuration.LocalAttributeManager$$FastClassByCGLIB$$b20ef545.invoke()

It seems to be caused by this entry in
assemblies/j2ee-jetty-server/src/var/config/config.xml:

   
   
   ${PlanServerHostname}
   ${PlanLdapPort}
   
   

I think we should remove this from the config.xml in 1.1 and put it
into the directory plugin instead (sans load=false).  Still, the main
question is, what is the correct GBean name of the DirectoryService?
It looks like it should just be name="DirectoryService" to me.  Any
comments?

Thanks,
   Aaron

Re: Maven Repo Woes - Temporary resolution in place


On 6/7/06, Joshua Slive <[EMAIL PROTECTED]> wrote:


Perhaps you are misunderstanding my intentions.  I am not trying to
blame anybody for the current situation and ask them to do penance.
I'm trying to get them to change what they do for future releases.
What exists now and in the past and who created it has nothing to do
with that.  The fact that a maven repository exists in a particular
location does not mean it must be used.


Are you on [EMAIL PROTECTED] Stefano's driving some conversation
there to get this better defined and organized rather than ad hoc.

Hen

Re: Re-migration to m2 - status and discussion.

2006-06-07 Thread Prasad Kashyap

Attention Maven Committers !

I really wish we had a maven committer too involved with the m2
migration effort. There are atleast 3 maven JIRAs that we desperately
need. Hopefully, then you could empathize with our pain and help us
get those JIRAs resolved :-)

Here are some of them to begin with -

http://jira.codehaus.org/browse/MASSEMBLY-45 is needed to "flatten"
dir structures during assembly.
http://jira.codehaus.org/browse/MASSEMBLY-41 can help us extract
*-builder-* artifacts for our schemas.
http://jira.codehaus.org/browse/MWAR-45 is needed to jar up classes
into web-inf/lib/classes.jar

Cheers
Prasad.

On 6/6/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote:

 I have already linked GERONIMO-2066, GERONIMO-2067, and
GERONIMO-2082 to GERONIMO-2071. I am going to link GERONIMO-1740 also.
Yes, for any new work we can create subtasks.

Thnaks
Anita

--- Jacek Laskowski <[EMAIL PROTECTED]> wrote:

> On 6/6/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote:
> > Now that we have something like a baseline of M2 in the trunk, can
> we
> > please go back to creating subtasks under Geronimo-2071 for any
> > current work that we are doing. This will help us prevent
> duplication.
>
> Thanks Prasad! I thought it was me who could not follow what was
> being
> done and meant to propose exactly what you did.
>
> > Prasad
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.laskowski.net.pl
>

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

Re: Maven Repo Woes - Temporary resolution in place

On 6/7/06, Joshua Slive <[EMAIL PROTECTED]> wrote:

On 6/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote:
> On 6/7/06, Joshua Slive <[EMAIL PROTECTED]> wrote:
>
> > And in any case, I believe that much of the problem
> > is not with maven per se, but with how it is being used.
>
> How exactly?
>
> Cocoon/Geronimo have both hit the same problem.  The factor would seem
> to be having a lot of components in your build - which I can't see as
> being a mis-use.

The part about pointing to people.apache.org as a maven repository is
not a design flaw in maven.  The part about maven gobbling up way more
resources than necessary probably is.

Geronimo/Cocoon and other projects did not set up the maven snapshot
repository at the ASF, they're using what has been in place for a long
time.

Hen

automated performance & system testing

2006-06-07 Thread James Strachan

For the longest time I've wanted a good distributed
performance/integration/system testing mechanism. Back in the day I
helped found this project...
http://sysunit.codehaus.org/

which was a neat idea at the time - though the distribution &
coordination & management & reporting was a bit tricky.

If you don't know gbuild is a kinda distributed continuum - it uses
ActiveMQ to distribute builds across a cluster of machines. It all
started due to issues with Geronimo's TCK taking days to run; so
gbuild splits the build up into small chunks and load balances them
across a cluster.
http://ci.gbuild.org/continuum/

After tinkering with the gbuild stuff a light went on - we could use a
cluster of Contiuum servers as our distributed testing framework -
then just use maven builds as the agents (which take care of
dependencies, classpaths and deploying results to a repo).

The source for gbuild is here...
https://svn.apache.org/repos/asf/geronimo/gbuild/

Also have BeanFlow for writing little orchestrations in Java code too...
http://incubator.apache.org/servicemix/beanflow.html

So we're getting closer to having the pieces in place.

A little while ago I hacked up some ideas on how we could build this
in a wiki page..
http://goopen.org/confluence/display/ACTIVEMQ/Example+Testing+Scenario

There's an early of an m2 plugin which lets you run brokers,
performance producer/consumer tests
https://svn.apache.org/repos/asf/incubator/activemq/trunk/tooling/maven-activemq-perf-plugin/

which now has some documentation too
http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+Performance+Module+Users+Manual

I'm sure there's gonna be some rough edges along the way to get a
great distributed performance testing suite - e.g. we may have to
tweak the gbuild stuff to be able to handle dependent sets of builds a
little better; so that say 10 different builds which have to run
concurrently on different machines can be scheduled properly etc. But
its getting closer.

So right now its easy to run performance tests of
producer/consumer/broker type models specifying the connection URL and
arguments to use in the test.

e.g. try following the user manual and see if you can run some basic
performance tests on your hardware.

http://activemq.org/site/activemq-performance-module-users-manual.html

then we can hopefully start adding tools such as to graph the
performance results over time; or compare performance results on
different hardware, or compare the effects of different optimisation
flags etc.

So far the plugin just deals with performance testing; I'm sure we
could extend the concept to automated integration/system testing too.
--

James
---
http://radio.weblogs.com/0112098/

Re: Maven Repo Woes - Temporary resolution in place

On 6/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote:

On 6/7/06, Joshua Slive <[EMAIL PROTECTED]> wrote:

> And in any case, I believe that much of the problem
> is not with maven per se, but with how it is being used.

How exactly?

Cocoon/Geronimo have both hit the same problem.  The factor would seem
to be having a lot of components in your build - which I can't see as
being a mis-use.

The part about pointing to people.apache.org as a maven repository is
not a design flaw in maven.  The part about maven gobbling up way more
resources than necessary probably is.

Joshua.

Re: Maven Repo Woes - Temporary resolution in place


On 6/7/06, Henri Yandell <[EMAIL PROTECTED]> wrote:


With respect sir, please direct the Maven ire to the Maven developers
and not the Maven users. We're blaming the messenger by complaining at
Matt for having helped figure out the problem.


I don't really buy that.  Just because they have chosen an ASF project
for their builds does not get them off from responsbility if it
performs poorly.  And in any case, I believe that much of the problem
is not with maven per se, but with how it is being used.

Joshua.

[jira] Commented: (GERONIMO-2071) Move Geronimo build to M2 (new 1.2 trunk)

2006-06-07 Thread David Jencks (JIRA)

[ 
http://issues.apache.org/jira/browse/GERONIMO-2071?page=comments#action_12415194
 ] 

David Jencks commented on GERONIMO-2071:


We have a conflict with the m1 build and geronimo-dependency.xml files.  Since 
the geronimo groupId is different in m2 than m1, we need different contents.  
There is currently no way to generate the content in m2, and this is likely to 
stay the same for the forseeable future.  If you add the m2 version to the 
appropriate m2 location src/resources/META-INF/geronimo-dependency.xml, the m1 
build uses it instead of the generated m1 version.

I guess we need to change the m1 build to exclude this specific file?

I added the fixed g-d.xml files in rev r412485, discovered this problem, and 
rolled back in rev 412487.

> Move Geronimo build to M2 (new 1.2 trunk)
> -
>
>  Key: GERONIMO-2071
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2071
>  Project: Geronimo
> Type: New Feature
> Security: public(Regular issues) 
>   Components: buildsystem
> Versions: 1.2
> Reporter: Prasad Kashyap
> Assignee: Jacek Laskowski
>  Fix For: 1.2
>  Attachments: applications.patch, applications.patch.zip, configs.log, 
> configs.log, configs.patch, configs.patch, deploy-tool.patch, 
> deploy-tool.patch, deployment-plugin.patch, deployment-plugin.patch, 
> geronimo-deployment-plugin-RTC-VOTE.2.patch, 
> geronimo-deployment-plugin-RTC-VOTE.patch, geronimo.patch, geronimo.patch, 
> geronimo.patch, m2-plugins.patch, modules.patch, modules.patch, mvn.log, 
> openejb.log, openejb.patch, openejb.patch, openejb.patch, openejb.patch, 
> openejb.patch, openejb.patch, pom.xml, pom.xml
>
> A lot of work for moving Geronimo build to M2 was done under G-851. 
> (http://issues.apache.org/jira/browse/GERONIMO-851) 
> The old trunk was renamed as dead-1.2. The new trunk was created from 1.1 and 
> hence the migration work needs to be done here again. This JIRA will seek to 
> consolidate the work that was done under G-851 and all it's subtasks. 
> The patch(es) here will be submitted under the RTC guidelines. Future patches 
> for migration will have to be applied on top of this one. This patch will 
> contain the parent pom, modules, openejb, configs, m2-plugins
> Any issues/concerns about migrating some pieces are well documented in G-851 
> with links to dev list archives.

-- 
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: permission

2006-06-07 Thread Mittler, Nathan

Excellent - all set.  Thanks!

-Original Message-
From: James Strachan [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, June 07, 2006 2:45 PM
To: activemq-dev@geronimo.apache.org
Subject: Re: permission

On 6/7/06, Mittler, Nathan <[EMAIL PROTECTED]> wrote:
> I don't seem to have the permission to assign issues to myself.  Is
> there some process for getting issues assigned, or should I just be
able
> to assign myself any issues I want?

Sorry about that.  Its described in the fine print near the bottom of
this page - so you did exactly the right thing :)

http://incubator.apache.org/activemq/contributing.html

basically one of the committers need to grant you karma in JIRA. Have
done it now, you should be all set (sometimes you need to log out & in
again to refresh your karma)

-- 

James
---
http://radio.weblogs.com/0112098/

[jira] Assigned: (AMQ-739) STOMP transport handles JMS type improperly

2006-06-07 Thread Nathan Mittler (JIRA)

 [ https://issues.apache.org/activemq/browse/AMQ-739?page=all ]

Nathan Mittler reassigned AMQ-739:
--

Assign To: Nathan Mittler

> STOMP transport handles JMS type improperly
> ---
>
>  Key: AMQ-739
>  URL: https://issues.apache.org/activemq/browse/AMQ-739
>  Project: ActiveMQ
> Type: Bug

>   Components: Transport
>  Environment: sending from STOMP to JMS
> Reporter: Nathan Mittler
> Assignee: Nathan Mittler
> Priority: Minor

>
> Original Estimate: 1 week
> Remaining: 1 week
>
> Sending a text message from a stomp client with a content-length results in a 
> bytes message on JMS.  Suggest doing the following ...
> 1) The stomp transport should always add the content-length header to 
> out-going messages, regardless of content-type or whether or not a 
> content-length was provided on the incoming message.
> 2) The stomp transport should handle in-coming messages with a content-type 
> header, and should pass that through.
> 3) If a message comes in without a content-length or a content-type, it 
> should just be assumed a TextMessage.  This way we can use the terminating 
> null character as the delimiter.

-- 
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: Maven Repo Woes - Temporary resolution in place


On 6/7/06, Joshua Slive <[EMAIL PROTECTED]> wrote:


And in any case, I believe that much of the problem
is not with maven per se, but with how it is being used.


How exactly?

Cocoon/Geronimo have both hit the same problem.  The factor would seem
to be having a lot of components in your build - which I can't see as
being a mis-use.

Hen

Re: permission

2006-06-07 Thread James Strachan


On 6/7/06, Mittler, Nathan <[EMAIL PROTECTED]> wrote:

I don't seem to have the permission to assign issues to myself.  Is
there some process for getting issues assigned, or should I just be able
to assign myself any issues I want?


Sorry about that.  Its described in the fine print near the bottom of
this page - so you did exactly the right thing :)

http://incubator.apache.org/activemq/contributing.html

basically one of the committers need to grant you karma in JIRA. Have
done it now, you should be all set (sometimes you need to log out & in
again to refresh your karma)

--

James
---
http://radio.weblogs.com/0112098/

[jira] Commented: (AMQ-732) Infinite recovery loop.

2006-06-07 Thread Maxim Fateev (JIRA)

[ 
https://issues.apache.org/activemq/browse/AMQ-732?page=comments#action_36252 ] 

Maxim Fateev commented on AMQ-732:
--

One possible clue is that I'm running broker from eclipse. And eclipse kills 
processes without running their shutdown handlers. So it might be that to 
reproduce you'll need to kill broker with kill -9.

> Infinite recovery loop.
> ---
>
>  Key: AMQ-732
>  URL: https://issues.apache.org/activemq/browse/AMQ-732
>  Project: ActiveMQ
> Type: Bug

>   Components: Broker
> Versions: 4.0
>  Environment: Linux RHEL 3
> Reporter: Maxim Fateev
> Assignee: Hiram Chirino

>
>
> The simplest way to reproduce the problem:
> 1. Remove storage directory. 
> 2. Start broker using the following code:
>  public static void main(String[] args)  throws Exception {
>BrokerService broker = new BrokerService();
>broker.setPersistent(true);
>DefaultPersistenceAdapterFactory pFactory = new 
> DefaultPersistenceAdapterFactory();
>pFactory.setJournalLogFiles(1);
>pFactory.setJournalLogFileSize(2048);
>broker.setPersistenceFactory(pFactory);
>broker.setUseJmx(false);
>broker.addConnector("tcp://localhost:61616");
>broker.start();
>Thread.sleep(1l);
>}
> 3. Shutdown the broker.
> 4. Start broker.
> It enters infinite loop
> [  main] BrokerService  INFO  
> ActiveMQ null JMS Message Broker (localhost) is starting
> [  main] BrokerService  INFO  For 
> help or more information please see: http://incubator.apache.org/activemq/
> [  main] JDBCPersistenceAdapter INFO  
> Database driver recognized: [apache_derby_embedded_jdbc_driver]
> [  main] DefaultJDBCAdapter DEBUG 
> Executing SQL: CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER 
> VARCHAR(250), MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, 
> MSG BLOB, PRIMARY KEY ( ID ) )
> [  main] DefaultJDBCAdapter DEBUG Could 
> not create JDBC tables; The message table already existed. Failure was: 
> CREATE TABLE ACTIVEMQ_MSGS(ID INTEGER NOT NULL, CONTAINER VARCHAR(250), 
> MSGID_PROD VARCHAR(250), MSGID_SEQ INTEGER, EXPIRATION BIGINT, MSG BLOB, 
> PRIMARY KEY ( ID ) ) Message: Table/View 'ACTIVEMQ_MSGS' already exists in 
> Schema 'APP'. SQLState: X0Y32 Vendor code: 2
> [  main] DefaultJDBCAdapter DEBUG 
> Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_MIDX ON ACTIVEMQ_MSGS 
> (MSGID_PROD,MSGID_SEQ)
> [  main] DefaultJDBCAdapter DEBUG 
> Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_CIDX ON ACTIVEMQ_MSGS (CONTAINER)
> [  main] DefaultJDBCAdapter DEBUG 
> Executing SQL: CREATE INDEX ACTIVEMQ_MSGS_EIDX ON ACTIVEMQ_MSGS (EXPIRATION)
> [  main] DefaultJDBCAdapter DEBUG 
> Executing SQL: CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, 
> CLIENT_ID VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR 
> VARCHAR(250), LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, 
> SUB_NAME))
> [  main] DefaultJDBCAdapter DEBUG Could 
> not create JDBC tables; The message table already existed. Failure was: 
> CREATE TABLE ACTIVEMQ_ACKS(CONTAINER VARCHAR(250) NOT NULL, CLIENT_ID 
> VARCHAR(250) NOT NULL, SUB_NAME VARCHAR(250) NOT NULL, SELECTOR VARCHAR(250), 
> LAST_ACKED_ID INTEGER, PRIMARY KEY ( CONTAINER, CLIENT_ID, SUB_NAME)) 
> Message: Table/View 'ACTIVEMQ_ACKS' already exists in Schema 'APP'. SQLState: 
> X0Y32 Vendor code: 2
> [  main] JDBCPersistenceAdapter DEBUG 
> Cleaning up old messages.
> [  main] DefaultJDBCAdapter DEBUG 
> Executing SQL: DELETE FROM ACTIVEMQ_MSGS WHERE ( EXPIRATION<>0 AND 
> EXPIRATION ACTIVEMQ_ACKS WHERE ACTIVEMQ_ACKS.CONTAINER=ACTIVEMQ_MSGS.CONTAINER)
> [  main] DefaultJDBCAdapter DEBUG Deleted 
> 0 old message(s).
> [  main] JDBCPersistenceAdapter DEBUG Cleanup 
> done.
> [  main] JournalPersistenceAdapter  INFO  Journal 
> Recovery Started from: Active Journal: using 1 x 0.001953125 Megs at: 
> /workplace/fateev/install/activemq-4.0-SNAPSHOT/activemq-core/activemq-data/journal
> [  main] JournalPersistenceAdapter  DEBUG TRACE 
> Entry: RECOVERED
> [Journal Writer] LogFileManager DEBUG 
> getNextDataRecordLocation offset=53
> [Journal Writer] LogFileManager DEBUG 
> getNextDataRecordLocation offset=97
> [Journal Writer] LogFileManager

Re: Maven Repo Woes - Temporary resolution in place

On 6/7/06, Joshua Slive <[EMAIL PROTECTED]> wrote:

On 6/6/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
> Joshua Slive wrote:
>
> > So you not only have your build process tied to apache infrastructure
> > in a non-scalable way
>
> Is this the issue with Maven not handling redirects, or something else?

It is the fact that builds of geronimo must download artifacts from
people.apache.org.  We have worked very hard with other projects to
make sure that all downloads point to the mirror system.  Otherwise,
our bandwidth requirements would be many times what they currently
are.  geronimo is circumventing this system.

To sound a bit like a Hollywood movie

---
With respect sir, please direct the Maven ire to the Maven developers
and not the Maven users. We're blaming the messenger by complaining at
Matt for having helped figure out the problem.
---

Then I think I get arrested for court-martial, however the courtroom
scene is then be cut from the movie as the editors realise I'm a
two-bit character without the depth to bond with the viewers.

We do need to sort out our repository management though. I'm not sure
it's something that we should unleash on the ASF mirrors - the Maven
repository is not something you delete old versions from and it'd be a
big increase in their diskspace. Hopefully you should see more
discussion on repository about it, Stefano's encouraging the list to
think about getting all of this under some control.

Hen

Re: 1.1 Candidate releases available

2006-06-07 Thread Hernan Cunico


I'll catch up with the release notes :)

Cheers!
Hernan

Matt Hogstrom wrote:

Geronimo Users and Developers,

We've been busy little beavers this evening and would like to share the 
fruits of our labor.


First, may we present the candidate build of Geronimo in Octographic 
quality.  We have big builds, little builds, some for Windows and others 
for Unix and of course the ever enjoyable Tomcat and Jetty versions.  
Please take some time to take these builds and verify that they meet 
your exacting standards for a Geronimo Release.  As we like to say, "Big 
G, Little G and things that rhyme with G."


*Jetty*
http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.tar.gz 

http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.zip 

http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.tar.gz 

http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.zip 



*Tomcat*
http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.tar.gz 

http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.zip 

http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.tar.gz 

http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.zip 




Remaining items.

1. We need the ActiveMQ 3.2.4 to be released.
2. Finalize release notes (Hernan...can you pick this one up?  A set for 
today would be good)

3. Move the remainging JIRAs out of 1.1.  (Aaron, Dain, anyone ?)
4. Fix OpenEJB Source.  I versioned and released it but I haven't fixed 
the SVN repo yet.  I'll do this in the morning unless someone beats me 
to it.
5. A vote.  I'm note sure if this can qualify for a vote since there is 
a SNAPSHOT in the release. It won't change but need to note that.  
Thoughts?


To complete an official release I need to finalize the project version 
and rebuild once again.


Its late and I'm probably missing something so if there are barriers to 
completing the final release please let me know ASAP.


I expect we'll start a 1.1.1 straightaway but let's get this 1.1 out and 
going.


Thanks in advance for taking time to review this release of AG 1.1.

The Geronimo Development Team

Re: 1.1 Candidate releases available


On 6/7/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:

Aaron,

Joe put out a thread about the interpretation of versions which I think is 
exactly this problem.  If
we have a well understood algorithm for Versions that includes several aspects 
of the final qualifer
(if present) this would solve the issue.  So releases is just one of many 
possible uses.   Others
include patched versions, SNAPSHOTS, etc.

Does this sound right to you?


Well, only a little.  I would rather agree to use well-defined
releases beta1-netaN followed by rc1-rcN followed by a final release.
I don't want to say a plugin will support arbitrary releases
designated by whatever token someone feels like using so long as it's
valid according to our version calculation rules -- that seems likely
to be problematic.  But in the plugin context, I'm only talking about
the "Geronimo version", not the version of individual components like
geronimo/jetty/1.1.3-patch5/car.  I agree that Joe's discussion needs
to happen in relation to dependencies and versions of specific
components *within* Geronimo.

I guess I better propose my release versioning issue in a separate
thread for 1.1.N/1.2.

Thanks,
   Aaron



Aaron Mulder wrote:
> OK, so we have a small issue with the plugins.
>
> They currently list the supported versions of Geronimo in their
> metadata.  The idea is that we don't state that a plugin will run in
> *any* version of Geronimo, we instead add each supported version as it
> is released.  Currently that list only contains 1.1-SNAPSHOT.
>
> Now I can go add 1.1-20060607 to the list of supported versions for
> the 1.1 plugins, but we'll never be able to do that in advance.  It
> would be nicer if the release candidates had more predictable names
> (rc1, rc2, rc3, etc.) so we could add them to the supported version
> list ahead of time.
>
> We also have to decide how to handle SNAPSHOT versions of Geronimo.  I
> don't really think we want the released 1.1 plugins to claim that they
> support 1.2-SNAPSHOT, which may or may not be true depending on the
> extent of the changes.  I'm currently planning to have a different
> plugin repository for each major version of Geronimo, so the 1.1
> plugin repository will be fairly stable and the 1.2 plugin repository
> may need to be rebuilt a lot and won't likely have a very complete set
> of plugins until the release.
>
> Thanks,
>Aaron
>
> On 6/7/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
>> Geronimo Users and Developers,
>>
>> We've been busy little beavers this evening and would like to share
>> the fruits of our labor.
>>
>> First, may we present the candidate build of Geronimo in Octographic
>> quality.  We have big builds,
>> little builds, some for Windows and others for Unix and of course the
>> ever enjoyable Tomcat and
>> Jetty versions.  Please take some time to take these builds and verify
>> that they meet your exacting
>> standards for a Geronimo Release.  As we like to say, "Big G, Little G
>> and things that rhyme with G."
>>
>> *Jetty*
>> 
http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.tar.gz
>>
>> 
http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.zip
>>
>> 
http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.tar.gz
>>
>> 
http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.zip
>>
>>
>> *Tomcat*
>> 
http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.tar.gz
>>
>> 
http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.zip
>>
>> 
http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.tar.gz
>>
>> 
http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.zip
>>
>>
>>
>> Remaining items.
>>
>> 1. We need the ActiveMQ 3.2.4 to be released.
>> 2. Finalize release notes (Hernan...can you pick this one up?  A set
>> for today would be good)
>> 3. Move the remainging JIRAs out of 1.1.  (Aaron, Dain, anyone ?)
>> 4. Fix OpenEJB Source.  I versioned and released it but I haven't
>> fixed the SVN repo yet.  I'll do
>> this in the morning unless someone beats me to it.
>> 5. A vote.  I'm note sure if this can qualify for a vote since there
>> is a SNAPSHOT in the release.
>> It won't change but need to note that.  Thoughts?
>>
>> To complete an official release I need to finalize the project version
>> and rebuild once again.
>>
>> Its late and I'm probably missing something so if there are barriers
>> to completing the final release
>> please let me know ASAP.
>>
>> I expect we'll start a 1.1.1 straightaway but let's get this 1.1 out
>> and going.
>>
>> Thanks in advance for taking time to review this release of AG 1.1.
>>
>> The Geronimo Development Team
>>
>
>
>

Re: [RTC] XBEAN-13 and XBEAN-14


On Jun 6, 2006, at 8:48 AM, Dain Sundstrom wrote:


On Jun 6, 2006, at 5:43 AM, Guillaume Nodet wrote:

http://issues.apache.org/jira/browse/XBEAN-14 is a major  
enhancement of xbean-spring to support Spring 2.0-m5.
I have created a branch instead of a patch, because of the need to  
split the existing xbean-spring module into two parts.
The branch is available at http://svn.apache.org/viewvc/geronimo/ 
xbean/branches/spring2/trunk/ and the revisions links

are availanble in the JIRA.
In addition I added integration tests to ensure that xbean-spring  
is fully compatible with all spring versions >= 1.2.4,
which was not the case, despite a modification I made for the  
latest xbean release.


Here's my +1 for applying the XBEAN-13 patch and merging the  
branch to trunk for XBEAN-14.


Wow!  Great work.  I'll try out the new branch and get back to you  
in a few hours.


Sorry, that took longer then I thought.

I've read over the changes and tested the branch.  It all looks  
great.  Here is my +1.


-dain

Re: 1.1 Candidate releases available

Aaron,

Joe put out a thread about the interpretation of versions which I think is exactly this problem. If
we have a well understood algorithm for Versions that includes several aspects of the final qualifer
(if present) this would solve the issue. So releases is just one of many possible uses. Others
include patched versions, SNAPSHOTS, etc.

Does this sound right to you?

Aaron Mulder wrote:

OK, so we have a small issue with the plugins.

They currently list the supported versions of Geronimo in their
metadata. The idea is that we don't state that a plugin will run in
*any* version of Geronimo, we instead add each supported version as it
is released. Currently that list only contains 1.1-SNAPSHOT.

Now I can go add 1.1-20060607 to the list of supported versions for
the 1.1 plugins, but we'll never be able to do that in advance. It
would be nicer if the release candidates had more predictable names
(rc1, rc2, rc3, etc.) so we could add them to the supported version
list ahead of time.

We also have to decide how to handle SNAPSHOT versions of Geronimo. I
don't really think we want the released 1.1 plugins to claim that they
support 1.2-SNAPSHOT, which may or may not be true depending on the
extent of the changes. I'm currently planning to have a different
plugin repository for each major version of Geronimo, so the 1.1
plugin repository will be fairly stable and the 1.2 plugin repository
may need to be rebuilt a lot and won't likely have a very complete set
of plugins until the release.

Thanks,
Aaron

On 6/7/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:

Geronimo Users and Developers,

We've been busy little beavers this evening and would like to share
the fruits of our labor.

First, may we present the candidate build of Geronimo in Octographic
quality. We have big builds,
little builds, some for Windows and others for Unix and of course the
ever enjoyable Tomcat and
Jetty versions. Please take some time to take these builds and verify
that they meet your exacting
standards for a Geronimo Release. As we like to say, "Big G, Little G
and things that rhyme with G."

*Jetty*
http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.tar.gz

http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.zip

http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.tar.gz

http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.zip

*Tomcat*
http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.tar.gz

http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.zip

http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.tar.gz

http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.zip

Remaining items.

1. We need the ActiveMQ 3.2.4 to be released.
2. Finalize release notes (Hernan...can you pick this one up? A set
for today would be good)

3. Move the remainging JIRAs out of 1.1. (Aaron, Dain, anyone ?)
4. Fix OpenEJB Source. I versioned and released it but I haven't
fixed the SVN repo yet. I'll do

this in the morning unless someone beats me to it.
5. A vote. I'm note sure if this can qualify for a vote since there
is a SNAPSHOT in the release.

It won't change but need to note that. Thoughts?

To complete an official release I need to finalize the project version
and rebuild once again.

Its late and I'm probably missing something so if there are barriers
to completing the final release

please let me know ASAP.

I expect we'll start a 1.1.1 straightaway but let's get this 1.1 out
and going.

Thanks in advance for taking time to review this release of AG 1.1.

The Geronimo Development Team

Re: [RTC] m2-plugins deployment plugin

On Jun 7, 2006, at 10:18 AM, Jacek Laskowski wrote:

On 6/7/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:

On Jun 7, 2006, at 5:43 AM, Jacek Laskowski wrote:

> On 6/7/06, David Jencks <[EMAIL PROTECTED]> wrote:
>> > It doesn't count, though ;-)
>>
>> Why not?  Because I edited prasad's patch for formatting and  
removed

>> unused cruft?  Ken's directive requires 3 +1 votes from committers
>> other than the proposer (who apparently does not need to be a
>> committer): although the document he appears to have adapted  
states
>> only PMC member votes count, that is not in his directive.   
Since he

>> hasn't responded to requests for clarification I think we have to
>> take him at his word.
>
> The proposer (!= the author) == DJ nor Prasad => DJ may not vote  
for

> it. Is that correct?

FWIU, everyone can vote, but only the votes of committers count.  To
apply a patch, you need 4 +1 votes, and your own +1 counts as the
first of the four.

That's exactly how I understand it! Note the difference in the numbers
- I hope it's not a mistake - there's 4 +1 votes in your email whereas
Dave mentioned 3 +1 votes. The difference is where I stand - apart
from Dave's own +1 he needs 3 more, doesn't he?

I seem to have cut of the important part of david's email.  Anyway, I  
agree he needs 3 more +1 in addition to his own.

-dain

Re: [RTC] m2-plugins deployment plugin


On 6/7/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote:

On Jun 7, 2006, at 5:43 AM, Jacek Laskowski wrote:

> On 6/7/06, David Jencks <[EMAIL PROTECTED]> wrote:
>> > It doesn't count, though ;-)
>>
>> Why not?  Because I edited prasad's patch for formatting and removed
>> unused cruft?  Ken's directive requires 3 +1 votes from committers
>> other than the proposer (who apparently does not need to be a
>> committer): although the document he appears to have adapted states
>> only PMC member votes count, that is not in his directive.  Since he
>> hasn't responded to requests for clarification I think we have to
>> take him at his word.
>
> The proposer (!= the author) == DJ nor Prasad => DJ may not vote for
> it. Is that correct?

FWIU, everyone can vote, but only the votes of committers count.  To
apply a patch, you need 4 +1 votes, and your own +1 counts as the
first of the four.


That's exactly how I understand it! Note the difference in the numbers
- I hope it's not a mistake - there's 4 +1 votes in your email whereas
Dave mentioned 3 +1 votes. The difference is where I stand - apart
from Dave's own +1 he needs 3 more, doesn't he?


-dain


Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: [RTC] m2-plugins deployment plugin


On Jun 7, 2006, at 5:43 AM, Jacek Laskowski wrote:


On 6/7/06, David Jencks <[EMAIL PROTECTED]> wrote:

> It doesn't count, though ;-)

Why not?  Because I edited prasad's patch for formatting and removed
unused cruft?  Ken's directive requires 3 +1 votes from committers
other than the proposer (who apparently does not need to be a
committer): although the document he appears to have adapted states
only PMC member votes count, that is not in his directive.  Since he
hasn't responded to requests for clarification I think we have to
take him at his word.


The proposer (!= the author) == DJ nor Prasad => DJ may not vote for
it. Is that correct?


FWIU, everyone can vote, but only the votes of committers count.  To  
apply a patch, you need 4 +1 votes, and your own +1 counts as the  
first of the four.


-dain

Re: Maven Repo Woes - Temporary resolution in place

On 6/6/06, Noel J. Bergman <[EMAIL PROTECTED]> wrote:

Joshua Slive wrote:

> So you not only have your build process tied to apache infrastructure
> in a non-scalable way

Is this the issue with Maven not handling redirects, or something else?

It is the fact that builds of geronimo must download artifacts from
people.apache.org.  We have worked very hard with other projects to
make sure that all downloads point to the mirror system.  Otherwise,
our bandwidth requirements would be many times what they currently
are.  geronimo is circumventing this system.

> but you are essentially doing a DoS attack against the
> infrastructure every time you build.  Great.

Is this related to anything other than the scalability issue?

Making >10 connections per client to the server is "very bad
behavior", although I was being a little dramatic calling it a DoS.
If more than a few clients at a time were doing this, it certainly
would have an adverse effect on our service.  This is a different
issue than the use of non-mirrored infrastructure for downloads.

Joshua.

[jira] Resolved: (GERONIMO-2087) MimeUtility.encodeWord()/encodeText() have some errors.

2006-06-07 Thread Rick McGuire (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-2087?page=all ]
 
Rick McGuire resolved GERONIMO-2087:


Resolution: Fixed

Committed revision 412426.

> MimeUtility.encodeWord()/encodeText() have some errors.
> ---
>
>  Key: GERONIMO-2087
>  URL: http://issues.apache.org/jira/browse/GERONIMO-2087
>  Project: Geronimo
> Type: Bug
> Security: public(Regular issues) 
>   Components: mail
> Versions: 1.1
> Reporter: Rick McGuire
> Assignee: Rick McGuire
>  Fix For: 1.1.1

>
> The MimeUtility encodeWord()/encodeText() methods have a couple of errors:
> 1)  "Q" is not properly recognized as an encoding type. 
> 2)  When encoding a base64 string, some non-ASCII characters do not encode 
> properly. 

-- 
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

M2 : welcome-tomcat configuration

2006-06-07 Thread anita kulshreshtha

David J,
   I am building welcome-tomcat configuration. I had to add the
following  dependencies to the existing g-dependency.xml in tomcat
module. How is M1 build working without it?
1. g-transaction
2. g-security
3  g-j2ee-connector...spec

Thanks
Anita


D:\x\geronimo\geronimo-1.2\configs\welcome-tomcat>mvn -o clean
install
[INFO]
NOTE: Maven is executing in offline mode. Any artifacts not already in
your local
repository will be inaccessible.

[INFO] Scanning for projects...
[INFO]

[INFO] Building Welcome app Tomcat
[INFO]task-segment: [clean, install]
[INFO]

[INFO] [clean:clean]
[INFO] Deleting directory
D:\x\geronimo\geronimo-1.2\configs\welcome-tomcat\target
[INFO] Deleting directory
D:\x\geronimo\geronimo-1.2\configs\welcome-tomcat\target\classes
[INFO] Deleting directory
D:\x\geronimo\geronimo-1.2\configs\welcome-tomcat\target\test-classes
[INFO] [car:dependencies]
[WARNING]
Artifact junit:junit:jar:3.8.1:test retains local scope 'test'
overriding broader scope 'com
pile'
given by a dependency. If this is not intended, modify or
remove the local scope.

[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [car:package]
---null
---org.apache.geronimo.configs/geronimo-gbean-deployer/1.2-SNAPSHOT/car?j2eeType=Deployer,na
me=Deployer
---[org.apache.geronimo.configs/geronimo-gbean-deployer/1.2-SNAPSHOT/car,
org.apache.geronim
o.configs/j2ee-deployer/1.2-SNAPSHOT/car,
org.apache.geronimo.configs/tomcat-deployer/1.2-SNAPSHOT/c
ar, org.apache.geronimo.configs/client-deployer/1.2-SNAPSHOT/car,
org.apache.geronimo.configs/openej
b-deployer/1.2-SNAPSHOT/car,
org.apache.geronimo.configs/axis-deployer/1.2-SNAPSHOT/car]
---lib/endorsed
---lib/ext
---null
---null
---null
---null
---C:\Documents and
Settings\User\.m2\repository\org\apache\geronimo\applications\geronimo-w
elcome\1.2-SNAPSHOT\geronimo-welcome-1.2-SNAPSHOT.war
---D:\x\geronimo\geronimo-1.2\configs\welcome-tomcat\target\welcome-tomcat-1.2-SNAPSHOT.
car
---D:\x\geronimo\geronimo-1.2\configs\welcome-tomcat\target\plan\plan.xml
---C:\Documents and Settings\User\.m2\repository
---org.apache.geronimo.system.repository.Maven2Repository
---org.apache.geronimo.plugin.packaging.MavenConfigStore
---D:\x\geronimo\geronimo-1.2\configs\welcome-tomcat\target\repository
---org.apache.geronimo.system.repository.Maven2Repository
---org.apache.geronimo.system.configuration.RepositoryConfigurationStore
---D:\x\geronimo\geronimo-1.2\configs\welcome-tomcat/../../etc/explicit_versions.propert
ies
---WARN

Packaging configuration
D:\x\geronimo\geronimo-1.2\configs\welcome-tomcat\target\plan\plan.x
ml

log4j:WARN No appenders could be found for logger
(org.apache.geronimo.kernel.basic.BasicKernel).
log4j:WARN Please initialize the log4j system properly.
Generated package
D:\x\geronimo\geronimo-1.2\configs\welcome-tomcat\target\welcome-tomcat-1.2-SN
APSHOT.car
[INFO] [install:install]
[INFO] Installing
D:\x\geronimo\geronimo-1.2\configs\welcome-tomcat\target\welcome-tomcat-1.2-SN
APSHOT.car to C:\Documents and
Settings\User\.m2\repository\org\apache\geronimo\configs\welcome-tomc
at\1.2-SNAPSHOT\welcome-tomcat-1.2-SNAPSHOT.car
[INFO]

[INFO] BUILD SUCCESSFUL
[INFO]

[INFO] Total time: 17 seconds
[INFO] Finished at: Wed Jun 07 11:10:36 EDT 2006
[INFO] Final Memory: 14M/26M
[INFO]











__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

[jira] Created: (GERONIMO-2087) MimeUtility.encodeWord()/encodeText() have some errors.

2006-06-07 Thread Rick McGuire (JIRA)

MimeUtility.encodeWord()/encodeText() have some errors.
---

 Key: GERONIMO-2087
 URL: http://issues.apache.org/jira/browse/GERONIMO-2087
 Project: Geronimo
Type: Bug
Security: public (Regular issues) 
  Components: mail  
Versions: 1.1
Reporter: Rick McGuire
 Assigned to: Rick McGuire 
 Fix For: 1.1.1


The MimeUtility encodeWord()/encodeText() methods have a couple of errors:

1)  "Q" is not properly recognized as an encoding type. 
2)  When encoding a base64 string, some non-ASCII characters do not encode 
properly. 

-- 
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: 1.1 Candidate releases available


OK, so we have a small issue with the plugins.

They currently list the supported versions of Geronimo in their
metadata.  The idea is that we don't state that a plugin will run in
*any* version of Geronimo, we instead add each supported version as it
is released.  Currently that list only contains 1.1-SNAPSHOT.

Now I can go add 1.1-20060607 to the list of supported versions for
the 1.1 plugins, but we'll never be able to do that in advance.  It
would be nicer if the release candidates had more predictable names
(rc1, rc2, rc3, etc.) so we could add them to the supported version
list ahead of time.

We also have to decide how to handle SNAPSHOT versions of Geronimo.  I
don't really think we want the released 1.1 plugins to claim that they
support 1.2-SNAPSHOT, which may or may not be true depending on the
extent of the changes.  I'm currently planning to have a different
plugin repository for each major version of Geronimo, so the 1.1
plugin repository will be fairly stable and the 1.2 plugin repository
may need to be rebuilt a lot and won't likely have a very complete set
of plugins until the release.

Thanks,
   Aaron

On 6/7/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:

Geronimo Users and Developers,

We've been busy little beavers this evening and would like to share the fruits 
of our labor.

First, may we present the candidate build of Geronimo in Octographic quality.  
We have big builds,
little builds, some for Windows and others for Unix and of course the ever 
enjoyable Tomcat and
Jetty versions.  Please take some time to take these builds and verify that 
they meet your exacting
standards for a Geronimo Release.  As we like to say, "Big G, Little G and things 
that rhyme with G."

*Jetty*
http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.tar.gz
http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.zip
http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.tar.gz
http://people.apache.org/~hogstrom/20060607/geronimo-jetty-minimal-1.1-20060607.zip

*Tomcat*
http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.tar.gz
http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-j2ee-1.1-20060607.zip
http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.tar.gz
http://people.apache.org/~hogstrom/20060607/geronimo-tomcat-minimal-1.1-20060607.zip


Remaining items.

1. We need the ActiveMQ 3.2.4 to be released.
2. Finalize release notes (Hernan...can you pick this one up?  A set for today 
would be good)
3. Move the remainging JIRAs out of 1.1.  (Aaron, Dain, anyone ?)
4. Fix OpenEJB Source.  I versioned and released it but I haven't fixed the SVN 
repo yet.  I'll do
this in the morning unless someone beats me to it.
5. A vote.  I'm note sure if this can qualify for a vote since there is a 
SNAPSHOT in the release.
It won't change but need to note that.  Thoughts?

To complete an official release I need to finalize the project version and 
rebuild once again.

Its late and I'm probably missing something so if there are barriers to 
completing the final release
please let me know ASAP.

I expect we'll start a 1.1.1 straightaway but let's get this 1.1 out and going.

Thanks in advance for taking time to review this release of AG 1.1.

The Geronimo Development Team

Re: Request to release ActriveMQ 3.2.4


On 6/7/06, Christoph Sturm <[EMAIL PROTECTED]> wrote:

try http://svn.activemq.codehaus.org/


Nope.  First, I assume that committers don't use HTTP.  Second, that's
Fisheye, and if you point SVN to it, you get

svn: PROPFIND request failed on '/'
svn: PROPFIND of '/': 501
Method+PROPFIND+is+not+defined+in+RFC+2068+and+is+not+supported+by+the+Servlet+API+
(http://svn.activemq.codehaus.org)

Thanks,
   Aaron


On 6/6/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:
> What's the best way to get the ActiveMQ 3.2.4 code?
>
> I tried to update
> 
svn+ssh://svn.activemq.codehaus.org/svnroot/activemq/branches/activemq-3/activemq
> and it didn't take my password (even the one that beaver.codehaus.org
> says is my new SVN password).
>
> Then I tried to check out
> svn+ssh://svn.activemq.org/scm/activemq/branches/activemq-3/activemq
> and it doesn't prompt for a password and doesn't let me on with my
> public key.
>
> Thanks,
> Aaron
>
> On 6/6/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> > I resolved 1, and commented on the other issue.
> >
> > On 6/6/06, Paul McMahan <[EMAIL PROTECTED]> wrote:
> > > Just wanted to send a reminder that there are a couple of patches
> > > waiting to be applied to AMQ 3.2.4 that address problems with creating
> > > connectors from the console.
> > >
> > > https://issues.apache.org/activemq/browse/AMQ-727
> > > http://issues.apache.org/jira/browse/GERONIMO-1451
> > >
> > > Actually, it's possible they have been applied without closing the
> > > JIRAs but I wasn't able to connect to svn.activemq.org to check.
> > >
> > >
> > > Best wishes,
> > > Paul
> > >
> > >
> > > On 6/5/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
> > > > Hiram / James,
> > > >
> > > > Currently we are running off 3.2.4-SNAPSHOT.  Can you release an 
official version?  I'd like to get
> > > > the official G RC out tomorrow.
> > > >
> > > > thanks
> > > >
> > > > Matt
> > > >
> > > > Hiram Chirino wrote:
> > > > > Howdy Folks,
> > > > >
> > > > > I was planing to work on a patch that takes that gbean related modules
> > > > > in ActiveMQ puts them in
> > > > > geronimo.  I just wanted to make sure that there are no objections to
> > > > > this.  Those gbean modules are mostly just gbean related glue code
> > > > > which I think make more sense living in Geronimo.  No one else outside
> > > > > of the geronimo project is interested in the activemq gbean modules.
> > > > >
> > > > > Once that part is done, then I'll start to work on merging/modifying
> > > > > the port to activemq 4.x that was done the 1.2-dead branch.
> > > > >
> > > >
> > >
> >
> >
> > --
> > Regards,
> > Hiram
> >
>


--
[EMAIL PROTECTED]

Re: Maven Repo Woes - Temporary resolution in place


This sounds good as far as it goes.  But we still have 5 single points
of failure in our build.  I would rather set up a site or zone to host
everything Geronimo needs, point all our builds to that only, and have
it create nightly packages of all the dependencies in the Maven repo
so a first-time user can download everything in one shot.

It will also help to get off Maven 1, but I think the steps above are
needed to avoid driving first-time developers away.

Thanks,
   Aaron

On 6/6/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:

All,

I spent a couple of hours working with the Infra structure team on the build 
problems we've been
experiencing.  They were really helpful in isolating the problem and effecting 
a solution.  Joes2
(IRC handle on #asfinfra) was the main contact point.

The problem is that people.apache.org has a limit of 10 concurrent connections 
on it.  The
expectation was that Maven would only be using a single connection but that 
appears to not be the
case.  The Infrastructure team has temporarily lifted the restriction while the 
Maven team looks
into the issue.

For our part I tested a full build with a clean repo and it only failed once 
(and that was an
ibiblio problem).  At this point I think we should have smoother sailing.

Next time you see an Infra guy/gal buy them a beer or two.  They're awesome to 
work with.  From the
time we started talking to the time it was resolved was a little under two 
hours.

Cheers,

Matt

Re: 1.1 Candidate releases available

2006-06-07 Thread Dave Colasurdo


Guillaume Nodet wrote:



and the plugins portlet does not display hyperlinks, so plugins can not 
be installed...




Aaron,

It seems that the plugin problems (installing samples, installing 
plugins from the admin console)that we saw last week have reappeared in 
the RC build.


These problems originally appeared ...then disappeared for a few builds 
but have resurfaced again in the RC build.  Is this a geronimo problem 
or a plugins regen or plugins website issue? It does not seem to be 
related to ibiblio availability..


Here is a link to an earlier append on this subject:

http://www.mail-archive.com/dev@geronimo.apache.org/msg23286.html

Thanks
-Dave-

Re: Maven Repo Woes - Temporary resolution in place

2006-06-07 Thread toby cabot

First off, thanks to Matt and the admins for the workaround!

On Tue, Jun 06, 2006 at 11:36:32PM -0400, Matt Hogstrom wrote:
> In general the problem is really people that are getting involved with 
> Geronimo for the first time as they start out with an empty repo.  The 
> developers and others on the project generally have an up to date repo and 
> work offline to get a build to go faster.

It's worse than that.  The problem is that anytime one of the
dependencies changes you need to do an online build to get it, and
that online build makes dozens and dozens of requests to various
remote repositories for artifacts that already exist locally.

> Noel J. Bergman wrote:
> >Joshua Slive wrote:
> >
> >>So you not only have your build process tied to apache infrastructure
> >>in a non-scalable way
> >
> >Is this the issue with Maven not handling redirects, or something else?

Among other things, it's an issue with Maven making requests to remote
servers for artifacts that were built locally, which is very wasteful.
Sure, there's the "-o" flag but you can't run "-o" all of the time.

[jira] Commented: (AMQ-737) for consumers especially but for producers too, it'd be good to do a brief summary on the command line of the throughput

2006-06-07 Thread james strachan (JIRA)

[ 
https://issues.apache.org/activemq/browse/AMQ-737?page=comments#action_36251 ] 

james strachan commented on AMQ-737:


BTW instructions on running the performance test maven project are here...

http://goopen.org/confluence/display/ACTIVEMQ/ActiveMQ+Performance+Module+Users+Manual

> for consumers especially but for producers too, it'd be good to do a brief 
> summary on the command line of the throughput
> 
>
>  Key: AMQ-737
>  URL: https://issues.apache.org/activemq/browse/AMQ-737
>  Project: ActiveMQ
> Type: Improvement

>   Components: Performance Test
> Versions: 4.0
> Reporter: james strachan
> Assignee: Adrian Co
>  Fix For: 4.1

>
>
> e.g. after running
> mvn activemq-perf:consumer
> it'd be nice to output a little summary something like
> Average throughtput: 1234.45 message/second.
> For average calulation it might be nice to ignore the first couple or the 
> highest & lowest values or something.
> Also for multiple consumers inside the JVM it might be nice to show something 
> like...
> Average throughput : 5000 msg/sec. Average per consumer: 1000 msg/sec, Min 
> consumer: 200 msg/sec, Max consumer: 1400 msg/sec
> so its easy at a glance to get a feel for the results if you are running the 
> tests from a command line

-- 
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-737) for consumers especially but for producers too, it'd be good to do a brief summary on the command line of the throughput

2006-06-07 Thread james strachan (JIRA)

for consumers especially but for producers too, it'd be good to do a brief 
summary on the command line of the throughput


 Key: AMQ-737
 URL: https://issues.apache.org/activemq/browse/AMQ-737
 Project: ActiveMQ
Type: Improvement

  Components: Performance Test  
Versions: 4.0
Reporter: james strachan
 Assigned to: Adrian Co 
 Fix For: 4.1


e.g. after running

mvn activemq-perf:consumer

it'd be nice to output a little summary something like

Average throughtput: 1234.45 message/second.

For average calulation it might be nice to ignore the first couple or the 
highest & lowest values or something.

Also for multiple consumers inside the JVM it might be nice to show something 
like...

Average throughput : 5000 msg/sec. Average per consumer: 1000 msg/sec, Min 
consumer: 200 msg/sec, Max consumer: 1400 msg/sec

so its easy at a glance to get a feel for the results if you are running the 
tests from a command line

-- 
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: M2 : javamail Configuration

2006-06-07 Thread anita kulshreshtha

We have both M1(legacy) and M2 repositories in our list of repos.
May be it finds the one from M2 repository first. 

Thanks
Anita

--- Jacek Laskowski <[EMAIL PROTECTED]> wrote:

> On 6/6/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote:
> 
> >The geronimo-javamail_1.3.1_spec-1.1-SNAPSHOT.jar in M2
> repositories
> > is missing
> org.apache.geronimo.mail.util.QuotedPrintableEncoderStream
> > class. The jar loaded during M1 build has this class. How can I get
> > this jar updated in M2 repositories?
> 
> Have you already worked it out? I think using M1 repositories as
> legacy in M2 will get rid of it or I didn't get it right.
> 
> > Anita
> 
> Jacek
> 
> -- 
> Jacek Laskowski
> http://www.laskowski.net.pl
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

Reorganizing javamai (revisited)

2006-06-07 Thread Rick McGuire

I brought this up a couple of months ago, and I believe we reached a 
consensus on what should be done but the work was put off until after 
1.1 shipped.  Since then, I have a new factor to introduce into this 
discussion, so I want to make sure we've got good agreement on what 
needs to be done.  To refresh, I proposed that the javamail code needed 
to be reorganized so that the javamail-transport jar (which is currently 
part of the Geronimo build) is separated from Geronimo and available 
with the geronimo-javamail-spec jar.  The consensus seemed to lean 
toward the following approach:


1)  keep the javamail spec jar/build the way it is.
2)  create a separate repository for the javamail-transport module and 
continue to build a javamail-transport jar file.
3)  as part of the javamail-transport build, also build an uber-jar that 
combines the spec jar and the transport jar.


I think this will work ok, but I think a slight modification is 
required.  Over the last couple of days, I created a javamail 1.4 
version of the spec jar, with the intent that this version could be made 
an optional plugin.  However, the javamail 1.3 spec jar is going to need 
to be kept around, since it's required to pass the tck.  The javamail 
1.4 jar can't be used, since it will fail the tck signature tests.  It 
looks like the best approach here would be to rename the existing 
javamail spec module to "geronimo-javamail-spec-1.3" and introduce a new 
"geronimo-javamail-spec-1.4" module to create the other version.


In lock-step with that, there are some dependencies between the 
transport jar file and the corresponding spec version.  So the transport 
repository will also need modules to build the matching provider jar. 


So, given all that, here's what I think should be done:

1)  rename the geronimo-spec-javamail module to 
geronimo-spec-javamail-1.3.  This already builds a 
geronimo-javamail_1.3.1_spec-${geronimoSpecsJavamailVersion} jar file, 
which is what we want.


2) create a new geronimo-spec-javamail-1.4 module, which will build a 
geronimo-javamail_1.4_spec-${geronimoSpecsJavamailVersion} jar file.


3) create a new javamail-provider repository (note the name 
change...javamail-transport might have made sense when it only contained 
smtp, but now that it also has Store providers, it doesn't really fit).  
This will have two modules for the 1.3 and 1.4 versions of the 
providers, and will build  
geronimo-javamail_1.3.1_provider-${geronimoProviderJavamailVersion} and 
geronimo-javamail_1.4_provider-${geronimoProviderJavamailVersion} jar files.


4)  Additionally, the javamail-provider build will create two uber-jars 
containing the specs and providers combined:  
geronimo-javamail_1.3.1_mail-${geronimoProviderJavamailVersion} and 
geronimo-javamail_1.4_mail-${geronimoProviderJavamailVersion}


Rick

Re: [RTC] m2-plugins deployment plugin

On 6/7/06, David Jencks <[EMAIL PROTECTED]> wrote:

I've uploaded

http://issues.apache.org/jira/secure/attachment/12335128/geronimo-
deployment-plugin-RTC-VOTE.2.patch

incorporating most of your comments, see below.

Will take a look at it real soon. More below.

david jencks

...

You want me to lie :-) ? I don't think anyone has ever used the in-vm
startServer command in the m1 plugin, so I doubt prasad has tested
this one either.  I still think its worth including as a starting
point in case some one wants to try it out.

Ah, it's a comment to let others know it's untested. Wouldn't it be
better adding TODO or FIXME so there's no doubt about it?

These are basically copies + modifications of the m1 deployment
plugin, copyright 2004.  I don't know if any changes happened in
2005, but 2004 and 2006 are definitely needed.

Well, I'm not a lawer so can't elaborate more on it. I can live with it ;-)

They should all have the @version, but only mojos should have the
@goal in order to not confuse maven.  I've fixed the @version tags as
well as I can find them.

Correct. That was my understanding.

> 5/ geronimo-deployment-plugin/pom.xml has no ASF license header.
fixed.  I think its better to include  the asf license in the source
even if maven removes it during processing.

Correct. No matter how tools will work with the sources they need to
be copyrighted appropriately.

> It doesn't count, though ;-)

Why not?  Because I edited prasad's patch for formatting and removed
unused cruft?  Ken's directive requires 3 +1 votes from committers
other than the proposer (who apparently does not need to be a
committer): although the document he appears to have adapted states
only PMC member votes count, that is not in his directive.  Since he
hasn't responded to requests for clarification I think we have to
take him at his word.

The proposer (!= the author) == DJ nor Prasad => DJ may not vote for
it. Is that correct?

david jencks

Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: M2 : javamail Configuration


On 6/6/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote:


   The geronimo-javamail_1.3.1_spec-1.1-SNAPSHOT.jar in M2 repositories
is missing org.apache.geronimo.mail.util.QuotedPrintableEncoderStream
class. The jar loaded during M1 build has this class. How can I get
this jar updated in M2 repositories?


Have you already worked it out? I think using M1 repositories as
legacy in M2 will get rid of it or I didn't get it right.


Anita


Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: 1.1 Candidate releases available

2006-06-07 Thread Guillaume Nodet


In addition i have the following errors in the console

13:14:46,546 ERROR [LocalAttributeManager] Error saving attributes
java.io.IOException: EXTREMELY CRITICAL!  Unable to move manageable 
attributes working file to proper file name!  Configuration will revert 
to defaults unless this is manually corrected!  (could not rename 
C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to 
C:\tmp\geronimo-1.1-20060607\var\config\config.xml)
   at 
org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449)
   at 
org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618)

   at java.util.TimerThread.mainLoop(Unknown Source)
   at java.util.TimerThread.run(Unknown Source)

and the plugins portlet does not display hyperlinks, so plugins can not 
be installed...


I guess I should raise jiras for these problems.

Cheers,
Guillaume Nodet

Guillaume Nodet wrote:

Shouldn't they include at least the ASF license,  a NOTICE file and 
maybe third party licenses ?


Cheers,
Guillaume Nodet

Jacek Laskowski wrote:


On 6/7/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:


Where can I find this RC ?




Pick your favorite one at http://people.apache.org/~hogstrom/20060607/


Guillaume Nodet




Jacek

Re: Eclipse Plugin V1.1.0 unstable driver now available

2006-06-07 Thread Sachin Patel

Hold off on the V11 testing, as I'm finding issues you may run into.   
I'm working on resolving the issues this morning and will let u know  
when I'm done.


On Jun 7, 2006, at 12:02 AM, Neal Sanche wrote:


Okay Sachin,

I have found what I believe to be the main problem. I looked in my  
Eclipse configuration settings, and found that the Geronimo plugin  
had a little red X on it indicating it was unhappy. So I looked  
into why that could be ant found a small complaint it was making:


Plug-in "org.apache.geronimo.st.v11.ui" version "1.0.0" referenced  
by this feature is missing.


I looked all over and sure enough I do not have a copy of this  
Jarfile anywhere in my Eclipse directory. Where would I find such a  
thing? I'm not brave enough to try this build myself at the moment  
otherwise I would try and make my own version of this. I will see  
if maybe one of the distributions you posted has it.


-Neal

Sachin Patel wrote:
I just posted a new driver.  Could you verify that the problem is  
fixed?


You should be able to just extract over your existing image.  Be  
sure to re-invoke eclipse with "-clean".


Thanks.

On Jun 6, 2006, at 9:53 PM, Neal Sanche wrote:


Fair enough,

I have put in a JIRA, let me know (though the JIRA) what else you  
need from me. I am trying out the other features and will see if  
I get stuck. I can't start the server from inside Eclipse, but  
maybe I can still develop a small application.


-Neal

Sachin Patel wrote:
I'd have to dig into it, I'm not quite sure looking at just the  
stack trace.


On Jun 6, 2006, at 9:32 PM, Neal Sanche wrote:

I will put in a JIRA, for sure. Can you tell me what might be  
going on?


-Neal

Sachin Patel wrote:

Ah shoot, can you open a jira? I can investigate.

On Jun 5, 2006, at 11:57 PM, Neal Sanche wrote:


Sachin Patel wrote:
The following driver can run on both JDK 1.4 or 1.5.  It  
should be run with WTP 1.0x and will eventually but not  
currently run on WTP 1.5.


http://people.apache.org/dist/geronimo/eclipse/unstable/g- 
eclipse-plugin-1.1-SNAPSHOT-deployable.zip


-sachin


Hi Sachin,

I am currently trying to get Eclipse 1.0.2 All In One bundle  
to run your new eclipse plugin with the following result. I  
have installed the plugin, and set up a Geronimo 1.1 server  
that I compiled myself about a week ago. I am going to try a  
recompile in the meantime, but what do you think the  
following means?


Thanks.

-Neal


!ENTRY org.eclipse.osgi 2006-06-05 21:44:07.125
!MESSAGE An error occurred while automatically activating  
bundle org.apache.geronimo.st.jmxagent (14).

!STACK 0
org.osgi.framework.BundleException: The activator  
org.apache.geronimo.st.jmxagent.Activator for bundle  
org.apache.geronimo.st.jmxagent is invalid
   at  
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBund 
leActivator(AbstractBundle.java:149)
   at  
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start 
(BundleContextImpl.java:965)
   at  
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( 
BundleHost.java:316)
   at  
org.eclipse.osgi.framework.internal.core.AbstractBundle.start 
(AbstractBundle.java:264)
   at  
org.eclipse.core.runtime.adaptor.EclipseClassLoader.findLocalCla 
ss(EclipseClassLoader.java:116)
   at  
org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalC 
lass(BundleLoader.java:337)
   at  
org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loa 
dClass(SingleSourcePackage.java:37)
   at  
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass( 
BundleLoader.java:386)
   at  
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass( 
BundleLoader.java:350)
   at  
org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.load 
Class(AbstractClassLoader.java:78)

   at java.lang.ClassLoader.loadClass(Unknown Source)
   at java.lang.ClassLoader.loadClassInternal(Unknown Source)
   at  
org.apache.geronimo.st.v11.core.GeronimoServerBehaviour. 
(GeronimoServerBehaviour.java:54)
   at sun.reflect.NativeConstructorAccessorImpl.newInstance0 
(Native Method)
   at sun.reflect.NativeConstructorAccessorImpl.newInstance 
(Unknown Source)
   at  
sun.reflect.DelegatingConstructorAccessorImpl.newInstance 
(Unknown Source)

   at java.lang.reflect.Constructor.newInstance(Unknown Source)
   at java.lang.Class.newInstance0(Unknown Source)
   at java.lang.Class.newInstance(Unknown Source)
   at  
org.eclipse.core.internal.registry.ConfigurationElement.createEx 
ecutableExtension(ConfigurationElement.java:162)
   at  
org.eclipse.core.internal.registry.ConfigurationElement.createEx 
ecutableExtension(ConfigurationElement.java:142)
   at  
org.eclipse.core.internal.registry.ConfigurationElement.createEx 
ecutableExtension(ConfigurationElement.java:129)
   at  
org.eclipse.core.internal.registry.ConfigurationElementHandle.cr 
eateExecutableExtension(ConfigurationElementHandle.java:48)
   at  
org.eclipse.wst.server.core.internal.ServerType.createServerBeha 
viourDel

Re: Eclipse Plugin V1.1.0 unstable driver now available

2006-06-07 Thread Sachin Patel


Is it in the zip?

On Jun 7, 2006, at 12:02 AM, Neal Sanche wrote:


Okay Sachin,

I have found what I believe to be the main problem. I looked in my  
Eclipse configuration settings, and found that the Geronimo plugin  
had a little red X on it indicating it was unhappy. So I looked  
into why that could be ant found a small complaint it was making:


Plug-in "org.apache.geronimo.st.v11.ui" version "1.0.0" referenced  
by this feature is missing.


I looked all over and sure enough I do not have a copy of this  
Jarfile anywhere in my Eclipse directory. Where would I find such a  
thing? I'm not brave enough to try this build myself at the moment  
otherwise I would try and make my own version of this. I will see  
if maybe one of the distributions you posted has it.


-Neal

Sachin Patel wrote:
I just posted a new driver.  Could you verify that the problem is  
fixed?


You should be able to just extract over your existing image.  Be  
sure to re-invoke eclipse with "-clean".


Thanks.

On Jun 6, 2006, at 9:53 PM, Neal Sanche wrote:


Fair enough,

I have put in a JIRA, let me know (though the JIRA) what else you  
need from me. I am trying out the other features and will see if  
I get stuck. I can't start the server from inside Eclipse, but  
maybe I can still develop a small application.


-Neal

Sachin Patel wrote:
I'd have to dig into it, I'm not quite sure looking at just the  
stack trace.


On Jun 6, 2006, at 9:32 PM, Neal Sanche wrote:

I will put in a JIRA, for sure. Can you tell me what might be  
going on?


-Neal

Sachin Patel wrote:

Ah shoot, can you open a jira? I can investigate.

On Jun 5, 2006, at 11:57 PM, Neal Sanche wrote:


Sachin Patel wrote:
The following driver can run on both JDK 1.4 or 1.5.  It  
should be run with WTP 1.0x and will eventually but not  
currently run on WTP 1.5.


http://people.apache.org/dist/geronimo/eclipse/unstable/g- 
eclipse-plugin-1.1-SNAPSHOT-deployable.zip


-sachin


Hi Sachin,

I am currently trying to get Eclipse 1.0.2 All In One bundle  
to run your new eclipse plugin with the following result. I  
have installed the plugin, and set up a Geronimo 1.1 server  
that I compiled myself about a week ago. I am going to try a  
recompile in the meantime, but what do you think the  
following means?


Thanks.

-Neal


!ENTRY org.eclipse.osgi 2006-06-05 21:44:07.125
!MESSAGE An error occurred while automatically activating  
bundle org.apache.geronimo.st.jmxagent (14).

!STACK 0
org.osgi.framework.BundleException: The activator  
org.apache.geronimo.st.jmxagent.Activator for bundle  
org.apache.geronimo.st.jmxagent is invalid
   at  
org.eclipse.osgi.framework.internal.core.AbstractBundle.loadBund 
leActivator(AbstractBundle.java:149)
   at  
org.eclipse.osgi.framework.internal.core.BundleContextImpl.start 
(BundleContextImpl.java:965)
   at  
org.eclipse.osgi.framework.internal.core.BundleHost.startWorker( 
BundleHost.java:316)
   at  
org.eclipse.osgi.framework.internal.core.AbstractBundle.start 
(AbstractBundle.java:264)
   at  
org.eclipse.core.runtime.adaptor.EclipseClassLoader.findLocalCla 
ss(EclipseClassLoader.java:116)
   at  
org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalC 
lass(BundleLoader.java:337)
   at  
org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loa 
dClass(SingleSourcePackage.java:37)
   at  
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass( 
BundleLoader.java:386)
   at  
org.eclipse.osgi.framework.internal.core.BundleLoader.findClass( 
BundleLoader.java:350)
   at  
org.eclipse.osgi.framework.adaptor.core.AbstractClassLoader.load 
Class(AbstractClassLoader.java:78)

   at java.lang.ClassLoader.loadClass(Unknown Source)
   at java.lang.ClassLoader.loadClassInternal(Unknown Source)
   at  
org.apache.geronimo.st.v11.core.GeronimoServerBehaviour. 
(GeronimoServerBehaviour.java:54)
   at sun.reflect.NativeConstructorAccessorImpl.newInstance0 
(Native Method)
   at sun.reflect.NativeConstructorAccessorImpl.newInstance 
(Unknown Source)
   at  
sun.reflect.DelegatingConstructorAccessorImpl.newInstance 
(Unknown Source)

   at java.lang.reflect.Constructor.newInstance(Unknown Source)
   at java.lang.Class.newInstance0(Unknown Source)
   at java.lang.Class.newInstance(Unknown Source)
   at  
org.eclipse.core.internal.registry.ConfigurationElement.createEx 
ecutableExtension(ConfigurationElement.java:162)
   at  
org.eclipse.core.internal.registry.ConfigurationElement.createEx 
ecutableExtension(ConfigurationElement.java:142)
   at  
org.eclipse.core.internal.registry.ConfigurationElement.createEx 
ecutableExtension(ConfigurationElement.java:129)
   at  
org.eclipse.core.internal.registry.ConfigurationElementHandle.cr 
eateExecutableExtension(ConfigurationElementHandle.java:48)
   at  
org.eclipse.wst.server.core.internal.ServerType.createServerBeha 
viourDelegate(ServerType.java:91)
   at  
org.eclipse.wst.server.core.internal.Server.getBehaviourDelegate 
(Server.java:235)
   at  
org.eclipse.ws

Re: 1.1 Candidate releases available

2006-06-07 Thread Guillaume Nodet

Shouldn't they include at least the ASF license,  a NOTICE file and 
maybe third party licenses ?


Cheers,
Guillaume Nodet

Jacek Laskowski wrote:


On 6/7/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:


Where can I find this RC ?



Pick your favorite one at http://people.apache.org/~hogstrom/20060607/


Guillaume Nodet



Jacek

[jira] Commented: (SM-446) New print component

2006-06-07 Thread Luca Gioppo (JIRA)

[ 
https://issues.apache.org/activemq/browse/SM-446?page=comments#action_36250 ] 

Luca Gioppo commented on SM-446:


As jasperreport is LGPL as it was pointed out in the forum we cannot release it 
under ASL2.
Is this correct?

> New print component
> ---
>
>  Key: SM-446
>  URL: https://issues.apache.org/activemq/browse/SM-446
>  Project: ServiceMix
> Type: New Feature

> Versions: 3.0
>  Environment: Tested under windows 2k for now.
> Reporter: Luca Gioppo
>  Fix For: 3.0
>  Attachments: print.zip
>
> Original Estimate: 2 days
> Remaining: 2 days
>
> The new proposed component for creating jasperreport reports and for printing 
> stuff.

-- 
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: Request to release ActriveMQ 3.2.4

2006-06-07 Thread Christoph Sturm


try http://svn.activemq.codehaus.org/

On 6/6/06, Aaron Mulder <[EMAIL PROTECTED]> wrote:

What's the best way to get the ActiveMQ 3.2.4 code?

I tried to update
svn+ssh://svn.activemq.codehaus.org/svnroot/activemq/branches/activemq-3/activemq
and it didn't take my password (even the one that beaver.codehaus.org
says is my new SVN password).

Then I tried to check out
svn+ssh://svn.activemq.org/scm/activemq/branches/activemq-3/activemq
and it doesn't prompt for a password and doesn't let me on with my
public key.

Thanks,
Aaron

On 6/6/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> I resolved 1, and commented on the other issue.
>
> On 6/6/06, Paul McMahan <[EMAIL PROTECTED]> wrote:
> > Just wanted to send a reminder that there are a couple of patches
> > waiting to be applied to AMQ 3.2.4 that address problems with creating
> > connectors from the console.
> >
> > https://issues.apache.org/activemq/browse/AMQ-727
> > http://issues.apache.org/jira/browse/GERONIMO-1451
> >
> > Actually, it's possible they have been applied without closing the
> > JIRAs but I wasn't able to connect to svn.activemq.org to check.
> >
> >
> > Best wishes,
> > Paul
> >
> >
> > On 6/5/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
> > > Hiram / James,
> > >
> > > Currently we are running off 3.2.4-SNAPSHOT.  Can you release an official 
version?  I'd like to get
> > > the official G RC out tomorrow.
> > >
> > > thanks
> > >
> > > Matt
> > >
> > > Hiram Chirino wrote:
> > > > Howdy Folks,
> > > >
> > > > I was planing to work on a patch that takes that gbean related modules
> > > > in ActiveMQ puts them in
> > > > geronimo.  I just wanted to make sure that there are no objections to
> > > > this.  Those gbean modules are mostly just gbean related glue code
> > > > which I think make more sense living in Geronimo.  No one else outside
> > > > of the geronimo project is interested in the activemq gbean modules.
> > > >
> > > > Once that part is done, then I'll start to work on merging/modifying
> > > > the port to activemq 4.x that was done the 1.2-dead branch.
> > > >
> > >
> >
>
>
> --
> Regards,
> Hiram
>




--
[EMAIL PROTECTED]

[jira] Commented: (SM-446) New print component

2006-06-07 Thread Guillaume Nodet (JIRA)

[ 
https://issues.apache.org/activemq/browse/SM-446?page=comments#action_36249 ] 

Guillaume Nodet commented on SM-446:


ServiceMix is licensed under ASL 2, but the copyrights on your files are LGPL :(

> New print component
> ---
>
>  Key: SM-446
>  URL: https://issues.apache.org/activemq/browse/SM-446
>  Project: ServiceMix
> Type: New Feature

> Versions: 3.0
>  Environment: Tested under windows 2k for now.
> Reporter: Luca Gioppo
>  Fix For: 3.0
>  Attachments: print.zip
>
> Original Estimate: 2 days
> Remaining: 2 days
>
> The new proposed component for creating jasperreport reports and for printing 
> stuff.

-- 
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: 1.1 Candidate releases available


On 6/7/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:

Where can I find this RC ?


Pick your favorite one at http://people.apache.org/~hogstrom/20060607/


Guillaume Nodet


Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

Re: 1.1 Candidate releases available

2006-06-07 Thread Guillaume Nodet


Where can I find this RC ?

Cheers,
Guillaume Nodet

Jacek Laskowski wrote:


On 6/7/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:

We've been busy little beavers this evening and would like to share 
the fruits of our labor.


...

Its late and I'm probably missing something so if there are barriers 
to completing the final release

please let me know ASAP.



Hey Matt,

Hurrrayy! Thanks for your hard work! We (those who don't sleep during
a day :-)) will look after the puppy.

Jacek

Re: 1.1 Candidate releases available


On 6/7/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:


We've been busy little beavers this evening and would like to share the fruits 
of our labor.

...

Its late and I'm probably missing something so if there are barriers to 
completing the final release
please let me know ASAP.


Hey Matt,

Hurrrayy! Thanks for your hard work! We (those who don't sleep during
a day :-)) will look after the puppy.

Jacek

--
Jacek Laskowski
http://www.laskowski.net.pl

1.1 Candidate releases available