[jira] Created: (GERONIMO-4338) Update Geronimo Jetty ServletHost to account for G3609 changes

[Vamsavardhana Reddy (JIRA)]

Update Geronimo Jetty ServletHost to account for G3609 changes
--

 Key: GERONIMO-4338
 URL: https://issues.apache.org/jira/browse/GERONIMO-4338
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: Plugins
Reporter: Vamsavardhana Reddy
Assignee: Vamsavardhana Reddy


Rev 601149 "GERONIMO-3609 Better fix for supplying jndi on forwarded calls as 
well as for servlet listeners" dropped the API 
org.apache.geronimo.jetty6.handler.ComponentContextHandler.getChildHandlerByClass()
 as AbstractImmutableHandler no longer extends AbstractHandlerContainer.  This 
requires corresponding changes to Geronimo Jetty ServletHost in Tuscany plugin. 
 This JIRA is created to keep track of the required changes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[BUILD] trunk: Failed for Revision: 701961

[gawor]

Geronimo Revision: 701961 built with tests included
 
See the full build-0300.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081006/build-0300.log
 
 
See the unit test reports at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081006/unit-test-reports
 

from the specified remote repositories:
  apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  codehaus-snapshots (http://snapshots.repository.codehaus.org),
  java.net (http://download.java.net/maven/1/),
  apache-incubator (http://people.apache.org/repo/m2-incubating-repository/),
  ibiblio.org (http://repo1.maven.org/maven2),
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository)


[INFO] 
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Missing:
--
1) org.apache.yoko:yoko-rmi-spec:jar:1.0

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.yoko 
-DartifactId=yoko-rmi-spec -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.apache.yoko 
-DartifactId=yoko-rmi-spec -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file 
-Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.geronimo.assemblies:geronimo-boilerplate:car:2.2-SNAPSHOT
2) org.apache.yoko:yoko-rmi-spec:jar:1.0

--
1 required artifact is missing.

for artifact: 
  org.apache.geronimo.assemblies:geronimo-boilerplate:car:2.2-SNAPSHOT

from the specified remote repositories:
  apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  codehaus-snapshots (http://snapshots.repository.codehaus.org),
  java.net (http://download.java.net/maven/1/),
  apache-incubator (http://people.apache.org/repo/m2-incubating-repository/),
  ibiblio.org (http://repo1.maven.org/maven2),
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository)

at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:618)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: 
org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing:
--
1) org.apache.yoko:yoko-rmi-spec:jar:1.0

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.yoko 
-DartifactId=yoko-rmi-spec -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.apache.yoko 
-DartifactId=yoko-rmi-spec -Dversion=1.0 -Dpackaging=jar -Dfile=/path/to/file 
-Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.geronimo.assemblies:geronimo-boilerplate:car:2.2-SNAPSHOT
2) org.apache.yoko:yoko-rmi-spec:jar:1.0

--
1 required artifact is missing.

for artifact: 
  org.apache.geronimo.assemblies:geronimo-boilerplate:car:2.2-SNAPSHOT

from the specified remote repositories:
  apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  codehaus-snapshots (http://snapshots.repository.codehaus.org),
  java.net (http://download.java.net/maven/1/),
  apache-incubator (http://people.apache.org/repo/m2-incubating-repository/),
  ibiblio.org (http://repo1.maven.org/maven2),
  apache.snapshots (http://people.apache.org/repo/m2

[jira] Commented: (GERONIMODEVTOOLS-498) How to create a local update site for Geronimo Eclipse Plugin

[Ashish Jain (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637086#action_12637086
 ] 

Ashish Jain commented on GERONIMODEVTOOLS-498:
--

This tutorial is no longer required because from GEP V2.1.3 onwards GEP builds 
generate local update site package automatically. Hence this JIRA can be closed 
as invalid.
Thanks

> How to create a local update site for Geronimo Eclipse Plugin
> -
>
> Key: GERONIMODEVTOOLS-498
> URL: 
> https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-498
> Project: Geronimo-Devtools
>  Issue Type: Task
> Environment: GEP 2.1.2
>Reporter: Ashish Jain
>Assignee: Ashish Jain
>
> Developers developing GEP in Eclipse can create there own local update site 
> and test the modifications made in GEP source code. This is an alternative 
> step of testing the code modifications.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DAYTRADER-61) trying to build Daytrader trunk fails with FATAL ERROR

[Lin Sun (JIRA)]

[ 
https://issues.apache.org/jira/browse/DAYTRADER-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637095#action_12637095
 ] 

Lin Sun commented on DAYTRADER-61:
--

Re Steve's last comment, I think I ran into this too.  So the prob is:

If you install daytrader-tomcat plugin via command line (deploy.sh 
install-plugin), it doesn't work due to the error "Could not find 
org.apache.activemq/activemq-ra/4.1.2/jar in any repo ".
If you install daytrader-tomcat plugin via admin console, it works fine.   

If you later switch to install daytrader-tomcat plugin via command line, IIRC 
it works for me too, as the org.apache.activemq/activemq-ra/4.1.2/jar is avail 
in the repo when installing daytrader-tomcat plugin via admin console.

I agree that I am surprised too that the install-plugin behavior is different 
(from admin console vs. command line).   And it seems best if we can change the 
command line behavior to be same as the admin console thus a user doesn't need 
to download the dependency manually.If you agree with me, maybe we should 
use a new JIRA to track this, as this isn't a daytrader prob?

> trying to build Daytrader trunk fails with FATAL ERROR
> --
>
> Key: DAYTRADER-61
> URL: https://issues.apache.org/jira/browse/DAYTRADER-61
> Project: DayTrader
>  Issue Type: Bug
>  Components: buildsystem
>Reporter: ant elder
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Reopened: (GERONIMO-4141) The war exported as a geronimo plugin in admin console cannot be installed with install-plugin command of deploy.bat|.sh

[Donald Woods (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods reopened GERONIMO-4141:



Reopening till we verify that this is fixed on 2.1.x 

> The war exported as a geronimo plugin in admin console cannot be installed 
> with install-plugin command of deploy.bat|.sh
> 
>
> Key: GERONIMO-4141
> URL: https://issues.apache.org/jira/browse/GERONIMO-4141
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3
> Environment: SLES 10 SP2, JDK 1.5.0
>Reporter: Forrest Xia
>Assignee: Lin Sun
>Priority: Minor
> Fix For: 2.1.4
>
> Attachments: jsp-examples-2.1.0.0.war, 
> jsp-examples-war-2.1-SNAPSHOT.war
>
>
> Steps:
> 1. install a war
> 2. export the war as a G plugin with admin console's export plugin function
> 3. undeploy it thru console, and use deployer install-plugin command to 
> install the exported war
> Results: The installation failed with message like this "installation FAILED: 
> start of org.apache.geronimo.samples/cviewer/2.1.0.0/war failed".
> The server log includes these exceptions:
> "17:12:38,335 ERROR [GBeanInstance] Problem in doFail of 
> samples/cviewer/2.1.0.0/war?J2EEApplication=null,j2eeType=WebModule,name=samples/cviewer/2.1.0.0/war
> java.lang.NullPointerException
> at 
> org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContainer.java:380)
> at 
> org.apache.geronimo.tomcat.TomcatWebAppContext.doFail(TomcatWebAppContext.java:540)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1028)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:541)
> at 
> org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111)
> at 
> org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146)
> at 
> org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120)
> at 
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
> at 
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
> at 
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:543)
> at 
> org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:684)
> at 
> org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:877)
> at 
> org.apache.geronimo.system.plugin.PluginInstallerGBean$4.run(PluginInstallerGBean.java:787)
> at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214)
> at 
> org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:344)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:810)
> 17:12:38,338 ERROR [GBeanInstanceState] Error while starting; GBean is now in 
> the FAILED state: 
> abstractName="samples/cviewer/2.1.0.0/war?J2EEApplication=null,j2eeType=WebModule,name=samples/cviewer/2.1.0.0/war"
> java.lang.NullPointerException
> 

[jira] Updated: (GERONIMO-4141) The war exported as a geronimo plugin in admin console cannot be installed with install-plugin command of deploy.bat|.sh

[Donald Woods (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Donald Woods updated GERONIMO-4141:
---

Affects Version/s: (was: 2.1.4)
   (was: 2.2)
Fix Version/s: (was: 2.2)

removing 2.2 from the affected/fix list, since Lin verified the problem doesn't 
exist in the current 2.2 code

> The war exported as a geronimo plugin in admin console cannot be installed 
> with install-plugin command of deploy.bat|.sh
> 
>
> Key: GERONIMO-4141
> URL: https://issues.apache.org/jira/browse/GERONIMO-4141
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>Affects Versions: 2.1, 2.1.1, 2.1.2, 2.1.3
> Environment: SLES 10 SP2, JDK 1.5.0
>Reporter: Forrest Xia
>Assignee: Lin Sun
>Priority: Minor
> Fix For: 2.1.4
>
> Attachments: jsp-examples-2.1.0.0.war, 
> jsp-examples-war-2.1-SNAPSHOT.war
>
>
> Steps:
> 1. install a war
> 2. export the war as a G plugin with admin console's export plugin function
> 3. undeploy it thru console, and use deployer install-plugin command to 
> install the exported war
> Results: The installation failed with message like this "installation FAILED: 
> start of org.apache.geronimo.samples/cviewer/2.1.0.0/war failed".
> The server log includes these exceptions:
> "17:12:38,335 ERROR [GBeanInstance] Problem in doFail of 
> samples/cviewer/2.1.0.0/war?J2EEApplication=null,j2eeType=WebModule,name=samples/cviewer/2.1.0.0/war
> java.lang.NullPointerException
> at 
> org.apache.geronimo.tomcat.TomcatContainer.removeContext(TomcatContainer.java:380)
> at 
> org.apache.geronimo.tomcat.TomcatWebAppContext.doFail(TomcatWebAppContext.java:540)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:1028)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:268)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:541)
> at 
> org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111)
> at 
> org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146)
> at 
> org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120)
> at 
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:176)
> at 
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:44)
> at 
> org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:254)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:294)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
> at 
> org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:555)
> at 
> org.apache.geronimo.kernel.basic.BasicKernel.startRecursiveGBean(BasicKernel.java:379)
> at 
> org.apache.geronimo.kernel.config.ConfigurationUtil.startConfigurationGBeans(ConfigurationUtil.java:456)
> at 
> org.apache.geronimo.kernel.config.KernelConfigurationManager.start(KernelConfigurationManager.java:187)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:562)
> at 
> org.apache.geronimo.kernel.config.SimpleConfigurationManager.startConfiguration(SimpleConfigurationManager.java:543)
> at 
> org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:684)
> at 
> org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:877)
> at 
> org.apache.geronimo.system.plugin.PluginInstallerGBean$4.run(PluginInstallerGBean.java:787)
> at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:214)
> at 
> org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:344)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
> at java.lang.Thread.run(Thread.java:810)
> 17:12:38,338 ERROR [GBeanInstanceState] Error while starting; GBean is now in 
> t

Re: An idea for defining custom valves in config.xml

[Donald Woods]

In-line below.


David Jencks wrote:


On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:

  Hey all.  I'm working on an idea for allowing custom valves to be 
defined in config.xml.  Currently this isn't possible since the tomcat 
classloader would not contain the custom classes for the valve.  I've 
create a jira for tracking this issue [1] and it contains a few links 
to workarounds.  IMHO, The solution we should be looking for is a way 
to add classes to a module without having to undeploy, modify the 
module config, and redeploying. 


People have suggested stuff like this before.  IMO it pretty much goes 
against the fundamental idea of geronimo of having fairly fixed plugins 
with only a few knobs to turn to adjust things in config.xml and 
config-substitutions.properties.


Why is changing the classloader contents in config.xml a good idea? 
 What is so hard about redeploying the app if you want to change its 
classloader significantly?  If you want to change a class in the app you 
have to redeploy it why is this situation different?




We shouldn't expect every Geronimo user to have to setup a local build 
environment to perform such Tomcat reconfiguration.  Especially given 
what Jason is trying to do doesn't require Tomcat users to rebuild 
Tomcat  This is a deficiency in Geronimo that needs to be resolved.





thanks
david jencks


I think this can be done by allowing a user to indicate jars that 
should be loaded by a module within the config.xml.  These jars can 
then be added to the module's classloader for use by the module.  I'm 
not extremely familiar with how our classloader works, but I've taken 
a look through the code and I think the ability to add to the 
classloader can be implemented without too much difficulty.  I'm not 
quite sure what type of scope to give this change, though.  Should I 
leave it as a change aimed solely at tomcat valves or should it be 
expanded to encompass any configuration?  I realize this is only a 
rough idea of what i plan to do, but I'm still working out the details 
of how to proceed.  I'm hoping for some feedback on what I intend to 
do and possibly some alternate ideas if anyone has some.


Thanks!
 


[1]  https://issues.apache.org/jira/browse/GERONIMO-4335

--
~Jason Warner

Re: An idea for defining custom valves in config.xml

[Jason Warner]

On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]> wrote:

>
> On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:
>
>   Hey all.  I'm working on an idea for allowing custom valves to be defined
> in config.xml.  Currently this isn't possible since the tomcat classloader
> would not contain the custom classes for the valve.  I've create a jira for
> tracking this issue [1] and it contains a few links to workarounds.  IMHO,
> The solution we should be looking for is a way to add classes to a module
> without having to undeploy, modify the module config, and redeploying.
>
>
> People have suggested stuff like this before.  IMO it pretty much goes
> against the fundamental idea of geronimo of having fairly fixed plugins with
> only a few knobs to turn to adjust things in config.xml and
> config-substitutions.properties.
>
> Why is changing the classloader contents in config.xml a good idea?  What
> is so hard about redeploying the app if you want to change its classloader
> significantly?  If you want to change a class in the app you have to
> redeploy it why is this situation different?
>

The specific instance I have in mind for this change is using a custom valve
for tomcat, so I think the scope really should be limited to just the tomcat
module.  I can't think of another instance where this would be useful, so
it's probably not necessary or desirable to expand it further.  I believe
this situation is different because the structure of geronimo is causing a
disconnect between the functionality of tomcat and the functionality of
tomcat as it is embedded in geronimo.  As Don just said in the middle of my
typing this, I don't believe we should expect the average user to have to
rebuild one of our modules to add something that can be added in a much
simpler way within tomcat itself.

Thanks!

>
> thanks
> david jencks
>
>
> I think this can be done by allowing a user to indicate jars that should be
> loaded by a module within the config.xml.  These jars can then be added to
> the module's classloader for use by the module.  I'm not extremely familiar
> with how our classloader works, but I've taken a look through the code and I
> think the ability to add to the classloader can be implemented without too
> much difficulty.  I'm not quite sure what type of scope to give this change,
> though.  Should I leave it as a change aimed solely at tomcat valves or
> should it be expanded to encompass any configuration?  I realize this is
> only a rough idea of what i plan to do, but I'm still working out the
> details of how to proceed.  I'm hoping for some feedback on what I intend to
> do and possibly some alternate ideas if anyone has some.
>
> Thanks!
>
>
> [1]  https://issues.apache.org/jira/browse/GERONIMO-4335
>
> --
> ~Jason Warner
>
>
>


-- 
~Jason Warner

[BUILD] trunk: Failed for Revision: 702139

[gawor]

Geronimo Revision: 702139 built with tests included
 
See the full build-0900.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081006/build-0900.log
 
 
See the unit test reports at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081006/unit-test-reports
 
from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  java.net (http://download.java.net/maven/1/),
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  codehaus-snapshots (http://snapshots.repository.codehaus.org),
  apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Path to dependency: 
1) org.apache.geronimo.plugins:sysdb-console-jetty:car:2.2-SNAPSHOT


at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:575)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.artifact.resolver.ArtifactResolutionException: 
Unable to get dependency information: Unable to read the metadata file for 
artifact 'org.tranql:tranql-connector-oracle-local:rar': Cannot find parent: 
org.tranql:tranql-connector-oracle for project: 
null:tranql-connector-oracle-local:rar:null for project 
null:tranql-connector-oracle-local:rar:null
  org.tranql:tranql-connector-oracle-local:rar:1.3

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  java.net (http://download.java.net/maven/1/),
  apache.snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  apache-snapshots (http://people.apache.org/repo/m2-snapshot-repository),
  codehaus-snapshots (http://snapshots.repository.codehaus.org),
  apache-incubator (http://people.apache.org/repo/m2-incubating-repository/)
Path to dependency: 
1) org.apache.geronimo.plugins:sysdb-console-jetty:car:2.2-SNAPSHOT


at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:403)
at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:76)
at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:300)
at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:288)
at 
org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1415)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:405)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
... 16 more
Caused by: 
org.apache.maven.artifact.metadata.ArtifactMetadataRetrievalException: Unable 
to read the metadata file for artifact 
'org.tranql:tranql-connector-oracle-local:rar': Cannot find parent: 
org.tranql:tranql-connector-oracle for project: 
null:tranql-connector-oracle-local:rar:null for project 
null:tranql-connector-oracle-local:rar:null
at 
org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:135)
at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:380)
... 22 more
Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find 
parent: org.tranql:tranql-connector-oracle for project: 
null:tranql-connector-oracle-local:rar:null for project 
null:tranql-connector-oracle-local

Re: An idea for defining custom valves in config.xml

[Joe Bohn]

Jason Warner wrote:



On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED] 
> wrote:



On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:


  Hey all.  I'm working on an idea for allowing custom valves to
be defined in config.xml.  Currently this isn't possible since the
tomcat classloader would not contain the custom classes for the
valve.  I've create a jira for tracking this issue [1] and it
contains a few links to workarounds.  IMHO, The solution we should
be looking for is a way to add classes to a module without having
to undeploy, modify the module config, and redeploying. 


People have suggested stuff like this before.  IMO it pretty much
goes against the fundamental idea of geronimo of having fairly fixed
plugins with only a few knobs to turn to adjust things in config.xml
and config-substitutions.properties.

Why is changing the classloader contents in config.xml a good idea?
 What is so hard about redeploying the app if you want to change its
classloader significantly?  If you want to change a class in the app
you have to redeploy it why is this situation different?


The specific instance I have in mind for this change is using a custom 
valve for tomcat, so I think the scope really should be limited to just 
the tomcat module.  I can't think of another instance where this would 
be useful, so it's probably not necessary or desirable to expand it 
further.  I believe this situation is different because the structure of 
geronimo is causing a disconnect between the functionality of tomcat and 
the functionality of tomcat as it is embedded in geronimo.  As Don just 
said in the middle of my typing this, I don't believe we should expect 
the average user to have to rebuild one of our modules to add something 
that can be added in a much simpler way within tomcat itself. 


Assuming that you can add a new valve to Tomcat with a simple 
configuration change then I agree that we should be able to do the same 
thing within Geronimo without requiring a user to redeploy the Tomcat 
plugin.


I also agree that it seems this would be a tomcat module specific change 
and not a general purpose thing (at least for now).


I know that David Jencks will cringe  but it seems like we should be 
able to do this in a similar fashion to how we extend the classloader in 
SharedLib.java.   We can just add an attribute or two on the Tomcat 
GBean so the user can specify the location(s) of their valve jars and 
then extend the classpath when the bean is constructed.


Joe




Thanks!


thanks
david jencks



I think this can be done by allowing a user to indicate jars that
should be loaded by a module within the config.xml.  These jars
can then be added to the module's classloader for use by the
module.  I'm not extremely familiar with how our classloader
works, but I've taken a look through the code and I think the
ability to add to the classloader can be implemented without too
much difficulty.  I'm not quite sure what type of scope to give
this change, though.  Should I leave it as a change aimed solely
at tomcat valves or should it be expanded to encompass any
configuration?  I realize this is only a rough idea of what i plan
to do, but I'm still working out the details of how to proceed. 
I'm hoping for some feedback on what I intend to do and possibly

some alternate ideas if anyone has some.

Thanks!
 


[1]  https://issues.apache.org/jira/browse/GERONIMO-4335

-- 
~Jason Warner





--
~Jason Warner

Re: svn commit: r702167 - in /geronimo/site/trunk/docs/plugins: geronimo-2.1.3/geronimo-plugins.xml geronimo-2.1.4/geronimo-plugins.xml geronimo-2.2/geronimo-plugins.xml samples-2.1.2/geronimo-plugins

[Joe Bohn]

comment inline below.

[EMAIL PROTECTED] wrote:

Author: dwoods
Date: Mon Oct  6 07:42:43 2008
New Revision: 702167

URL: http://svn.apache.org/viewvc?rev=702167&view=rev
Log:
add in private svn repo so plugin installs can find our rebuilt artifacts

Modified:
geronimo/site/trunk/docs/plugins/geronimo-2.1.3/geronimo-plugins.xml
geronimo/site/trunk/docs/plugins/geronimo-2.1.4/geronimo-plugins.xml
geronimo/site/trunk/docs/plugins/geronimo-2.2/geronimo-plugins.xml
geronimo/site/trunk/docs/plugins/samples-2.1.2/geronimo-plugins.xml
geronimo/site/trunk/docs/plugins/samples-2.2/geronimo-plugins.xml

Modified: geronimo/site/trunk/docs/plugins/geronimo-2.1.3/geronimo-plugins.xml
URL: 
http://svn.apache.org/viewvc/geronimo/site/trunk/docs/plugins/geronimo-2.1.3/geronimo-plugins.xml?rev=702167&r1=702166&r2=702167&view=diff
==
--- geronimo/site/trunk/docs/plugins/geronimo-2.1.3/geronimo-plugins.xml 
(original)
+++ geronimo/site/trunk/docs/plugins/geronimo-2.1.3/geronimo-plugins.xml Mon 
Oct  6 07:42:43 2008
@@ -8061,6 +8061,7 @@
 
 
 
http://geronimo.apache.org/plugins/geronimo-2.1.3/
+
http://svn.apache.org/repos/asf/geronimo/server/tags/2.1.3/repository/
 http://repo1.maven.org/maven2/
 http://www.ibiblio.org/maven2/
 

Modified: geronimo/site/trunk/docs/plugins/geronimo-2.1.4/geronimo-plugins.xml
URL: 
http://svn.apache.org/viewvc/geronimo/site/trunk/docs/plugins/geronimo-2.1.4/geronimo-plugins.xml?rev=702167&r1=702166&r2=702167&view=diff
==
--- geronimo/site/trunk/docs/plugins/geronimo-2.1.4/geronimo-plugins.xml 
(original)
+++ geronimo/site/trunk/docs/plugins/geronimo-2.1.4/geronimo-plugins.xml Mon 
Oct  6 07:42:43 2008
@@ -8134,6 +8134,7 @@
 
 
 
http://geronimo.apache.org/plugins/geronimo-2.1.4/
+
http://svn.apache.org/repos/asf/geronimo/server/tags/2.1.3/repository/


I *think* this might be what you intended for 2.1.4 (at least until it 
is released in which case we would want to point to the 2.1.4 tag):


http://svn.apache.org/repos/asf/geronimo/server/branches/2.1/repository/

Am I missing something?

Joe





 http://repo1.maven.org/maven2/
 http://www.ibiblio.org/maven2/
 

Modified: geronimo/site/trunk/docs/plugins/geronimo-2.2/geronimo-plugins.xml
URL: 
http://svn.apache.org/viewvc/geronimo/site/trunk/docs/plugins/geronimo-2.2/geronimo-plugins.xml?rev=702167&r1=702166&r2=702167&view=diff
==
--- geronimo/site/trunk/docs/plugins/geronimo-2.2/geronimo-plugins.xml 
(original)
+++ geronimo/site/trunk/docs/plugins/geronimo-2.2/geronimo-plugins.xml Mon Oct  
6 07:42:43 2008
@@ -9348,6 +9348,7 @@
 
 
 
http://geronimo.apache.org/plugins/geronimo-2.2/
+
http://svn.apache.org/repos/asf/geronimo/server/trunk/repository/
 http://repo1.maven.org/maven2/
 http://www.ibiblio.org/maven2/
 

Modified: geronimo/site/trunk/docs/plugins/samples-2.1.2/geronimo-plugins.xml
URL: 
http://svn.apache.org/viewvc/geronimo/site/trunk/docs/plugins/samples-2.1.2/geronimo-plugins.xml?rev=702167&r1=702166&r2=702167&view=diff
==
--- geronimo/site/trunk/docs/plugins/samples-2.1.2/geronimo-plugins.xml 
(original)
+++ geronimo/site/trunk/docs/plugins/samples-2.1.2/geronimo-plugins.xml Mon Oct 
 6 07:42:43 2008
@@ -2202,6 +2202,7 @@
 
 
 
http://geronimo.apache.org/plugins/samples-2.1.2/
+
http://svn.apache.org/repos/asf/geronimo/server/tags/2.1.2/repository/
 http://repo1.maven.org/maven2/
 http://www.ibiblio.org/maven2/
 

Modified: geronimo/site/trunk/docs/plugins/samples-2.2/geronimo-plugins.xml
URL: 
http://svn.apache.org/viewvc/geronimo/site/trunk/docs/plugins/samples-2.2/geronimo-plugins.xml?rev=702167&r1=702166&r2=702167&view=diff
==
--- geronimo/site/trunk/docs/plugins/samples-2.2/geronimo-plugins.xml (original)
+++ geronimo/site/trunk/docs/plugins/samples-2.2/geronimo-plugins.xml Mon Oct  
6 07:42:43 2008
@@ -1497,6 +1497,7 @@
 
 
 
http://geronimo.apache.org/plugins/samples-2.2/
+
http://svn.apache.org/repos/asf/geronimo/server/trunk/repository/
 http://repo1.maven.org/maven2/
 http://www.ibiblio.org/maven2/
 

Re: Continuous TCK Testing

[Jason Warner]

Just got around to reading this.  Thanks for the brain dump, Jason.  No
questions as of yet, but I'm sure I'll need a few more reads before I
understand it all.

On Thu, Oct 2, 2008 at 2:34 PM, Jason Dillon <[EMAIL PROTECTED]> wrote:

> On Oct 1, 2008, at 11:20 PM, Jason Warner wrote:
>
>  Is the GBuild stuff in svn the same as the anthill-based code or is that
>> something different?  GBuild seems to have scripts for running tck and that
>> leads me to think they're the same thing, but I see no mention of anthill in
>> the code.
>>
>
> The Anthill stuff is completely different than the GBuild stuff.  I started
> out trying to get the TCK automated using GBuild, but decided that the
> system lacked too many features to perform as I desired, and went ahead with
> Anthill as it did pretty much everything, though had some stability
> problems.
>
> One of the main reasons why I choose Anthill (AHP, Anthill Pro that is) was
> its build agent and code repository systems.  This allowed me to ensure that
> each build used exactly the desired artifacts.  Another was the configurable
> workflow, which allowed me to create a custom chain of events to handle
> running builds on remote agents and control what data gets set to them, what
> it will collect and what logic to execute once all distributed work has been
> completed for a particular build.  And the kicker which help facilitate
> bringing it all together was its concept of a build life.
>
> At the time I could find *no other* build tool which could meet all of
> these needs, and so I went with AHP instead of spending months
> building/testing features in GBuild.
>
> While AHP supports configuring a lot of stuff via its web-interface, I
> found that it was very cumbersome, so I opted to write some glue, which was
> stored in svn here:
>
>
> https://svn.apache.org/viewvc/geronimo/sandbox/build-support/?pathrev=632245
>
> Its been a while, so I have to refresh my memory on how this stuff actually
> worked.  First let me explain about the code repository (what it calls
> codestation) and why it was critical to the TCK testing IMO.  When we use
> Maven normally, it pulls data from a set of external repositories, picks up
> more repositories from the stuff it downloads and quickly we loose control
> where stuff comes from.  After it pulls down all that stuff, it churns
> though a build and spits out the stuff we care about, normally stuffing them
> (via mvn install) into the local repository.
>
> AHP supports by default tasks to publish artifacts (really just a set of
> files controlled by an Ant-like include/exclude path) from a build agent
> into Codestation, as well as tasks to resolve artifacts (ie. download them
> from Codestation to the local working directory on the build agents system).
>  Each top-level build in AHP gets assigned a new (empty) build life.
>  Artifacts are always published to/resolved from a build life, either that
> of the current build, or of a dependency build.
>
> So what I did was I setup builds for Geronimo Server (the normal
> server/trunk stuff), which did the normal mvn install thingy, but I always
> gave it a custom -Dmaven.local.repository which resolved to something inside
> the working directory for the running build.  The build was still online, so
> it pulled down a bunch of stuff into an empty local repository (so it was a
> clean build wrt the repository, as well as the source code, which was always
> fetched for each new build).  Once the build had finished, I used the
> artifact publisher task to push *all* of the stuff in the local repository
> into Codestation, labled as something like "Maven repository artifacts" for
> the current build life.
>
> Then I setup another build for Apache Geronimo CTS Server (the
> porting/branches/* stuff).  This build was dependent upon the "Maven
> repository artifacts" of the Geronimo Server build, and I configured those
> artifacts to get installed on the build agents system in the same directory
> that I configured the CTS Server build to use for its local maven
> repository.  So again the repo started out empty, then got populated with
> all of the outputs from the normal G build, and then the cts-server build
> was started.  The build of the components and assemblies is normally fairly
> quick and aside from some stuff in the private tck repo won't download muck
> more stuff, because it already had most of its dependencies installed via
> the Codestation dependency resolution.   Once the build finished, I
> published to cts-server assembly artifacts back to Codestation under like
> "CTS Server Assemblies" or something.
>
> Up until this point its normal builds, but now we have built the G server,
> then built the CTS server (using the *exact* artifacts from the G server
> build, even though each might have happened on a different build agent).
>  And now we need to go and run a bunch of tests, using the *exact* CTS
> server assemblies, produce some output, collect it, and once all of

Re: An idea for defining custom valves in config.xml

[David Jencks]

On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:




On Fri, Oct 3, 2008 at 6:55 PM, David Jencks  
<[EMAIL PROTECTED]> wrote:


On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:

  Hey all.  I'm working on an idea for allowing custom valves to be  
defined in config.xml.  Currently this isn't possible since the  
tomcat classloader would not contain the custom classes for the  
valve.  I've create a jira for tracking this issue [1] and it  
contains a few links to workarounds.  IMHO, The solution we should  
be looking for is a way to add classes to a module without having  
to undeploy, modify the module config, and redeploying.


People have suggested stuff like this before.  IMO it pretty much  
goes against the fundamental idea of geronimo of having fairly fixed  
plugins with only a few knobs to turn to adjust things in config.xml  
and config-substitutions.properties.


Why is changing the classloader contents in config.xml a good idea?   
What is so hard about redeploying the app if you want to change its  
classloader significantly?  If you want to change a class in the app  
you have to redeploy it why is this situation different?


The specific instance I have in mind for this change is using a  
custom valve for tomcat, so I think the scope really should be  
limited to just the tomcat module.  I can't think of another  
instance where this would be useful, so it's probably not necessary  
or desirable to expand it further.  I believe this situation is  
different because the structure of geronimo is causing a disconnect  
between the functionality of tomcat and the functionality of tomcat  
as it is embedded in geronimo.  As Don just said in the middle of my  
typing this, I don't believe we should expect the average user to  
have to rebuild one of our modules to add something that can be  
added in a much simpler way within tomcat itself.


Could you explain more about the circumstances for this custom valve?   
Is it intended to be for every app deployed on this tomcat server  
instance rather than for one particular app?  Will it work if it is in  
a child classloader of the tomcat plugin classloader?


At the moment I would MUCH rather see us make it easier for users to  
deploy new/different/modified tomcat servers (and other plugins) than  
introduce a hack to modify classloaders of existing plugins.  Our  
customization story is already  too complicated, IMO we don't need to  
glue on more bits that don't actually fit well.


IMO the best end result for users is to have a new tomcat plugin with  
the needed extra jars and valve configuration.  Lets look for a way to  
make it really easy for our users to get there.


How would you deal with this in an osgi or spring environment?

thanks
david jencks



Thanks!

thanks
david jencks


I think this can be done by allowing a user to indicate jars that  
should be loaded by a module within the config.xml.  These jars can  
then be added to the module's classloader for use by the module.   
I'm not extremely familiar with how our classloader works, but I've  
taken a look through the code and I think the ability to add to the  
classloader can be implemented without too much difficulty.  I'm  
not quite sure what type of scope to give this change, though.   
Should I leave it as a change aimed solely at tomcat valves or  
should it be expanded to encompass any configuration?  I realize  
this is only a rough idea of what i plan to do, but I'm still  
working out the details of how to proceed.  I'm hoping for some  
feedback on what I intend to do and possibly some alternate ideas  
if anyone has some.


Thanks!


[1]  https://issues.apache.org/jira/browse/GERONIMO-4335

--
~Jason Warner





--
~Jason Warner

URL encoding of colons in web permissions

[David Jencks]

There's a new MR for the jacc spec and one of the changes is related  
to something we've already tried to solve for dealing with the pluto  
console urls which sometimes have colons in them for instance when a  
jdbc url is in a query parameter in the url..



Here's the text of the spec change:

The name of the permission checked in a transport or pre-dispatch  
decision must
be the unqualified request URI minus the context path. All colon  
characters

occurring within the name must be represented using escaped encoding1.


Here's our current code:

static String encodeColons(HttpServletRequest request) {
String result = request.getServletPath() +  
(request.getPathInfo() == null ? "" : request.getPathInfo());


if (result.indexOf("%3A") > -1) result =  
result.replaceAll("%3A", "%3A%3A");
if (result.indexOf(":") > -1) result = result.replaceAll(":",  
"%3A");


return result;
}


I think that we are being over-enthusiastic and should leave out the  
doubling of a pre-encoded colon:


static String encodeColons(HttpServletRequest request) {
String result = request.getServletPath() +  
(request.getPathInfo() == null ? "" : request.getPathInfo());


if (result.indexOf(":") > -1) result = result.replaceAll(":",  
"%3A");


return result;
}


Does this seem right?

thanks
david jencks

Re: Continuous TCK Testing

[Jason Dillon]

Sure np, took me a while to get around to writing it too ;-)

--jason


On Oct 6, 2008, at 10:24 PM, Jason Warner wrote:

Just got around to reading this.  Thanks for the brain dump, Jason.   
No questions as of yet, but I'm sure I'll need a few more reads  
before I understand it all.


On Thu, Oct 2, 2008 at 2:34 PM, Jason Dillon  
<[EMAIL PROTECTED]> wrote:

On Oct 1, 2008, at 11:20 PM, Jason Warner wrote:

Is the GBuild stuff in svn the same as the anthill-based code or is  
that something different?  GBuild seems to have scripts for running  
tck and that leads me to think they're the same thing, but I see no  
mention of anthill in the code.


The Anthill stuff is completely different than the GBuild stuff.  I  
started out trying to get the TCK automated using GBuild, but  
decided that the system lacked too many features to perform as I  
desired, and went ahead with Anthill as it did pretty much  
everything, though had some stability problems.


One of the main reasons why I choose Anthill (AHP, Anthill Pro that  
is) was its build agent and code repository systems.  This allowed  
me to ensure that each build used exactly the desired artifacts.   
Another was the configurable workflow, which allowed me to create a  
custom chain of events to handle running builds on remote agents and  
control what data gets set to them, what it will collect and what  
logic to execute once all distributed work has been completed for a  
particular build.  And the kicker which help facilitate bringing it  
all together was its concept of a build life.


At the time I could find *no other* build tool which could meet all  
of these needs, and so I went with AHP instead of spending months  
building/testing features in GBuild.


While AHP supports configuring a lot of stuff via its web-interface,  
I found that it was very cumbersome, so I opted to write some glue,  
which was stored in svn here:


   https://svn.apache.org/viewvc/geronimo/sandbox/build-support/?pathrev=632245

Its been a while, so I have to refresh my memory on how this stuff  
actually worked.  First let me explain about the code repository  
(what it calls codestation) and why it was critical to the TCK  
testing IMO.  When we use Maven normally, it pulls data from a set  
of external repositories, picks up more repositories from the stuff  
it downloads and quickly we loose control where stuff comes from.   
After it pulls down all that stuff, it churns though a build and  
spits out the stuff we care about, normally stuffing them (via mvn  
install) into the local repository.


AHP supports by default tasks to publish artifacts (really just a  
set of files controlled by an Ant-like include/exclude path) from a  
build agent into Codestation, as well as tasks to resolve artifacts  
(ie. download them from Codestation to the local working directory  
on the build agents system).  Each top-level build in AHP gets  
assigned a new (empty) build life.  Artifacts are always published  
to/resolved from a build life, either that of the current build, or  
of a dependency build.


So what I did was I setup builds for Geronimo Server (the normal  
server/trunk stuff), which did the normal mvn install thingy, but I  
always gave it a custom -Dmaven.local.repository which resolved to  
something inside the working directory for the running build.  The  
build was still online, so it pulled down a bunch of stuff into an  
empty local repository (so it was a clean build wrt the repository,  
as well as the source code, which was always fetched for each new  
build).  Once the build had finished, I used the artifact publisher  
task to push *all* of the stuff in the local repository into  
Codestation, labled as something like "Maven repository artifacts"  
for the current build life.


Then I setup another build for Apache Geronimo CTS Server (the  
porting/branches/* stuff).  This build was dependent upon the "Maven  
repository artifacts" of the Geronimo Server build, and I configured  
those artifacts to get installed on the build agents system in the  
same directory that I configured the CTS Server build to use for its  
local maven repository.  So again the repo started out empty, then  
got populated with all of the outputs from the normal G build, and  
then the cts-server build was started.  The build of the components  
and assemblies is normally fairly quick and aside from some stuff in  
the private tck repo won't download muck more stuff, because it  
already had most of its dependencies installed via the Codestation  
dependency resolution.   Once the build finished, I published to cts- 
server assembly artifacts back to Codestation under like "CTS Server  
Assemblies" or something.


Up until this point its normal builds, but now we have built the G  
server, then built the CTS server (using the *exact* artifacts from  
the G server build, even though each might have happened on a  
different build agent).  And now we need to go and run a

Re: An idea for defining custom valves in config.xml

[Jason Warner]

On Mon, Oct 6, 2008 at 11:56 AM, David Jencks <[EMAIL PROTECTED]>wrote:

>
> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>
>
>
> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]>wrote:
>
>>
>> On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:
>>
>>   Hey all.  I'm working on an idea for allowing custom valves to be
>> defined in config.xml.  Currently this isn't possible since the tomcat
>> classloader would not contain the custom classes for the valve.  I've create
>> a jira for tracking this issue [1] and it contains a few links to
>> workarounds.  IMHO, The solution we should be looking for is a way to add
>> classes to a module without having to undeploy, modify the module config,
>> and redeploying.
>>
>>
>> People have suggested stuff like this before.  IMO it pretty much goes
>> against the fundamental idea of geronimo of having fairly fixed plugins with
>> only a few knobs to turn to adjust things in config.xml and
>> config-substitutions.properties.
>>
>> Why is changing the classloader contents in config.xml a good idea?  What
>> is so hard about redeploying the app if you want to change its classloader
>> significantly?  If you want to change a class in the app you have to
>> redeploy it why is this situation different?
>>
>
> The specific instance I have in mind for this change is using a custom
> valve for tomcat, so I think the scope really should be limited to just the
> tomcat module.  I can't think of another instance where this would be
> useful, so it's probably not necessary or desirable to expand it further.  I
> believe this situation is different because the structure of geronimo is
> causing a disconnect between the functionality of tomcat and the
> functionality of tomcat as it is embedded in geronimo.  As Don just said in
> the middle of my typing this, I don't believe we should expect the average
> user to have to rebuild one of our modules to add something that can be
> added in a much simpler way within tomcat itself.
>
>
> Could you explain more about the circumstances for this custom valve?  Is
> it intended to be for every app deployed on this tomcat server instance
> rather than for one particular app?  Will it work if it is in a child
> classloader of the tomcat plugin classloader?
>

When a valve is added to the tomcat valve chain, it becomes part of the
request processing pipeline.  Every request that is made to that tomcat
server instance passes through this valve chain as it's processed regardless
of whether the valve will act upon it or not.  It's possible that a single
web app will be the only app to use the valve, and for that instance it is
already possible to define the valve in the context of the web app rather
than the tomcat server.  We need to be able to define a valve as part of
tomcat server instance as well, though, to be consistent with tomcat.
Currently we can only define the valves on the per web app basis.
I don't think this would work in a child classloader of the tomcat
plugin classloader.  When we start up the tomcat module now, the currently
defined valves are processed and added to the engine.  The custom valves
would need to be added to the valves already in the tomcat engine to be
available in the way described previously.  Once the valves were added to
the engine (which would be using the tomcat classloader, I believe) the
class def not found issues we currently see would pop back up.  For this to
work, the custom valve classes and the tomcat engine would need to share the
same classloader.

>
> At the moment I would MUCH rather see us make it easier for users to deploy
> new/different/modified tomcat servers (and other plugins) than introduce a
> hack to modify classloaders of existing plugins.  Our customization story is
> already  too complicated, IMO we don't need to glue on more bits that don't
> actually fit well.
>
> IMO the best end result for users is to have a new tomcat plugin with the
> needed extra jars and valve configuration.  Lets look for a way to make it
> really easy for our users to get there.
>

I agree that a whole new plugin with all desired functionality included
would be best for users.  Any ideas how to make this easier than it
currently is?  Perhaps the attribute idea mentioned by Joe could serve as a
temporary solution until we can come up with something better.

>
> How would you deal with this in an osgi or spring environment?
>

> thanks
> david jencks
>
>
>
> Thanks!
>
>>
>> thanks
>> david jencks
>>
>>
>> I think this can be done by allowing a user to indicate jars that should
>> be loaded by a module within the config.xml.  These jars can then be added
>> to the module's classloader for use by the module.  I'm not extremely
>> familiar with how our classloader works, but I've taken a look through the
>> code and I think the ability to add to the classloader can be implemented
>> without too much difficulty.  I'm not quite sure what type of scope to give
>> this change, though.  Shou

Re: An idea for defining custom valves in config.xml

[David Jencks]

On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:




On Mon, Oct 6, 2008 at 11:56 AM, David Jencks  
<[EMAIL PROTECTED]> wrote:


On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:




On Fri, Oct 3, 2008 at 6:55 PM, David Jencks  
<[EMAIL PROTECTED]> wrote:


On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:

  Hey all.  I'm working on an idea for allowing custom valves to  
be defined in config.xml.  Currently this isn't possible since the  
tomcat classloader would not contain the custom classes for the  
valve.  I've create a jira for tracking this issue [1] and it  
contains a few links to workarounds.  IMHO, The solution we should  
be looking for is a way to add classes to a module without having  
to undeploy, modify the module config, and redeploying.


People have suggested stuff like this before.  IMO it pretty much  
goes against the fundamental idea of geronimo of having fairly  
fixed plugins with only a few knobs to turn to adjust things in  
config.xml and config-substitutions.properties.


Why is changing the classloader contents in config.xml a good  
idea?  What is so hard about redeploying the app if you want to  
change its classloader significantly?  If you want to change a  
class in the app you have to redeploy it why is this situation  
different?


The specific instance I have in mind for this change is using a  
custom valve for tomcat, so I think the scope really should be  
limited to just the tomcat module.  I can't think of another  
instance where this would be useful, so it's probably not necessary  
or desirable to expand it further.  I believe this situation is  
different because the structure of geronimo is causing a disconnect  
between the functionality of tomcat and the functionality of tomcat  
as it is embedded in geronimo.  As Don just said in the middle of  
my typing this, I don't believe we should expect the average user  
to have to rebuild one of our modules to add something that can be  
added in a much simpler way within tomcat itself.


Could you explain more about the circumstances for this custom  
valve?  Is it intended to be for every app deployed on this tomcat  
server instance rather than for one particular app?  Will it work if  
it is in a child classloader of the tomcat plugin classloader?


When a valve is added to the tomcat valve chain, it becomes part  
of the request processing pipeline.  Every request that is made to  
that tomcat server instance passes through this valve chain as it's  
processed regardless of whether the valve will act upon it or not.   
It's possible that a single web app will be the only app to use the  
valve, and for that instance it is already possible to define the  
valve in the context of the web app rather than the tomcat server.   
We need to be able to define a valve as part of tomcat server  
instance as well, though, to be consistent with tomcat.  Currently  
we can only define the valves on the per web app basis.
I don't think this would work in a child classloader of the  
tomcat plugin classloader.  When we start up the tomcat module now,  
the currently defined valves are processed and added to the engine.   
The custom valves would need to be added to the valves already in  
the tomcat engine to be available in the way described previously.   
Once the valves were added to the engine (which would be using the  
tomcat classloader, I believe) the class def not found issues we  
currently see would pop back up.  For this to work, the custom valve  
classes and the tomcat engine would need to share the same  
classloader.


Could you try this to be sure?  I would hope that tomcat would use a  
TCCL or supplied classloader for loading components rather than  
something like TomcatEngine.class.getClassLoader() which I believe is  
what you are suggesting it does.


One example of an inconvenient tomcat configuration is the app-per- 
port sample where we set up a whole additional tomcat server in a  
child configuration.  I think all the server components in that  
example are also in a standard tomcat server but its a similar  
situation to what I'm thinking of here in terms of configuring a  
tomcat server in a child classloader.






At the moment I would MUCH rather see us make it easier for users to  
deploy new/different/modified tomcat servers (and other plugins)  
than introduce a hack to modify classloaders of existing plugins.   
Our customization story is already  too complicated, IMO we don't  
need to glue on more bits that don't actually fit well.


IMO the best end result for users is to have a new tomcat plugin  
with the needed extra jars and valve configuration.  Lets look for a  
way to make it really easy for our users to get there.


I agree that a whole new plugin with all desired functionality  
included would be best for users.  Any ideas how to make this easier  
than it currently is?  Perhaps the attribute idea mentioned by Joe  
could serve as a temporary solution until we

Re: svn commit: r702167 - in /geronimo/site/trunk/docs/plugins: geronimo-2.1.3/geronimo-plugins.xml geronimo-2.1.4/geronimo-plugins.xml geronimo-2.2/geronimo-plugins.xml samples-2.1.2/geronimo-plugins

[Donald Woods]

Yep, was just doing a cut-n-paste.  I'll update it.  Thanks.


Joe Bohn wrote:

comment inline below.

[EMAIL PROTECTED] wrote:

Author: dwoods
Date: Mon Oct  6 07:42:43 2008
New Revision: 702167

URL: http://svn.apache.org/viewvc?rev=702167&view=rev
Log:
add in private svn repo so plugin installs can find our rebuilt artifacts

Modified:
geronimo/site/trunk/docs/plugins/geronimo-2.1.3/geronimo-plugins.xml
geronimo/site/trunk/docs/plugins/geronimo-2.1.4/geronimo-plugins.xml
geronimo/site/trunk/docs/plugins/geronimo-2.2/geronimo-plugins.xml
geronimo/site/trunk/docs/plugins/samples-2.1.2/geronimo-plugins.xml
geronimo/site/trunk/docs/plugins/samples-2.2/geronimo-plugins.xml

Modified: 
geronimo/site/trunk/docs/plugins/geronimo-2.1.3/geronimo-plugins.xml
URL: 
http://svn.apache.org/viewvc/geronimo/site/trunk/docs/plugins/geronimo-2.1.3/geronimo-plugins.xml?rev=702167&r1=702166&r2=702167&view=diff 

== 

--- 
geronimo/site/trunk/docs/plugins/geronimo-2.1.3/geronimo-plugins.xml 
(original)
+++ 
geronimo/site/trunk/docs/plugins/geronimo-2.1.3/geronimo-plugins.xml 
Mon Oct  6 07:42:43 2008

@@ -8061,6 +8061,7 @@
 
 
 
http://geronimo.apache.org/plugins/geronimo-2.1.3/ 

+
http://svn.apache.org/repos/asf/geronimo/server/tags/2.1.3/repository/ 

 
http://repo1.maven.org/maven2/
 
http://www.ibiblio.org/maven2/

 

Modified: 
geronimo/site/trunk/docs/plugins/geronimo-2.1.4/geronimo-plugins.xml
URL: 
http://svn.apache.org/viewvc/geronimo/site/trunk/docs/plugins/geronimo-2.1.4/geronimo-plugins.xml?rev=702167&r1=702166&r2=702167&view=diff 

== 

--- 
geronimo/site/trunk/docs/plugins/geronimo-2.1.4/geronimo-plugins.xml 
(original)
+++ 
geronimo/site/trunk/docs/plugins/geronimo-2.1.4/geronimo-plugins.xml 
Mon Oct  6 07:42:43 2008

@@ -8134,6 +8134,7 @@
 
 
 
http://geronimo.apache.org/plugins/geronimo-2.1.4/ 

+
http://svn.apache.org/repos/asf/geronimo/server/tags/2.1.3/repository/ 



I *think* this might be what you intended for 2.1.4 (at least until it 
is released in which case we would want to point to the 2.1.4 tag):


http://svn.apache.org/repos/asf/geronimo/server/branches/2.1/repository/ 



Am I missing something?

Joe




 
http://repo1.maven.org/maven2/
 
http://www.ibiblio.org/maven2/

 

Modified: 
geronimo/site/trunk/docs/plugins/geronimo-2.2/geronimo-plugins.xml
URL: 
http://svn.apache.org/viewvc/geronimo/site/trunk/docs/plugins/geronimo-2.2/geronimo-plugins.xml?rev=702167&r1=702166&r2=702167&view=diff 

== 

--- geronimo/site/trunk/docs/plugins/geronimo-2.2/geronimo-plugins.xml 
(original)
+++ geronimo/site/trunk/docs/plugins/geronimo-2.2/geronimo-plugins.xml 
Mon Oct  6 07:42:43 2008

@@ -9348,6 +9348,7 @@
 
 
 
http://geronimo.apache.org/plugins/geronimo-2.2/ 

+
http://svn.apache.org/repos/asf/geronimo/server/trunk/repository/ 

 
http://repo1.maven.org/maven2/
 
http://www.ibiblio.org/maven2/

 

Modified: 
geronimo/site/trunk/docs/plugins/samples-2.1.2/geronimo-plugins.xml
URL: 
http://svn.apache.org/viewvc/geronimo/site/trunk/docs/plugins/samples-2.1.2/geronimo-plugins.xml?rev=702167&r1=702166&r2=702167&view=diff 

== 

--- 
geronimo/site/trunk/docs/plugins/samples-2.1.2/geronimo-plugins.xml 
(original)
+++ 
geronimo/site/trunk/docs/plugins/samples-2.1.2/geronimo-plugins.xml 
Mon Oct  6 07:42:43 2008

@@ -2202,6 +2202,7 @@
 
 
 
http://geronimo.apache.org/plugins/samples-2.1.2/ 

+
http://svn.apache.org/repos/asf/geronimo/server/tags/2.1.2/repository/ 

 
http://repo1.maven.org/maven2/
 
http://www.ibiblio.org/maven2/

 

Modified: 
geronimo/site/trunk/docs/plugins/samples-2.2/geronimo-plugins.xml
URL: 
http://svn.apache.org/viewvc/geronimo/site/trunk/docs/plugins/samples-2.2/geronimo-plugins.xml?rev=702167&r1=702166&r2=702167&view=diff 

== 

--- geronimo/site/trunk/docs/plugins/samples-2.2/geronimo-plugins.xml 
(original)
+++ geronimo/site/trunk/docs/plugins/samples-2.2/geronimo-plugins.xml 
Mon Oct  6 07:42:43 2008

@@ -1497,6 +1497,7 @@
 
 
 
http://geronimo.apache.org/plugins/samples-2.2/ 

+
http://svn.apache.org/repos/asf/geronimo/server/trunk/repository/ 

 
http://repo1.maven.org/maven2/
 
http://www.ibiblio.org/maven2/

 

Fwd: Tuscany Geronimo integration and the SCA JEE spec

[Vamsavardhana Reddy]

Didn't click "Reply to all" the last time.



-- Forwarded message --
From: Vamsavardhana Reddy <[EMAIL PROTECTED]>
Date: Tue, Oct 7, 2008 at 12:14 AM
Subject: Re: Tuscany Geronimo integration and the SCA JEE spec
To: [EMAIL PROTECTED]




On Sat, Oct 4, 2008 at 12:32 AM, David Jencks <[EMAIL PROTECTED]>wrote:

> Is there an overview of how the existing TGP works, preferably
> comprehensible from a geronimo-centric viewpoint?
>
The current plugin has a deployer for sca-contribution jars and an
EmbeddedSCADomainGBean that wraps
org.apache.tuscany.sca.host.embedded.impl.EmbeddedSCADomain.  The deployer
places the sca-contibution jar under the repository and adds an
EmbeddedRuntimeGBean to the configuration.  When the configuration is
started, the EmbeddedRuntimeGBean deploys the sca-contribution into
EmbeddedSCADomain.  The plugin has servlet-host implementations for
Geronimo-Tomcat and Geronimo-Jetty so that the services exposed with
webservice binding use the webcontainer in Geronimo. Proxies to SCA services
are obtained through the SCADomain made available by the
EmbeddedSCADomainGBean.


> On Oct 3, 2008, at 2:57 AM, ant elder wrote:
>
> I'd like to start spending more time actively working on the Tuscany
> Geronimo integration and having that more support the SCA JEE specification
> (see: [1]). Here is a rough outline of what i'd like to do:
>
> The goal of this would be to use Geronimo and Tuscany to create an
> SCA-enabled Java EE runtime, which from the SCA JEE specification means "a
> Java EE runtime that supports deployment and execution of SCA-enhanced Java
> EE applications as well as SCA-enhanced Java EE modules."
>
> We already have a start of that with the old Tuscany Geronimo Plugin [2]
> and there's another wiki page thats started to be used to capture some
> requirements at [3]. Currently the old TGP has got out of date and doesn't
> work with any current releases of Geronimo or Tuscany so the first thing to
> do is to get a basic plugin going again and then gradually add functionality
> to it so it does things like:
> - adds all Tuscany jars and their dependencys into Geronimo
>
>
> If you build this stuff as a geronimo plugin using the geronimo maven2
> car-maven-plugin the maven dependencies will turn into geronimo plugin
> dependencies and get installed automatically when you install the TGP into a
> geronimo server.  I don't think this was really working when the original
> TGP was written.
>
The current TGP is built using car-maven-plugin.


>
> - supports existing Tuscany webapps without needing to include any Tuscany
> jars or dependencys in the lib directory
>
>
> Keep in mind I know nothing about tuscany :-)
> You may find it valuable to set up a "tuscany classloader" geronimo plugin
> that has all the tuscany jars in it, and has appropriate parents for stuff
> it needs like jee specs or jaxb.  Then any app can use this as a parent
> classloader and get all the tuscany stuff at once, and all apps will be
> using tuscany classes from the same classloader.
>
This seems to be a good idea.


>
>
> - supports simple jar contributions into a Tuscany standalone node
> - supports Tuscany using Geronimo infrastructure for things such as HTTP
> and JMS hosts
> - supports for SCA enabled JEE application local assembly
> - supports SCA wiring across JEE applications and modules
>
>
> These sound cool, wish I knew what they meant :-)
>
> thanks
> david jencks
>
>
>
> Thats a high level and incomplete list, it is in a rough order of when
> things get done and some of the items may not be needed in the log term but
> are just stepping stones to the later items. There's been lots of off list
> discussion about this so i'd like to try to move that all to the mailing
> lists from now so everyone can participate and can see whats going on. I'd
> like to try to break the work down into several milestones with actual
> releases that we can ask users in both Tuscany and Geronimo to try out as we
> go along to get feedback and also to try to promote some interest around SCA
> in JEE.
>
>...ant
>
> [1]
> http://www.oasis-open.org/committees/download.php/29127/sca-jee-1[1].1-spec-wd03.doc
> [2] http://cwiki.apache.org/TUSCANYWIKI/tuscany-geronimo-integration.html
> [3]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Java+EE+Integration
>
>
>
>

[jira] Created: (GERONIMO-4339) Calling MimeMessage#setRecipients with empty array causes ArrayOutOfBoundsException

[Andreas Veithen (JIRA)]

Calling MimeMessage#setRecipients with empty array causes 
ArrayOutOfBoundsException
---

 Key: GERONIMO-4339
 URL: https://issues.apache.org/jira/browse/GERONIMO-4339
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: mail
 Environment: All
Reporter: Andreas Veithen
Priority: Minor
 Attachments: GERONIMO-4339.patch.txt

Calling MimeMessage#setRecipients with an empty array triggers an 
ArrayOutOfBoundsException in InternetHeaders#setHeader(String, Address[]). This 
is caused by an incorrectly constructed if statement in setHeader.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (GERONIMO-4339) Calling MimeMessage#setRecipients with empty array causes ArrayOutOfBoundsException

[Andreas Veithen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Veithen updated GERONIMO-4339:
--

Attachment: GERONIMO-4339.patch.txt

> Calling MimeMessage#setRecipients with empty array causes 
> ArrayOutOfBoundsException
> ---
>
> Key: GERONIMO-4339
> URL: https://issues.apache.org/jira/browse/GERONIMO-4339
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: mail
> Environment: All
>Reporter: Andreas Veithen
>Priority: Minor
> Attachments: GERONIMO-4339.patch.txt
>
>
> Calling MimeMessage#setRecipients with an empty array triggers an 
> ArrayOutOfBoundsException in InternetHeaders#setHeader(String, Address[]). 
> This is caused by an incorrectly constructed if statement in setHeader.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: An idea for defining custom valves in config.xml

[Jason Warner]

On Mon, Oct 6, 2008 at 1:59 PM, David Jencks <[EMAIL PROTECTED]> wrote:

>
> On Oct 6, 2008, at 10:35 AM, Jason Warner wrote:
>
>
>
> On Mon, Oct 6, 2008 at 11:56 AM, David Jencks <[EMAIL PROTECTED]>wrote:
>
>>
>> On Oct 6, 2008, at 7:22 AM, Jason Warner wrote:
>>
>>
>>
>> On Fri, Oct 3, 2008 at 6:55 PM, David Jencks <[EMAIL PROTECTED]>wrote:
>>
>>>
>>> On Oct 3, 2008, at 12:51 PM, Jason Warner wrote:
>>>
>>>   Hey all.  I'm working on an idea for allowing custom valves to be
>>> defined in config.xml.  Currently this isn't possible since the tomcat
>>> classloader would not contain the custom classes for the valve.  I've create
>>> a jira for tracking this issue [1] and it contains a few links to
>>> workarounds.  IMHO, The solution we should be looking for is a way to add
>>> classes to a module without having to undeploy, modify the module config,
>>> and redeploying.
>>>
>>>
>>> People have suggested stuff like this before.  IMO it pretty much goes
>>> against the fundamental idea of geronimo of having fairly fixed plugins with
>>> only a few knobs to turn to adjust things in config.xml and
>>> config-substitutions.properties.
>>>
>>> Why is changing the classloader contents in config.xml a good idea?  What
>>> is so hard about redeploying the app if you want to change its classloader
>>> significantly?  If you want to change a class in the app you have to
>>> redeploy it why is this situation different?
>>>
>>
>> The specific instance I have in mind for this change is using a custom
>> valve for tomcat, so I think the scope really should be limited to just the
>> tomcat module.  I can't think of another instance where this would be
>> useful, so it's probably not necessary or desirable to expand it further.  I
>> believe this situation is different because the structure of geronimo is
>> causing a disconnect between the functionality of tomcat and the
>> functionality of tomcat as it is embedded in geronimo.  As Don just said in
>> the middle of my typing this, I don't believe we should expect the average
>> user to have to rebuild one of our modules to add something that can be
>> added in a much simpler way within tomcat itself.
>>
>>
>> Could you explain more about the circumstances for this custom valve?  Is
>> it intended to be for every app deployed on this tomcat server instance
>> rather than for one particular app?  Will it work if it is in a child
>> classloader of the tomcat plugin classloader?
>>
>
> When a valve is added to the tomcat valve chain, it becomes part of the
> request processing pipeline.  Every request that is made to that tomcat
> server instance passes through this valve chain as it's processed regardless
> of whether the valve will act upon it or not.  It's possible that a single
> web app will be the only app to use the valve, and for that instance it is
> already possible to define the valve in the context of the web app rather
> than the tomcat server.  We need to be able to define a valve as part of
> tomcat server instance as well, though, to be consistent with tomcat.
> Currently we can only define the valves on the per web app basis.
> I don't think this would work in a child classloader of the tomcat
> plugin classloader.  When we start up the tomcat module now, the currently
> defined valves are processed and added to the engine.  The custom valves
> would need to be added to the valves already in the tomcat engine to be
> available in the way described previously.  Once the valves were added to
> the engine (which would be using the tomcat classloader, I believe) the
> class def not found issues we currently see would pop back up.  For this to
> work, the custom valve classes and the tomcat engine would need to share the
> same classloader.
>
>
> Could you try this to be sure?  I would hope that tomcat would use a TCCL
> or supplied classloader for loading components rather than something like
> TomcatEngine.class.getClassLoader() which I believe is what you are
> suggesting it does.
>
> One example of an inconvenient tomcat configuration is the app-per-port
> sample where we set up a whole additional tomcat server in a child
> configuration.  I think all the server components in that example are also
> in a standard tomcat server but its a similar situation to what I'm thinking
> of here in terms of configuring a tomcat server in a child classloader.
>
>
Sure.  It'll take me a bit as I don't actually have any examples prepared
yet.

>
>
>> At the moment I would MUCH rather see us make it easier for users to
>> deploy new/different/modified tomcat servers (and other plugins) than
>> introduce a hack to modify classloaders of existing plugins.  Our
>> customization story is already  too complicated, IMO we don't need to glue
>> on more bits that don't actually fit well.
>>
>> IMO the best end result for users is to have a new tomcat plugin with the
>> needed extra jars and valve configuration.  Lets look for a way to make it
>> really easy for our user

[jira] Assigned: (GERONIMO-4339) Calling MimeMessage#setRecipients with empty array causes ArrayOutOfBoundsException

[Rick McGuire (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rick McGuire reassigned GERONIMO-4339:
--

Assignee: Rick McGuire

> Calling MimeMessage#setRecipients with empty array causes 
> ArrayOutOfBoundsException
> ---
>
> Key: GERONIMO-4339
> URL: https://issues.apache.org/jira/browse/GERONIMO-4339
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: mail
> Environment: All
>Reporter: Andreas Veithen
>Assignee: Rick McGuire
>Priority: Minor
> Attachments: GERONIMO-4339.patch.txt
>
>
> Calling MimeMessage#setRecipients with an empty array triggers an 
> ArrayOutOfBoundsException in InternetHeaders#setHeader(String, Address[]). 
> This is caused by an incorrectly constructed if statement in setHeader.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (GERONIMO-4339) Calling MimeMessage#setRecipients with empty array causes ArrayOutOfBoundsException

[Rick McGuire (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rick McGuire resolved GERONIMO-4339.


Resolution: Fixed

Committed revision 702234.

Thank you Andreas for providing a patch!


> Calling MimeMessage#setRecipients with empty array causes 
> ArrayOutOfBoundsException
> ---
>
> Key: GERONIMO-4339
> URL: https://issues.apache.org/jira/browse/GERONIMO-4339
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: mail
> Environment: All
>Reporter: Andreas Veithen
>Assignee: Rick McGuire
>Priority: Minor
> Attachments: GERONIMO-4339.patch.txt
>
>
> Calling MimeMessage#setRecipients with an empty array triggers an 
> ArrayOutOfBoundsException in InternetHeaders#setHeader(String, Address[]). 
> This is caused by an incorrectly constructed if statement in setHeader.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: URL encoding of colons in web permissions

[Joe Bohn]

Seems reasonable to me.  I don't know why we would need to double encode 
the %3A and it actually seems like it might cause some problems.


Joe


David Jencks wrote:
There's a new MR for the jacc spec and one of the changes is related to 
something we've already tried to solve for dealing with the pluto 
console urls which sometimes have colons in them for instance when a 
jdbc url is in a query parameter in the url..  



Here's the text of the spec change:

The name of the permission checked in a transport or pre-dispatch 
decision must 
be the unqualified request URI minus the context path. All colon characters 
occurring within the name must be represented using escaped encoding1.



Here's our current code:

static String encodeColons(HttpServletRequest request) {
String result = request.getServletPath() + 
(request.getPathInfo() == null ? "" : request.getPathInfo());


if (result.indexOf("%3A") > -1) result = 
result.replaceAll("%3A", "%3A%3A");
if (result.indexOf(":") > -1) result = result.replaceAll(":", 
"%3A");


return result;
}


I think that we are being over-enthusiastic and should leave out the 
doubling of a pre-encoded colon:


static String encodeColons(HttpServletRequest request) {
String result = request.getServletPath() + 
(request.getPathInfo() == null ? "" : request.getPathInfo());


if (result.indexOf(":") > -1) result = result.replaceAll(":", 
"%3A");


return result;
}


Does this seem right?

thanks
david jencks

[jira] Updated: (GERONIMO-4340) MimePartDataSource incorrectly assumes that MimeMessages are never transfer encoded

[Andreas Veithen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andreas Veithen updated GERONIMO-4340:
--

Attachment: GERONIMO-4340.patch.txt

> MimePartDataSource incorrectly assumes that MimeMessages are never transfer 
> encoded
> ---
>
> Key: GERONIMO-4340
> URL: https://issues.apache.org/jira/browse/GERONIMO-4340
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: mail
> Environment: All
>Reporter: Andreas Veithen
> Attachments: GERONIMO-4340.patch.txt
>
>
> MimePartDataSource#getInputStream() assumes that a MimeMessage instance never 
> has a transfer encoding (other than 7bit, 8bit or binary) and simply 
> delegates to MimeMessage#getContentStream(). This is incorrect.
> Example message that is incorrectly decoded by MimePartDataSource:
> Date: Tue, 7 Oct 2008 00:31:30 +0200 (CEST)
> From: [EMAIL PROTECTED]
> Reply-To: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Message-ID: urn:uuid:88163FD5618DFAA54C1223332290272
> Subject: SOAPAction: null
> MIME-Version: 1.0
> Content-Type: text/xml; charset=UTF-8
> Content-Transfer-Encoding: quoted-printable
> X-Message-ID: urn:uuid:88163FD5618DFAA54C1223332290272
>  =3D"http://schemas.xmlsoap.org/soap/envelope/";>=C3=A0 p=
> eine arriv=C3=A9s nous entr=C3=A2mes dans sa chambre<=
> /soapenv:Envelope>

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (GERONIMO-4340) MimePartDataSource incorrectly assumes that MimeMessages are never transfer encoded

[Andreas Veithen (JIRA)]

MimePartDataSource incorrectly assumes that MimeMessages are never transfer 
encoded
---

 Key: GERONIMO-4340
 URL: https://issues.apache.org/jira/browse/GERONIMO-4340
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: mail
 Environment: All
Reporter: Andreas Veithen
 Attachments: GERONIMO-4340.patch.txt

MimePartDataSource#getInputStream() assumes that a MimeMessage instance never 
has a transfer encoding (other than 7bit, 8bit or binary) and simply delegates 
to MimeMessage#getContentStream(). This is incorrect.

Example message that is incorrectly decoded by MimePartDataSource:

Date: Tue, 7 Oct 2008 00:31:30 +0200 (CEST)
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Message-ID: urn:uuid:88163FD5618DFAA54C1223332290272
Subject: SOAPAction: null
MIME-Version: 1.0
Content-Type: text/xml; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Message-ID: urn:uuid:88163FD5618DFAA54C1223332290272

http://schemas.xmlsoap.org/soap/envelope/";>=C3=A0 p=
eine arriv=C3=A9s nous entr=C3=A2mes dans sa chambre<=
/soapenv:Envelope>



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Tuscany Geronimo integration and the SCA JEE spec

[Kevan Miller]

On Oct 3, 2008, at 5:57 AM, ant elder wrote:

I'd like to start spending more time actively working on the Tuscany  
Geronimo integration and having that more support the SCA JEE  
specification (see: [1]). Here is a rough outline of what i'd like  
to do:


The goal of this would be to use Geronimo and Tuscany to create an  
SCA-enabled Java EE runtime, which from the SCA JEE specification  
means "a Java EE runtime that supports deployment and execution of  
SCA-enhanced Java EE applications as well as SCA-enhanced Java EE  
modules."


We already have a start of that with the old Tuscany Geronimo Plugin  
[2] and there's another wiki page thats started to be used to  
capture some requirements at [3]. Currently the old TGP has got out  
of date and doesn't work with any current releases of Geronimo or  
Tuscany so the first thing to do is to get a basic plugin going  
again and then gradually add functionality to it so it does things  
like:


I took a look at Vamsi's recent updates to the Tuscany plugin and  
fixed a minor version dependency problem. I can now build, but  
installation fails with a NullPointerException:


Caused by: java.lang.NullPointerException
	at  
org.apache.tuscany.sca.binding.ws.axis2.WSBindingDefinitionsProvider 
$1.run(WSBindingDefinitionsProvider.java:57)
	at  
org.apache.tuscany.sca.binding.ws.axis2.WSBindingDefinitionsProvider 
$1.run(WSBindingDefinitionsProvider.java:56)

at java.security.AccessController.doPrivileged(Native Method)
	at  
org 
.apache 
.tuscany 
.sca 
.binding 
.ws 
.axis2 
.WSBindingDefinitionsProvider 
.getSCADefinition(WSBindingDefinitionsProvider.java:55)


The NullPointerException is caused because  
WSBindingDefinitionsProvider (line 46) is looking for a  
URLArtifactProcessor for the  
org.apache.tuscany.sca.definitions.SCADefinitions interface. However,  
there isn't a processor defined for this interface. Thus the  
NullPointerException...


Not sure what should be happening, here...

--kevan
 

Re: [DISCUSS] URLClassloader problem

[Tim McConnell]

I've opened the following Axis2 JIRA so that I can attach patch(es) to fix this 
specific scenario.


https://issues.apache.org/jira/browse/AXIS2-4072

Tim McConnell wrote:
Hi, There is at least one scenario using Axis2 and Geronimo that is 
causing jarfiles to get locked on Windows such that a deployed WAR 
cannot be either redeployed or uninstalled. Here is a brief description 
of the failing scenario:


1. A WAR file containing various Axis2 jarfiles in the /lib directory 
(axis2-kernel-1.4, axis2-adb-1.4, axis2-spring) is deployed on the 
Tomcat version of Geronimo 2.1.3
2. Navigate to the deployed app's address to generate the WSDL for the 
web service
3. Redeploy or uninstall of the WAR will now fail since all the jarfiles 
in the WAR /lib directory are locked by Windows and cannot be deleted.


What appears to be happening is that there are three Axis2 
URLClassLoaders in this scenario and at least two of them are creating 
their own ClassPath and URLClassPath$JarLoader objects that apparently 
are locking the jarfiles in the /lib directory. I know that Geronimo has 
the JarFileClassloader and MultiParentClassloader classes to address 
this problems of this type but unfortunately they don't really come into 
play here since the Axis2 libraries are embedded in the WAR's /lib 
directory. I also know that this has been a problem on Windows for a 
long time (at least 2003 -- see Java Bug ID:4950148) and probably won't 
be fixed in the JDK in the immediate future if ever. And finally I know 
that this may not actually be a Geronimo problem but nevertheless 
appears as just that to the Geronimo end-user(s).


Here is what I've tried up to now with varying degree of success:

1. Moved all the jarfiles out of WAR file into Geronimo's shared-lib 
directory added a dependency to the geronimo-web.xml file. This 
fortunately does work and provides a fairly simple work-around but still 
doesn't fix the underlying problem.
2. Tried the corresponding Axis2-1.4.1 jarfiles (that were just recently 
released) but they didn't fix the problem.
3. I was hoping that by using reflection I could clear out some of the 
private variable in the ClassLoader to mitigate this problem. But this 
causes errors in the JVM whenever the private variables (e.g. "classes) 
are updated via reflection.


I wonder if there are other alternatives that I can pursue ?? Kevan has 
suggested at least two:
1. Ask Axis2 to change their ClassLoader using the same techniques that 
Geronimo employs with JarFileClassLoader and MultiParentClassLoader
2. Intercept instantiations of URLClassLoader in Geronimo and change 
them to our own MultiParentClassLoader. I really like this idea since it 
would be an all-encompassing solution and not specific to just Axis2, 
but I don't know how difficult this might be.


Does anyone have any other suggestions and/or recommendations that I can 
or should attempt ??




--
Thanks,
Tim McConnell

Re: Tuscany Geronimo integration and the SCA JEE spec

[Luciano Resende]

You might be missing the  tuscany-definitions-xml dependency.
Check if adding tuscany-definitions-xml
dependency to your pom helps.

On Mon, Oct 6, 2008 at 7:17 PM, Kevan Miller <[EMAIL PROTECTED]> wrote:
>
> On Oct 3, 2008, at 5:57 AM, ant elder wrote:
>
>> I'd like to start spending more time actively working on the Tuscany
>> Geronimo integration and having that more support the SCA JEE specification
>> (see: [1]). Here is a rough outline of what i'd like to do:
>>
>> The goal of this would be to use Geronimo and Tuscany to create an
>> SCA-enabled Java EE runtime, which from the SCA JEE specification means "a
>> Java EE runtime that supports deployment and execution of SCA-enhanced Java
>> EE applications as well as SCA-enhanced Java EE modules."
>>
>> We already have a start of that with the old Tuscany Geronimo Plugin [2]
>> and there's another wiki page thats started to be used to capture some
>> requirements at [3]. Currently the old TGP has got out of date and doesn't
>> work with any current releases of Geronimo or Tuscany so the first thing to
>> do is to get a basic plugin going again and then gradually add functionality
>> to it so it does things like:
>
> I took a look at Vamsi's recent updates to the Tuscany plugin and fixed a
> minor version dependency problem. I can now build, but installation fails
> with a NullPointerException:
>
> Caused by: java.lang.NullPointerException
>at
> org.apache.tuscany.sca.binding.ws.axis2.WSBindingDefinitionsProvider$1.run(WSBindingDefinitionsProvider.java:57)
>at
> org.apache.tuscany.sca.binding.ws.axis2.WSBindingDefinitionsProvider$1.run(WSBindingDefinitionsProvider.java:56)
>at java.security.AccessController.doPrivileged(Native Method)
>at
> org.apache.tuscany.sca.binding.ws.axis2.WSBindingDefinitionsProvider.getSCADefinition(WSBindingDefinitionsProvider.java:55)
>
> The NullPointerException is caused because WSBindingDefinitionsProvider
> (line 46) is looking for a URLArtifactProcessor for the
> org.apache.tuscany.sca.definitions.SCADefinitions interface. However, there
> isn't a processor defined for this interface. Thus the
> NullPointerException...
>
> Not sure what should be happening, here...
>
> --kevan
>
>



-- 
Luciano Resende
Apache Tuscany, Apache PhotArk
http://people.apache.org/~lresende
http://lresende.blogspot.com/

Re: Tuscany Geronimo integration and the SCA JEE spec

[Kevan Miller]

On Oct 6, 2008, at 10:17 PM, Kevan Miller wrote:



On Oct 3, 2008, at 5:57 AM, ant elder wrote:

I'd like to start spending more time actively working on the  
Tuscany Geronimo integration and having that more support the SCA  
JEE specification (see: [1]). Here is a rough outline of what i'd  
like to do:


The goal of this would be to use Geronimo and Tuscany to create an  
SCA-enabled Java EE runtime, which from the SCA JEE specification  
means "a Java EE runtime that supports deployment and execution of  
SCA-enhanced Java EE applications as well as SCA-enhanced Java EE  
modules."


We already have a start of that with the old Tuscany Geronimo  
Plugin [2] and there's another wiki page thats started to be used  
to capture some requirements at [3]. Currently the old TGP has got  
out of date and doesn't work with any current releases of Geronimo  
or Tuscany so the first thing to do is to get a basic plugin going  
again and then gradually add functionality to it so it does things  
like:


I took a look at Vamsi's recent updates to the Tuscany plugin and  
fixed a minor version dependency problem. I can now build, but  
installation fails with a NullPointerException:


Caused by: java.lang.NullPointerException
	at  
org.apache.tuscany.sca.binding.ws.axis2.WSBindingDefinitionsProvider 
$1.run(WSBindingDefinitionsProvider.java:57)
	at  
org.apache.tuscany.sca.binding.ws.axis2.WSBindingDefinitionsProvider 
$1.run(WSBindingDefinitionsProvider.java:56)

at java.security.AccessController.doPrivileged(Native Method)
	at  
org 
.apache 
.tuscany 
.sca 
.binding 
.ws 
.axis2 
.WSBindingDefinitionsProvider 
.getSCADefinition(WSBindingDefinitionsProvider.java:55)


The NullPointerException is caused because  
WSBindingDefinitionsProvider (line 46) is looking for a  
URLArtifactProcessor for the  
org.apache.tuscany.sca.definitions.SCADefinitions interface.  
However, there isn't a processor defined for this interface. Thus  
the NullPointerException...


Not sure what should be happening, here...


K. The plugin needed a new dependency for tuscany-definitions-xml  
(thanks for the info Luciano). Plugin builds and installs for me -- I  
haven't tried to use it... I do see one WARNING:


WARNING: Exception starting module  
org 
.apache 
.tuscany.sca.core.databinding.module.DataBindingModuleActivator :org/ 
apache/tuscany/sca/databinding/jaxb/XMLAdapterExtensionPoint


--kevan