[jira] Closed: (GERONIMO-3747) subprojects should use file system parent poms as parent poms in general
[
https://issues.apache.org/jira/browse/GERONIMO-3747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon closed GERONIMO-3747.
--
Resolution: Fixed
Module parentage has been updated so that the module's parent is ../pom.xml.
All bits under {{framework/\*}} are now in the
{{org.apache.geronimo.framework}} groupId. Other bits under {{plugins/\*}} are
still using {{org.apache.geronimo.modules}} and
{{org.apache.geronimo.configs}}, which should be changed, but can wait until
2.2.
In addition the {{components/\*}} and {{applications/\*}} modules have been
relocated under {{plugins}}.
subprojects should use file system parent poms as parent poms in general
Key: GERONIMO-3747
URL: https://issues.apache.org/jira/browse/GERONIMO-3747
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: buildsystem
Affects Versions: 2.1
Reporter: David Jencks
Assignee: Jason Dillon
Fix For: 2.1
Attachments: GERONIMO-3747-step-1.diff.zip,
GERONIMO-3747-step-1.diff.zip, GERONIMO-3747-step-1.diff.zip
After the move of most stuff into plugins, the parent pom is usually still
o.a.g.modules/modules or o.a.g.configs/configs. I think this is a really bad
idea. I think the main thing that needs to be changed is to move the car
plugin setup code into the root pom. However I'm not sure if this is
possible bit of a chicken/egg situation?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Trunk might break for a little while
I've fixed a few things in the testsuite and it seems to be running fine. Most of the tests seemed to pass, though I do recall seeing one failure, but I'm sleepy and can't remember where. I checked the javaee5 and minimal assemblies to make sure they boot up... which they do. Might have missed something, but it looks like things are back to normal after the module parentage change. --jason On Jan 22, 2008, at 11:04 PM, Jarek Gawor wrote: I updated bunch of things so trunk should work better now but I think testsuites poms still need some updates. Jarek On Jan 22, 2008 5:56 PM, David Jencks [EMAIL PROTECTED] wrote: I'm trying to help jdillon check the pom cleanup he's been working on but I'm having trouble applying the patches, so I've asked him to commit his work so far. We're not 100% sure if it builds correctly or not so you might not want to svn up until we are more sure hopefully very soon. Hope this does not cause too much disruption and thanks david jencks
Specs for geronimo 2.1
I recently fixed a bug in the jacc spec jar so we need to finish making sure it still works :-), release it, and get it into 2.1. We should take a look at the specs in general and make sure the svn tree is appropriately cleaned up. I think there are some problems like the root pom released at 1.3 but there's a copy in trunk at 1.3- SNAPSHOT. Aside from being really wrong I thought we had a policy of stuff being in trunk only when it was being worked on. We should make sure we're using the most up to date spec jar releases I think the servicemix guys have released several with osgification. thanks david jencks
[jira] Commented: (GERONIMO-3776) WebResourcePermission.getName() is not always the string URLPatternSpec is based on, making it impossible to find out the meaning of the permission except through imp
[ https://issues.apache.org/jira/browse/GERONIMO-3776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561611#action_12561611 ] David Jencks commented on GERONIMO-3776: rev 614454 fixes the problem in a new spec jar. We still need to use it in geronimo and publish it. WebResourcePermission.getName() is not always the string URLPatternSpec is based on, making it impossible to find out the meaning of the permission except through implies. --- Key: GERONIMO-3776 URL: https://issues.apache.org/jira/browse/GERONIMO-3776 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Affects Versions: 2.0.x, 2.1 Reporter: David Jencks Assignee: David Jencks Priority: Blocker Fix For: 2.1 Attachments: GERONIMO-3776.diff getName() should return the same string as is used for the URLPatternSpec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Offline Deployer leaving behind temporary files
I see the following in Deployer.java
// todo jar url handling with Sun's VM on Windows leaves a lock
on the module file *preventing rebuilds*
// to address this we use a gross hack and copy the file to a
temporary directory
// the lock on the file will prevent that being deleted properly
until the URLJarFile has
// been GC'ed.
boolean cleanup = true;
try {
tmpDir = File.createTempFile(geronimo-deployer,
.tmpdir);
tmpDir.delete();
tmpDir.mkdir();
tmpFile = new File(tmpDir, moduleFile.getName());
DeploymentUtil.copyFile(moduleFile, tmpFile);
moduleFile = tmpFile;
Can someone explain the preventing rebuilds part in the above? It is
followed by code that creates a temporary copy of the module archive that
should be cleaned up by DeployerReaper which does not delete these files in
case of offline deployment. In online deployment also, the files may be
left behind if the DeployerReaper does not get a chance to run after the
files are added to pendingDeletionIndex. Incase of offline deployment
DeployerReaper does not get a chance at all as the java process terminates
immediately. I have tried deleteOnExit() as well with offline deployment,
but the files won't just go away. I am wondering if the reason this is
introduced in the first place is applicable to 2.x. If not, we can get rid
of this code.
++Vamsi
Re: Can anyone build 1.2 from the soource repository?
Well, with maven 2.0.7 and the 1,2 sources pulled from svn, I did the staged
build. The -Dstage=bootstrap built fine but the second -Dstage=assemble
failed with:
[INFO]
[INFO] Building Geronimo Configs :: OpenEJB
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/srv/home/amarcinkowski/geronimo/server_1.2/configs/openejb/target/classes/META-INF
[INFO] Copying 2 files to
/srv/home/amarcinkowski/geronimo/server_1.2/configs/openejb/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated:
/srv/home/amarcinkowski/geronimo/server_1.2/configs/openejb/target/plan/plan.xml
Downloading:
http://people.apache.org/repo/m2-incubating-repository/org/apache/openejb/openejb-core/2.3-incubating/openejb-core-2.3-incubating.pom
Downloading:
http://repository.codehaus.org/org/apache/openejb/openejb-core/2.3-incubating/openejb-core-2.3-incubating.pom
Downloading:
http://repo1.maven.org/maven2/org/apache/openejb/openejb-core/2.3-incubating/openejb-core-2.3-incubating.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository/org/apache/openejb/openejb-axis/2.3-incubating/openejb-axis-2.3-incubating.pom
Downloading:
http://repository.codehaus.org/org/apache/openejb/openejb-axis/2.3-incubating/openejb-axis-2.3-incubating.pom
Downloading:
http://repo1.maven.org/maven2/org/apache/openejb/openejb-axis/2.3-incubating/openejb-axis-2.3-incubating.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository/org/apache/yoko/yoko-spec-corba/1.0-incubating-M2/yoko-spec-corba-1.0-incubating-M2.pom
11K downloaded
Downloading:
http://people.apache.org/repo/m2-incubating-repository/org/apache/yoko/yoko/1.0-incubating-M2/yoko-1.0-incubating-M2.pom
26K downloaded
Downloading:
http://people.apache.org/repo/m2-incubating-repository/org/apache/openejb/openejb-core/2.3-incubating/openejb-core-2.3-incubating.jar
Downloading:
http://repository.codehaus.org/org/apache/openejb/openejb-core/2.3-incubating/openejb-core-2.3-incubating.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openejb/openejb-core/2.3-incubating/openejb-core-2.3-incubating.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository/org/apache/yoko/yoko-spec-corba/1.0-incubating-M2/yoko-spec-corba-1.0-incubating-M2.jar
1787K downloaded
Downloading:
http://people.apache.org/repo/m2-incubating-repository/org/apache/openejb/openejb-axis/2.3-incubating/openejb-axis-2.3-incubating.jar
Downloading:
http://repository.codehaus.org/org/apache/openejb/openejb-axis/2.3-incubating/openejb-axis-2.3-incubating.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openejb/openejb-axis/2.3-incubating/openejb-axis-2.3-incubating.jar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.apache.openejb:openejb-core:jar:2.3-incubating
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.openejb
-DartifactId=openejb-core \
-Dversion=2.3-incubating -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.openejb
-DartifactId=openejb-core \
-Dversion=2.3-incubating -Dpackaging=jar -Dfile=/path/to/file \
-Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.apache.geronimo.configs:openejb:car:1.2
2) org.apache.openejb:openejb-core:jar:2.3-incubating
2) org.apache.openejb:openejb-axis:jar:2.3-incubating
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.openejb
-DartifactId=openejb-axis \
-Dversion=2.3-incubating -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.openejb
-DartifactId=openejb-axis \
-Dversion=2.3-incubating -Dpackaging=jar -Dfile=/path/to/file \
-Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.apache.geronimo.configs:openejb:car:1.2
2) org.apache.openejb:openejb-axis:jar:2.3-incubating
--
2 required artifacts are missing.
for artifact:
org.apache.geronimo.configs:openejb:car:1.2
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
apache.snapshots
Build error on branches\2.0 building Persistence Deployer config
Has anyone come across this build error Error installing artifact's
metadata: Error installing metadata: Error updating group repository
metadata. only whitespace content allowed before start tag and not \u0
(position: START_DOCUMENT seen \u0... @1:1)? Output from build window
given below.
C:\G\server\branches\2.0\configs\persistence-jpa10-deployermvn -o -e
+ Error stacktraces are turned on.
[INFO]
NOTE: Maven is executing in offline mode. Any artifacts not already in your
loca
l
repository will be inaccessible.
[INFO] Scanning for projects...
[INFO]
-
---
[INFO] Building Geronimo Configs :: Persistence Deployer
[INFO]task-segment: [install]
[INFO]
-
---
[INFO] [enforcer:enforce {execution: default}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated:
C:\G\server\branches\2.0\configs\persistence-jpa10-deployer\ta
rget\plan\plan.xml
log4j:WARN No appenders could be found for logger (
org.codehaus.mojo.pluginsuppo
rt.logging.Logging).
log4j:WARN Please initialize the log4j system properly.
[INFO] [car:package]
[INFO] Packaging module configuration:
C:\G\server\branches\2.0\configs\persiste
nce-jpa10-deployer\target\plan\plan.xml
[INFO] Building jar:
C:\G\server\branches\2.0\configs\persistence-jpa10-deployer
\target\persistence-jpa10-deployer-2.0.3-SNAPSHOT.car
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in:
persistence-jpa10-deployer-2.0.3-SNAPSHOT.car
[INFO] [install:install]
[INFO] Installing
C:\G\server\branches\2.0\configs\persistence-jpa10-deployer\ta
rget\persistence-jpa10-deployer-2.0.3-SNAPSHOT.car to
C:\M2REPO\org\apache\geron
imo\configs\persistence-jpa10-deployer\2.0.3-SNAPSHOT\persistence-jpa10-deployer
-2.0.3-SNAPSHOT.car
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Error installing artifact's metadata: Error installing metadata:
Error up
dating group repository metadata
only whitespace content allowed before start tag and not \u0 (position:
START_DO
CUMENT seen \u0... @1:1)
[INFO]
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error installing
artifac
t's metadata: Error installing metadata: Error updating group repository
metadat
a
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(Defa
ultLifecycleExecutor.java:564)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
fecycle(DefaultLifecycleExecutor.java:480)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal
(Defau
ltLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
dleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
ts(DefaultLifecycleExecutor.java:278)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute
(DefaultLi
fecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.
java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAcces
sorImpl.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.plugin.MojoExecutionException: Error installing
arti
fact's metadata: Error installing metadata: Error updating group repository
meta
data
at org.apache.maven.plugin.install.InstallMojo.execute(
InstallMojo.java:
143)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo
(DefaultPlugi
nManager.java:443)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals
(Defa
ultLifecycleExecutor.java:539)
... 16 more
Caused by: org.apache.maven.artifact.installer.ArtifactInstallationException:
Er
ror installing artifact's metadata: Error installing metadata: Error
updating gr
oup repository metadata
at
org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(
DefaultArtifactInstaller.java:91)
Re: Can anyone build 1.2 from the soource repository?
...OK, after tracking down some revision problems, I changed the openejb
version to 2.2-incubating and fixed the yoko version in the pom it
downloaded. Man, is maven a tangled web of lost dependencies... Anyway, I've
got it built.
Is this version of openejb a problem, it wanted the 2.3-incubating but that
didn't exist.
Thanks.
Alski
AlskiOnTheWeb wrote:
Well, with maven 2.0.7 and the 1,2 sources pulled from svn, I did the
staged build. The -Dstage=bootstrap built fine but the second
-Dstage=assemble failed with:
[INFO]
[INFO] Building Geronimo Configs :: OpenEJB
[INFO]task-segment: [install]
[INFO]
[INFO] [tools:require-java-version {execution: validate-java-version}]
[INFO] [tools:copy-legal-files {execution: install-legal-files}]
[INFO] Created dir:
/srv/home/amarcinkowski/geronimo/server_1.2/configs/openejb/target/classes/META-INF
[INFO] Copying 2 files to
/srv/home/amarcinkowski/geronimo/server_1.2/configs/openejb/target/classes/META-INF
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [car:prepare-plan]
[INFO] Generated:
/srv/home/amarcinkowski/geronimo/server_1.2/configs/openejb/target/plan/plan.xml
Downloading:
http://people.apache.org/repo/m2-incubating-repository/org/apache/openejb/openejb-core/2.3-incubating/openejb-core-2.3-incubating.pom
Downloading:
http://repository.codehaus.org/org/apache/openejb/openejb-core/2.3-incubating/openejb-core-2.3-incubating.pom
Downloading:
http://repo1.maven.org/maven2/org/apache/openejb/openejb-core/2.3-incubating/openejb-core-2.3-incubating.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository/org/apache/openejb/openejb-axis/2.3-incubating/openejb-axis-2.3-incubating.pom
Downloading:
http://repository.codehaus.org/org/apache/openejb/openejb-axis/2.3-incubating/openejb-axis-2.3-incubating.pom
Downloading:
http://repo1.maven.org/maven2/org/apache/openejb/openejb-axis/2.3-incubating/openejb-axis-2.3-incubating.pom
Downloading:
http://people.apache.org/repo/m2-incubating-repository/org/apache/yoko/yoko-spec-corba/1.0-incubating-M2/yoko-spec-corba-1.0-incubating-M2.pom
11K downloaded
Downloading:
http://people.apache.org/repo/m2-incubating-repository/org/apache/yoko/yoko/1.0-incubating-M2/yoko-1.0-incubating-M2.pom
26K downloaded
Downloading:
http://people.apache.org/repo/m2-incubating-repository/org/apache/openejb/openejb-core/2.3-incubating/openejb-core-2.3-incubating.jar
Downloading:
http://repository.codehaus.org/org/apache/openejb/openejb-core/2.3-incubating/openejb-core-2.3-incubating.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openejb/openejb-core/2.3-incubating/openejb-core-2.3-incubating.jar
Downloading:
http://people.apache.org/repo/m2-incubating-repository/org/apache/yoko/yoko-spec-corba/1.0-incubating-M2/yoko-spec-corba-1.0-incubating-M2.jar
1787K downloaded
Downloading:
http://people.apache.org/repo/m2-incubating-repository/org/apache/openejb/openejb-axis/2.3-incubating/openejb-axis-2.3-incubating.jar
Downloading:
http://repository.codehaus.org/org/apache/openejb/openejb-axis/2.3-incubating/openejb-axis-2.3-incubating.jar
Downloading:
http://repo1.maven.org/maven2/org/apache/openejb/openejb-axis/2.3-incubating/openejb-axis-2.3-incubating.jar
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Failed to resolve artifact.
Missing:
--
1) org.apache.openejb:openejb-core:jar:2.3-incubating
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.openejb
-DartifactId=openejb-core \
-Dversion=2.3-incubating -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.openejb
-DartifactId=openejb-core \
-Dversion=2.3-incubating -Dpackaging=jar -Dfile=/path/to/file \
-Durl=[url] -DrepositoryId=[id]
Path to dependency:
1) org.apache.geronimo.configs:openejb:car:1.2
2) org.apache.openejb:openejb-core:jar:2.3-incubating
2) org.apache.openejb:openejb-axis:jar:2.3-incubating
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.openejb
-DartifactId=openejb-axis \
-Dversion=2.3-incubating -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.openejb
-DartifactId=openejb-axis \
-Dversion=2.3-incubating -Dpackaging=jar
[jira] Commented: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561675#action_12561675 ] Vamsavardhana Reddy commented on GERONIMO-3764: --- Incase of offline deployment, using deleteOnExit also did not help. Even at jvm process termination the locks on the files are not released and so the files are left behind. DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3764-2.0.patch Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Offline Deployer leaving behind temporary files
On Jan 23, 2008, at 5:23 AM, Vamsavardhana Reddy wrote:
I see the following in Deployer.java
// todo jar url handling with Sun's VM on Windows leaves
a lock on the module file preventing rebuilds
// to address this we use a gross hack and copy the file
to a temporary directory
// the lock on the file will prevent that being deleted
properly until the URLJarFile has
// been GC'ed.
boolean cleanup = true;
try {
tmpDir = File.createTempFile(geronimo-deployer,
.tmpdir);
tmpDir.delete();
tmpDir.mkdir();
tmpFile = new File(tmpDir, moduleFile.getName());
DeploymentUtil.copyFile(moduleFile, tmpFile);
moduleFile = tmpFile;
Can someone explain the preventing rebuilds part in the above? It
is followed by code that creates a temporary copy of the module
archive that should be cleaned up by DeployerReaper which does not
delete these files in case of offline deployment. In online
deployment also, the files may be left behind if the DeployerReaper
does not get a chance to run after the files are added to
pendingDeletionIndex. Incase of offline deployment DeployerReaper
does not get a chance at all as the java process terminates
immediately. I have tried deleteOnExit() as well with offline
deployment, but the files won't just go away. I am wondering if the
reason this is introduced in the first place is applicable to 2.x.
If not, we can get rid of this code.
Hi Vamsi,
Well, the fact that the files are locked indicates a problem, I think.
Can you tell who's reading the files? I thought we would be using
org.apache.geronimo.kernel.classloader.JarFileClassLoader and would
thus avoid the Windows file locking problem.
Hmm, perhaps we're not calling JarFileClassLoader.destroy()? This
should free up the file locks.
--kevan
Re: Build error on branches\2.0 building Persistence Deployer config
On Jan 23, 2008, at 8:32 AM, Vamsavardhana Reddy wrote: Has anyone come across this build error Error installing artifact's metadata: Error installing metadata: Error updating group repository metadata. only whitespace content allowed before start tag and not \u0 (position: START_DOCUMENT seen \u0... @1:1)? Output from build window given below. I don't recall ever seeing this. I'd cleanup your local repo -- looks like one of the xml files has some bad characters. I'd start by deleting the following directory: C:\M2REPO\org\apache\geronimo\configs\persistence-jpa10-deployer\ And see if that fixes your problem. --kevan
Re: [AsyncHttpClient] data collection instrumentation
Sangjin Lee wrote: The modified patch is there on JIRA. Some follow-up discussions... I think the current implementation works well, but one thing that's difficult to do is to collecting timing data. For example, some of the most important instrumentation data are things like average response time (from request start to request complete) and average connect time (from connect start to connect complete). Currently the context object that's available to monitoring listeners is the request object, along with the timestamp of the event itself. To be able to compute a response time for a given request, one would need to take the timestamp from the request start event, associate it with the request, and store it on the listener. When the request complete event fires, then one would need to look up the stored data using the request object as a key to retrieve the timestamp for the request start event, compute the delta, and store the delta. While all this is possible, it has a number of issues, not the least of which is that one would need to maintain a map of request to start time (as well as request to connect time). This would bloat memory as well as other implications. A substantially easier solution would be to provide the request start time and connect start time as part of the information that's passed to the monitoring listener. Then listeners could simply compute the diff to get the elapsed time very easily with no need to maintain maps of any kind. This could be either part of the request object itself, or if desirable, one could consider a separate context or event object that contains this information. What do you think? Thanks, Sangjin On Jan 22, 2008 1:33 PM, Sangjin Lee [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I took a look at the patch on GERONIMO-3761, and it looks great. Thanks. I have modified your patch for several things, though, and I'm nearly ready to add it to the JIRA report. Comments about the changes... - I rewrote the EventQueue class to use an Executor. Since the Executor implementation provided by the JDK is basically a thread pool associated with a task queue, it provides an identical functionality to what was in EventQueue. I think that it is good to use the constructs from java.util.concurrent.* whenever it makes sense, and I believe this is one of them. - This change also enables us to remove synchronized from notifyMonitoringListener(). The notify method will be called very often and concurrently, and reducing the lock contention will be important. Using an Executor makes it possible to eliminate synchronization, at least at that level. - I associated a shared thread pool (Executor) for all dispatchers. I think it is desirable for dispatchers to share this thread pool rather than each instance of dispatchers creating and maintaining its own thread. - Renamed EventQueue to EventDispatcher. - I also moved the monitoring listener list to EventDispatcher. I also used CopyOnWriteArrayList as the implementation for the list. CopyOnWriteArrayList is an ideal choice for this as it is thread safe and lock-free. Also, our use case is heavy read-access but very infrequent write-access, which CopyOnWriteArrayList is suitable for. - I moved the connection_failed notification to before the getSession() call. The getSession() call here always throws an exception (by design), and thus notification needs to be done before calling getSession(). - I rewrote the CountingMonitor to use AtomicIntegers. This should be slightly safer. - I changed the timestamp calls from System.currentTimeMillis() to System.nanoTime()/100. The nanoTime() call is more high-res, as currentTimeMillis() may be tens of milliseconds accurate on some platforms, and thus not suitable for these measurements. I also have some more follow-up questions, which I'll post soon. Thanks, Sangjin On Jan 17, 2008 10:51 AM, Sangjin Lee [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I like your idea of using the event listener as the main way of doing this. Basically no or multiple listeners would be invoked on a different thread when events occur. The event listener APIs would define those key methods which would contain all the necessary information about the events in an immutable fashion. We could provide a simple adapter that is no op so people can override necessary methods easily. Also, we could provide one implementation which is a counting listener that does the basic metrics collection. What do you think? Only if it can be done without having to maintain the same sort of request-to-start time map that you don't wish to do with the listener. The process of adding data collection should
Re: [AsyncHttpClient] data collection instrumentation
The changes you made look really nice. I think my only concern is whether the Executor used by the EventDispatcher needs to be cleaned up at some point. If it gets finalized appropriately and doesn't leave dangling threads, then I guess I'm ok with it. Rick Sangjin Lee wrote: I took a look at the patch on GERONIMO-3761, and it looks great. Thanks. I have modified your patch for several things, though, and I'm nearly ready to add it to the JIRA report. Comments about the changes... - I rewrote the EventQueue class to use an Executor. Since the Executor implementation provided by the JDK is basically a thread pool associated with a task queue, it provides an identical functionality to what was in EventQueue. I think that it is good to use the constructs from java.util.concurrent.* whenever it makes sense, and I believe this is one of them. - This change also enables us to remove synchronized from notifyMonitoringListener(). The notify method will be called very often and concurrently, and reducing the lock contention will be important. Using an Executor makes it possible to eliminate synchronization, at least at that level. - I associated a shared thread pool (Executor) for all dispatchers. I think it is desirable for dispatchers to share this thread pool rather than each instance of dispatchers creating and maintaining its own thread. - Renamed EventQueue to EventDispatcher. - I also moved the monitoring listener list to EventDispatcher. I also used CopyOnWriteArrayList as the implementation for the list. CopyOnWriteArrayList is an ideal choice for this as it is thread safe and lock-free. Also, our use case is heavy read-access but very infrequent write-access, which CopyOnWriteArrayList is suitable for. - I moved the connection_failed notification to before the getSession() call. The getSession() call here always throws an exception (by design), and thus notification needs to be done before calling getSession(). - I rewrote the CountingMonitor to use AtomicIntegers. This should be slightly safer. - I changed the timestamp calls from System.currentTimeMillis() to System.nanoTime()/100. The nanoTime() call is more high-res, as currentTimeMillis() may be tens of milliseconds accurate on some platforms, and thus not suitable for these measurements. I also have some more follow-up questions, which I'll post soon. Thanks, Sangjin On Jan 17, 2008 10:51 AM, Sangjin Lee [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I like your idea of using the event listener as the main way of doing this. Basically no or multiple listeners would be invoked on a different thread when events occur. The event listener APIs would define those key methods which would contain all the necessary information about the events in an immutable fashion. We could provide a simple adapter that is no op so people can override necessary methods easily. Also, we could provide one implementation which is a counting listener that does the basic metrics collection. What do you think? Thanks, Sangjin On Jan 17, 2008 2:58 AM, Rick McGuire [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Thunderbird is playing very strange games with me this morning, somehow deleting the original post. Anyway, here are my comments on this. I'd like to propose changes to enable some basic stat collection and/or instrumentation to have visibility into performance of AHC. For a given *AsyncHttpClient*, one might want to know metrics like - total request count - total success count - total exception count - total timeout count - connection attempt count - connection failure count - connect time average - connection close count - average response time (as measured from the invocation time to having the response ready) - and others? Collection of metric information would, I think, be a good thing. However, I think we should separate the consolidation of the information from the collection. That is, the client should just have different types of events for data collection, and the event listener would be responsible for presenting the information appropriately. For example, to create the list above, I'd see the following set of events needed: - request made - request completed - request failed - request timeout - connection attempt started - connection failed - connection closed All events would be timestamped, which would allow metrics like average request time to be calculated. This set of events would mean the client would not need to maintain any metric
Re: Offline Deployer leaving behind temporary files
Kevan,
I am testing this with an ear file. So, the EARConfiBuilder should be
reading this file. I guess it is the same with other builders as well. The
JarFileClassLoader has the following comment
* Note: This implementation currently does not work reliably on windows,
since the jar URL handler included with the Sun JavaVM
* holds a read lock on the JarFile, and this lock is not released when the
jar url is dereferenced. To fix this a
* replacement for the jar url handler must be written.
BTW, I am running G 2.0.3-SNAPSHOT on Win XP.
++Vamsi
On Jan 23, 2008 7:48 PM, Kevan Miller [EMAIL PROTECTED] wrote:
On Jan 23, 2008, at 5:23 AM, Vamsavardhana Reddy wrote:
I see the following in Deployer.java
// todo jar url handling with Sun's VM on Windows leaves a
lock on the module file *preventing rebuilds*
// to address this we use a gross hack and copy the file to a
temporary directory
// the lock on the file will prevent that being deleted
properly until the URLJarFile has
// been GC'ed.
boolean cleanup = true;
try {
tmpDir = File.createTempFile(geronimo-deployer,
.tmpdir);
tmpDir.delete();
tmpDir.mkdir();
tmpFile = new File(tmpDir, moduleFile.getName());
DeploymentUtil.copyFile(moduleFile, tmpFile);
moduleFile = tmpFile;
Can someone explain the preventing rebuilds part in the above? It is
followed by code that creates a temporary copy of the module archive that
should be cleaned up by DeployerReaper which does not delete these files in
case of offline deployment. In online deployment also, the files may be
left behind if the DeployerReaper does not get a chance to run after the
files are added to pendingDeletionIndex. Incase of offline deployment
DeployerReaper does not get a chance at all as the java process terminates
immediately. I have tried deleteOnExit() as well with offline deployment,
but the files won't just go away. I am wondering if the reason this is
introduced in the first place is applicable to 2.x. If not, we can get
rid of this code.
Hi Vamsi,
Well, the fact that the files are locked indicates a problem, I think. Can
you tell who's reading the files? I thought we would be using
org.apache.geronimo.kernel.classloader.JarFileClassLoader and would thus
avoid the Windows file locking problem.
Hmm, perhaps we're not calling JarFileClassLoader.destroy()? This should
free up the file locks.
--kevan
Re: Build error on branches\2.0 building Persistence Deployer config
argh... My bad... I should have read the message more carefully :(. I thought it is failing to build the car. While building G 2.0 branch, my system crashed 3 times in a span of 2 hours and the metadata file must have got corrupted. Thanks Kevan. On Jan 23, 2008 8:02 PM, Kevan Miller [EMAIL PROTECTED] wrote: On Jan 23, 2008, at 8:32 AM, Vamsavardhana Reddy wrote: Has anyone come across this build error Error installing artifact's metadata: Error installing metadata: Error updating group repository metadata. only whitespace content allowed before start tag and not \u0 (position: START_DOCUMENT seen \u0... @1:1)? Output from build window given below. I don't recall ever seeing this. I'd cleanup your local repo -- looks like one of the xml files has some bad characters. I'd start by deleting the following directory: C:\M2REPO\org\apache\geronimo\configs\persistence-jpa10-deployer\ And see if that fixes your problem. --kevan
Re: Offline Deployer leaving behind temporary files
On Jan 23, 2008, at 10:02 AM, Vamsavardhana Reddy wrote: Kevan, I am testing this with an ear file. So, the EARConfiBuilder should be reading this file. I guess it is the same with other builders as well. The JarFileClassLoader has the following comment * Note: This implementation currently does not work reliably on windows, since the jar URL handler included with the Sun JavaVM * holds a read lock on the JarFile, and this lock is not released when the jar url is dereferenced. To fix this a * replacement for the jar url handler must be written. BTW, I am running G 2.0.3-SNAPSHOT on Win XP. I wouldn't trust that comment. Dain's commit was addressing this very problem (at least within the server runtime: http://svn.apache.org/viewvc?view=revrevision=399522 You need to check to see what type of ClassLoader is being used. If it's not JarFileClassLoader, then we understand the problem. If it is JarFileClassLoader, then maybe we aren't calling destroy. If we doing all of these things, then obviously I'm wrong again... ;-) --kevan
[jira] Created: (GERONIMODEVTOOLS-271) Integrate and package samples and examples
Integrate and package samples and examples --- Key: GERONIMODEVTOOLS-271 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-271 Project: Geronimo-Devtools Issue Type: Sub-task Reporter: Tim McConnell Assignee: Tim McConnell -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-264) Port Classpath Containers 2.0 code to 2.1.0
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell updated GERONIMODEVTOOLS-264: --- Component/s: eclipse-plugin Affects Version/s: 2.1.0 Fix Version/s: 2.1.0 Port Classpath Containers 2.0 code to 2.1.0 --- Key: GERONIMODEVTOOLS-264 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-264 Project: Geronimo-Devtools Issue Type: Sub-task Components: eclipse-plugin Affects Versions: 2.1.0 Reporter: Tim McConnell Assignee: Tim McConnell Fix For: 2.1.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3778) downloadStatus page in plugin installer isn't grabbing correct configIds array
[ https://issues.apache.org/jira/browse/GERONIMO-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3778: --- Attachment: GERONIMO-3778.patch This patch will now report the list of plugins being installed on the console/plugin installer page. Previously, the plugin installer displayed Processing null because it wasn't grabbing the configIds array correctly. downloadStatus page in plugin installer isn't grabbing correct configIds array -- Key: GERONIMO-3778 URL: https://issues.apache.org/jira/browse/GERONIMO-3778 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Environment: Ubuntu 7.10, Firefox 2.0.0.6 Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor Fix For: 2.1 Attachments: GERONIMO-3778.patch On the downloadStatus page of the plugin installer, the list of plugins to install shows null because the configIds array isn't being requested properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3778) downloadStatus page in plugin installer isn't grabbing correct configIds array
[ https://issues.apache.org/jira/browse/GERONIMO-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong resolved GERONIMO-3778. Resolution: Fixed Patch posted downloadStatus page in plugin installer isn't grabbing correct configIds array -- Key: GERONIMO-3778 URL: https://issues.apache.org/jira/browse/GERONIMO-3778 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Environment: Ubuntu 7.10, Firefox 2.0.0.6 Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor Fix For: 2.1 Attachments: GERONIMO-3778.patch On the downloadStatus page of the plugin installer, the list of plugins to install shows null because the configIds array isn't being requested properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Trunk might break for a little while
Jason, Some modules there were moved from applications/ directory use org.apache.geronimo.applications as groupId and some use org.apache.geronimo.plugins. Should we use org.apache.geronimo.plugins for all these apps to be consistent? Jarek On Jan 23, 2008 3:34 AM, Jason Dillon [EMAIL PROTECTED] wrote: I've fixed a few things in the testsuite and it seems to be running fine. Most of the tests seemed to pass, though I do recall seeing one failure, but I'm sleepy and can't remember where. I checked the javaee5 and minimal assemblies to make sure they boot up... which they do. Might have missed something, but it looks like things are back to normal after the module parentage change. --jason On Jan 22, 2008, at 11:04 PM, Jarek Gawor wrote: I updated bunch of things so trunk should work better now but I think testsuites poms still need some updates. Jarek On Jan 22, 2008 5:56 PM, David Jencks [EMAIL PROTECTED] wrote: I'm trying to help jdillon check the pom cleanup he's been working on but I'm having trouble applying the patches, so I've asked him to commit his work so far. We're not 100% sure if it builds correctly or not so you might not want to svn up until we are more sure hopefully very soon. Hope this does not cause too much disruption and thanks david jencks
[jira] Reopened: (GERONIMO-3778) downloadStatus page in plugin installer isn't grabbing correct configIds array
[ https://issues.apache.org/jira/browse/GERONIMO-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong reopened GERONIMO-3778: My apologies, it's not committed yet. Issue Re-opened downloadStatus page in plugin installer isn't grabbing correct configIds array -- Key: GERONIMO-3778 URL: https://issues.apache.org/jira/browse/GERONIMO-3778 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Environment: Ubuntu 7.10, Firefox 2.0.0.6 Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor Fix For: 2.1 Attachments: GERONIMO-3778.patch On the downloadStatus page of the plugin installer, the list of plugins to install shows null because the configIds array isn't being requested properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3778) downloadStatus page in plugin installer isn't grabbing correct configIds array
[ https://issues.apache.org/jira/browse/GERONIMO-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joseph Leong updated GERONIMO-3778: --- Patch Info: [Patch Available] downloadStatus page in plugin installer isn't grabbing correct configIds array -- Key: GERONIMO-3778 URL: https://issues.apache.org/jira/browse/GERONIMO-3778 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: console Affects Versions: 2.1 Environment: Ubuntu 7.10, Firefox 2.0.0.6 Reporter: Joseph Leong Assignee: Joseph Leong Priority: Minor Fix For: 2.1 Attachments: GERONIMO-3778.patch On the downloadStatus page of the plugin installer, the list of plugins to install shows null because the configIds array isn't being requested properly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-3779) Server assembly is not respecting version specified in pom
Server assembly is not respecting version specified in pom -- Key: GERONIMO-3779 URL: https://issues.apache.org/jira/browse/GERONIMO-3779 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem Affects Versions: 2.1 Reporter: David Jencks Assignee: David Jencks Priority: Blocker Fix For: 2.1 I noticed that if I get geronimo-jsp_2.1_spec-1.0.1-SNAPSHOT into my local repo it shows up in the server instead of the 1.0 version specified in the (root) pom. Apparently filtering the local maven repo to show only stuff specified in the pom is not working correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Trunk might break for a little while
On Jan 23, 2008, at 9:17 AM, Jarek Gawor wrote: Jason, Some modules there were moved from applications/ directory use org.apache.geronimo.applications as groupId and some use org.apache.geronimo.plugins. Should we use org.apache.geronimo.plugins for all these apps to be consistent? Yes, I tried to look for them and change, but I think my regex for s/r was bad. The org.apache.geronimo.applications groupId should be changed to org.apache.geronimo.plugins. --jason
Re: [AsyncHttpClient] data collection instrumentation
The executor created in the EventDispatcher is a daemon thread pool (that's why I added DaemonThreadFactory), so it will go away cleanly without cleanup. Thanks, Sangjin On Jan 23, 2008 6:54 AM, Rick McGuire [EMAIL PROTECTED] wrote: The changes you made look really nice. I think my only concern is whether the Executor used by the EventDispatcher needs to be cleaned up at some point. If it gets finalized appropriately and doesn't leave dangling threads, then I guess I'm ok with it. Rick Sangjin Lee wrote: I took a look at the patch on GERONIMO-3761, and it looks great. Thanks. I have modified your patch for several things, though, and I'm nearly ready to add it to the JIRA report. Comments about the changes... - I rewrote the EventQueue class to use an Executor. Since the Executor implementation provided by the JDK is basically a thread pool associated with a task queue, it provides an identical functionality to what was in EventQueue. I think that it is good to use the constructs from java.util.concurrent.* whenever it makes sense, and I believe this is one of them. - This change also enables us to remove synchronized from notifyMonitoringListener(). The notify method will be called very often and concurrently, and reducing the lock contention will be important. Using an Executor makes it possible to eliminate synchronization, at least at that level. - I associated a shared thread pool (Executor) for all dispatchers. I think it is desirable for dispatchers to share this thread pool rather than each instance of dispatchers creating and maintaining its own thread. - Renamed EventQueue to EventDispatcher. - I also moved the monitoring listener list to EventDispatcher. I also used CopyOnWriteArrayList as the implementation for the list. CopyOnWriteArrayList is an ideal choice for this as it is thread safe and lock-free. Also, our use case is heavy read-access but very infrequent write-access, which CopyOnWriteArrayList is suitable for. - I moved the connection_failed notification to before the getSession() call. The getSession() call here always throws an exception (by design), and thus notification needs to be done before calling getSession(). - I rewrote the CountingMonitor to use AtomicIntegers. This should be slightly safer. - I changed the timestamp calls from System.currentTimeMillis() to System.nanoTime()/100. The nanoTime() call is more high-res, as currentTimeMillis() may be tens of milliseconds accurate on some platforms, and thus not suitable for these measurements. I also have some more follow-up questions, which I'll post soon. Thanks, Sangjin On Jan 17, 2008 10:51 AM, Sangjin Lee [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: I like your idea of using the event listener as the main way of doing this. Basically no or multiple listeners would be invoked on a different thread when events occur. The event listener APIs would define those key methods which would contain all the necessary information about the events in an immutable fashion. We could provide a simple adapter that is no op so people can override necessary methods easily. Also, we could provide one implementation which is a counting listener that does the basic metrics collection. What do you think? Thanks, Sangjin On Jan 17, 2008 2:58 AM, Rick McGuire [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Thunderbird is playing very strange games with me this morning, somehow deleting the original post. Anyway, here are my comments on this. I'd like to propose changes to enable some basic stat collection and/or instrumentation to have visibility into performance of AHC. For a given *AsyncHttpClient*, one might want to know metrics like - total request count - total success count - total exception count - total timeout count - connection attempt count - connection failure count - connect time average - connection close count - average response time (as measured from the invocation time to having the response ready) - and others? Collection of metric information would, I think, be a good thing. However, I think we should separate the consolidation of the information from the collection. That is, the client should just have different types of events for data collection, and the event listener would be responsible for presenting the information appropriately. For example, to create the list above, I'd see the following set of events needed: - request
Re: Offline Deployer leaving behind temporary files
I have found the culprit. It is the URLs that we use to read content from
an archive, for e.g., META-INF/application.xml from an ear file. The
deployer is creating a JarFile and closing the JarFile after the deployment
operation is completed. JarFile.close() closes all the InputStreams
obtained from the JarFile and releases any locks.
For e.g., in EARConfigBuilder.getEarPlan(), we have code like the following:
URL applicationXmlUrl = DeploymentUtil.createJarURL(earFile,
META-INF/application.xml);
specDD = DeploymentUtil.readAll(applicationXmlUrl);
After this code is executed the earFile is locked until the JVM terminates.
If you replace the above with something similar to
InputStream inp = earFile.getInputStream(earFile.getJarEntry
(META-INF/application.xml));
BufferedReader br = new BufferedReader(new InputStreamReader(inp));
String line;
while((line = br.readLine()) != null) {
specDD += line;
}
the earFile is no longer locked once earFile.close() is called and can be
deleted anytime. This is what is observed on Win XP.
++Vamsi
On Jan 23, 2008 8:52 PM, Kevan Miller [EMAIL PROTECTED] wrote:
On Jan 23, 2008, at 10:02 AM, Vamsavardhana Reddy wrote:
Kevan,
I am testing this with an ear file. So, the EARConfiBuilder should
be reading this file. I guess it is the same with other builders as
well. The JarFileClassLoader has the following comment
* Note: This implementation currently does not work reliably on
windows, since the jar URL handler included with the Sun JavaVM
* holds a read lock on the JarFile, and this lock is not released
when the jar url is dereferenced. To fix this a
* replacement for the jar url handler must be written.
BTW, I am running G 2.0.3-SNAPSHOT on Win XP.
I wouldn't trust that comment. Dain's commit was addressing this very
problem (at least within the server runtime:
http://svn.apache.org/viewvc?view=revrevision=399522
You need to check to see what type of ClassLoader is being used. If
it's not JarFileClassLoader, then we understand the problem. If it is
JarFileClassLoader, then maybe we aren't calling destroy. If we doing
all of these things, then obviously I'm wrong again... ;-)
--kevan
[jira] Commented: (GERONIMO-3757) KeyStore type can't be changed
[ https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561773#action_12561773 ] Vasily Zakharov commented on GERONIMO-3757: --- Vamsavardhana, I've tested the patch, it seems to work fine. The only problem I see with it is with keystores that I put to var/security/keystores directory manually, as files. Those keystores are visible through the Keystore portlet, but when I try to unlock them, NullPointerException occurs as the keystore type is null. I'm not sure if those keystores should be visible at all, as keystore type for them is unknown - probably it would be wiser to hide them and ignore them, unless they're properly described in configs. KeyStore type can't be changed -- Key: GERONIMO-3757 URL: https://issues.apache.org/jira/browse/GERONIMO-3757 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.0.x, 2.1 Reporter: Vasily Zakharov Attachments: Geronimo-3757.patch, GERONIMO-3757.patch For now (r612905), Geronimo is hardcoded to use JKS keystore type, which prevents Geronimo from running on Harmony or other JDKs that have no JKS implementation: org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635: KeyStore tempKeystore = KeyStore.getInstance(JKS); org.apache.geronimo.security.keystore.FileKeystoreManager, line 364: KeyStore keystore = KeyStore.getInstance(FileKeystoreInstance.JKS); To workaround this issue, one can change JKS to KeyStore.getDefaultType() (this returns BKS for Harmony) or particular other keystore type, but this requires source recompilation. Replacing var/security/keystores/geronimo-default with the proper keystore type file is not a problem. A proper solution seems to apply the fix above to use the JDK-default keystore type, and provide FileKeystoreInstance with an additional configuration option, keystoreType, that would allow to change the keystore type through config.xml without recompilation, like this: module name=org.apache.geronimo.configs/server-security-config/2.0.2/car gbean name=geronimo-default attribute name=keystoreTypePKCS12/attribute attribute name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute /gbean /module This issue if a follow up to GERONIMO-2015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMODEVTOOLS-272) Description of core feature confusing
Description of core feature confusing
-
Key: GERONIMODEVTOOLS-272
URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-272
Project: Geronimo-Devtools
Issue Type: Improvement
Components: eclipse-plugin
Affects Versions: 2.0.0, 2.0.2, 2.0.x, 2.1.0, 2.1.x
Reporter: Ted Kirby
Assignee: Tim McConnell
When you install the eclipse plugin with the eclipse update manager, you get a
choice of Geronimo WTP Server Adapters:
Geronimo Core Feature,
and a series of versioned server adapters of the form:
Geronimo vX.X Server Adapter
When you click on them, they all have the same descripton:
This feature provides the WTP Server Adapter and additional development tools
for the Apache Geronimo server.
This text might be customized to include the version number, or changed to:
This feature provides the WTP Server Adapter and additional development tools
for {color:red}this specific version of the{color} Apache Geronimo server.
For the core feature, however, the text is quite misleading. Installing it
does not give you any working server adapter. So, it's description should be
changed to something like:
This feature provides core support required for the WTP Server Adapter for
specific versions of the Apache Geronimo server.
It would be nice if the core feature did not show up at all in the list to
install. It is included by those version-specific real server adapters that
need it.
Also, not sure what these additional development tools are, or where the user
finds out about them, but they can probably be removed from the core feature,
if that feature itself can't be removed from the install list.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-272) Description of core feature confusing
[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Kirby updated GERONIMODEVTOOLS-272:
---
Attachment: GD-272.patch
this patch changes the wording of the core feature to:
This feature provides core support required for the WTP Server Adapter for
specific versions of the Apache Geronimo server.
Description of core feature confusing
-
Key: GERONIMODEVTOOLS-272
URL:
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-272
Project: Geronimo-Devtools
Issue Type: Improvement
Components: eclipse-plugin
Affects Versions: 2.0.0, 2.0.2, 2.0.x, 2.1.0, 2.1.x
Reporter: Ted Kirby
Assignee: Tim McConnell
Attachments: GD-272.patch
When you install the eclipse plugin with the eclipse update manager, you get
a choice of Geronimo WTP Server Adapters:
Geronimo Core Feature,
and a series of versioned server adapters of the form:
Geronimo vX.X Server Adapter
When you click on them, they all have the same descripton:
This feature provides the WTP Server Adapter and additional development
tools for the Apache Geronimo server.
This text might be customized to include the version number, or changed to:
This feature provides the WTP Server Adapter and additional development
tools for {color:red}this specific version of the{color} Apache Geronimo
server.
For the core feature, however, the text is quite misleading. Installing it
does not give you any working server adapter. So, it's description should be
changed to something like:
This feature provides core support required for the WTP Server Adapter for
specific versions of the Apache Geronimo server.
It would be nice if the core feature did not show up at all in the list to
install. It is included by those version-specific real server adapters that
need it.
Also, not sure what these additional development tools are, or where the
user finds out about them, but they can probably be removed from the core
feature, if that feature itself can't be removed from the install list.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3677) Add support for cli options for host/port and user/pass for commands
[ https://issues.apache.org/jira/browse/GERONIMO-3677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GERONIMO-3677. -- Resolution: Fixed Add support for cli options for host/port and user/pass for commands Key: GERONIMO-3677 URL: https://issues.apache.org/jira/browse/GERONIMO-3677 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 2.1 Reporter: Jason Dillon Assignee: Jason Dillon Priority: Blocker Fix For: 2.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-2996) Car modules should have explicit dependencies
[ https://issues.apache.org/jira/browse/GERONIMO-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon reassigned GERONIMO-2996: -- Assignee: David Jencks (was: Jason Dillon) I think you've implemented this right? If so can you please close this puppy? Car modules should have explicit dependencies - Key: GERONIMO-2996 URL: https://issues.apache.org/jira/browse/GERONIMO-2996 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: car-maven-plugin Reporter: Jason Dillon Assignee: David Jencks When building car files currently, the enclosing maven pom is inspected for dependencies, which can sometimes lead to unwanted dependencies being included. Also as a side effect we have to overload the meaning of _scope_ to alter the behavior when setting up the configuration modules plan. By making the list of dependencies to be included in the plan explicit, the plugin becomes simpler, faster and with predictable behavior wrt what dependencies will be included. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3771) Move maven-plugins/* to buildsupport/* and update groupId to org.apache.geronimo.buildsupport
[ https://issues.apache.org/jira/browse/GERONIMO-3771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GERONIMO-3771. -- Resolution: Fixed Move maven-plugins/* to buildsupport/* and update groupId to org.apache.geronimo.buildsupport - Key: GERONIMO-3771 URL: https://issues.apache.org/jira/browse/GERONIMO-3771 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Affects Versions: 2.1 Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 2.1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [AsyncHttpClient] data collection instrumentation
On Jan 23, 2008 6:50 AM, Rick McGuire [EMAIL PROTECTED] wrote: Only if it can be done without having to maintain the same sort of request-to-start time map that you don't wish to do with the listener. The process of adding data collection should cause memory bloat there either, particularly if monitoring is not being used (the more likely case). It seems more reasonable that this type of processing should be pushed into the monitoring implementation rather than have the async client try to keep track of everything. This way, the overhead is only introduced while metrics are being gathered. A very simple and relatively low cost means might be to add a couple of time stamp fields to the request object, but only for the most significant events. Perhaps request start and connection start, but nothing else. Another possible approach would be to have a mechanism that would allow the monitor to attach an annotation object to the request that could be used to implement a lifecycle memory if needed. The cost of doing this is relatively minor when this type of information is not needed, but it's flexible enough to be tailored to any type of data collection. I agree, the only things that make sense to be present are request start time and connect start time... I'm going to upload a revised patch that shows this along with a proof-of-concept monitor that uses this to compute the average response time. Thanks, Sangjin
[jira] Closed: (GERONIMO-2996) Car modules should have explicit dependencies
[ https://issues.apache.org/jira/browse/GERONIMO-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-2996. -- Resolution: Fixed Fix Version/s: 2.1 This got implemented some time ago. Car modules should have explicit dependencies - Key: GERONIMO-2996 URL: https://issues.apache.org/jira/browse/GERONIMO-2996 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: car-maven-plugin Reporter: Jason Dillon Assignee: David Jencks Fix For: 2.1 When building car files currently, the enclosing maven pom is inspected for dependencies, which can sometimes lead to unwanted dependencies being included. Also as a side effect we have to overload the meaning of _scope_ to alter the behavior when setting up the configuration modules plan. By making the list of dependencies to be included in the plan explicit, the plugin becomes simpler, faster and with predictable behavior wrt what dependencies will be included. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3761) Add data collection and instrumentation to the AsyncHttpClient
[ https://issues.apache.org/jira/browse/GERONIMO-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated GERONIMO-3761: -- Attachment: GERONIMO-3761-v3.patch A suggestion for adding request start time and connect start time. The main difference from the previous one is on HttpRequestMessage and AsyncHttpClient. Add data collection and instrumentation to the AsyncHttpClient -- Key: GERONIMO-3761 URL: https://issues.apache.org/jira/browse/GERONIMO-3761 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Reporter: Rick McGuire Attachments: GERONIMO-3761-v2.patch, GERONIMO-3761-v3.patch, GERONIMO-3761.patch There's been some discussion on the dev list about adding some instrumentation to the AsyncHttpClient. This is for tracking these additions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3761) Add data collection and instrumentation to the AsyncHttpClient
[ https://issues.apache.org/jira/browse/GERONIMO-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sangjin Lee updated GERONIMO-3761: -- Attachment: TimeMonitor.java A proof of concept for measuring average response time. For simplicity, it provides only averages, and a single long variable accumulates response times. But one could easily extend it to maintain a list to compute means, averages, std deviation, etc... Add data collection and instrumentation to the AsyncHttpClient -- Key: GERONIMO-3761 URL: https://issues.apache.org/jira/browse/GERONIMO-3761 Project: Geronimo Issue Type: New Feature Security Level: public(Regular issues) Components: AsyncHttpClient Reporter: Rick McGuire Attachments: GERONIMO-3761-v2.patch, GERONIMO-3761-v3.patch, GERONIMO-3761.patch, TimeMonitor.java There's been some discussion on the dev list about adding some instrumentation to the AsyncHttpClient. This is for tracking these additions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3451) Restricted listeners property file not found error logged during Tomcat server startup
[ https://issues.apache.org/jira/browse/GERONIMO-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh reassigned GERONIMO-3451: --- Assignee: Jay D. McHugh Restricted listeners property file not found error logged during Tomcat server startup Key: GERONIMO-3451 URL: https://issues.apache.org/jira/browse/GERONIMO-3451 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.x Reporter: Kevan Miller Assignee: Jay D. McHugh Fix For: 2.0.x During Tomcat server startup, the following log error is displayed on the console: 12:57:32,559 ERROR [[/]] Restricted listeners property file not found Althgough the log message can be ignored, users assume that something is broken... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Assigned: (GERONIMO-3451) Restricted listeners property file not found error logged during Tomcat server startup
Hello all. I have a new private snapshot of Tomcat ready to be checked into Geronimo trunk. But G 2.0.x is using Tomcat 6.0.13 (trunk is using 6.0.14). Does anyone have an objection to upgrading G 2.0.x to use Tomcat 6.0.14? Jay Jay D. McHugh (JIRA) wrote: [ https://issues.apache.org/jira/browse/GERONIMO-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh reassigned GERONIMO-3451: --- Assignee: Jay D. McHugh Restricted listeners property file not found error logged during Tomcat server startup Key: GERONIMO-3451 URL: https://issues.apache.org/jira/browse/GERONIMO-3451 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.x Reporter: Kevan Miller Assignee: Jay D. McHugh Fix For: 2.0.x During Tomcat server startup, the following log error is displayed on the console: 12:57:32,559 ERROR [[/]] Restricted listeners property file not found Althgough the log message can be ignored, users assume that something is broken...
Spec development/release process documentation
The specs tree seems to be in a mess with stuff in branches and waay too much stuff in trunk, and many trunk poms having a xxx-SNAPSHOT version where the latest tag is xxx. I've attempted to document our previous decisions on spec development and release in specs/branches/README: WARNING DO NOT DEVELOP ANY SPECS UNDER BRANCHES OR COPY ANY VERSIONS INTO BRANCHES ALL DEVELOPMENT MUST TAKE PLACE UNDER TRUNK ANY CODE UNDER BRANCHES IS AN ERROR AND SHOULD BE CLEANED UP AS SOON AS POSSIBLE and specs/trunk/README.txt: Structure Only specs under active development should be in trunk. Once you release, delete the trunk. If you need to make a change or bugfix, copy the latest tag into trunk and work with that. Be certain that all dependencies are marked provided Do not copy any code into branches under any circumstances. Building The is normally no root pom, so you need to build specs individually. To build you will need: * J2SE SDK 1.5+ (http://java.sun.com/j2se/1.4.2) * Maven 2.0.7+ (http://maven.apache.org) To build all changes incrementally: mvn install To perform clean builds, which are sometimes needed after some changes to the source tree: mvn clean install Releasing = Use the maven-release-plugin. Stage to your people.apache.org account or to your local machine and scp to people.apache.org. After a release vote has passed use the maven-stage-plugin to transfer the voted artifacts to the apache release repo. --- Please review, fix, and if you think this isn't what we agreed on complain. thanks david jencks
Re: Retire unused modules?
On Jan 23, 2008 10:02 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: I would move what we hope someone else to pick up into the sandbox. Everything else can get trashed. I'd go even further - move everything to be retired to sandbox/retired and let people work on it if/when they can benefit from it. Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Updated: (GERONIMO-3764) DeployerReaper fails to cleanup the temp directories left behind by deployer
[ https://issues.apache.org/jira/browse/GERONIMO-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vamsavardhana Reddy updated GERONIMO-3764: -- Attachment: GERONIMO-3764-deploymentutil.patch GERONIMO-3764-deploymentutil.patch: The reason for archive files getting locked is that some of the code uses URLs to extract content from the archive, for e.g., application.xml from an ear file. See http://marc.info/?l=geronimo-devm=120111383903434w=2 . We will need to update DeploymentUtil and the attached patch gives an idea on what should be done. The drawback is that we may end up with more temp files (but these will be deletable as soon as the deployment operation completes) and deleteOnExit may be called only if delete fails on these files. Comments? Suggestions? Help!!! DeployerReaper fails to cleanup the temp directories left behind by deployer Key: GERONIMO-3764 URL: https://issues.apache.org/jira/browse/GERONIMO-3764 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0.1, 2.0.2, 2.0.x, 2.1 Reporter: Vamsavardhana Reddy Assignee: Vamsavardhana Reddy Fix For: 2.0.x, 2.1 Attachments: GERONIMO-3764-2.0.patch, GERONIMO-3764-deploymentutil.patch Deployer creates a temporary directory and cleans up the directory once deployment operation is completed. When deletion of a temp dir fails, the deployer leaves it upto DeployerReaper to cleanup the directory later on. DeployerReaper is failing to cleanup these directories as only the dir name (not the complete path) is available to it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (XBEAN-77) ClassFinder needs better error handling
[ https://issues.apache.org/jira/browse/XBEAN-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Cabrera updated XBEAN-77: -- Fix Version/s: (was: 3.1) 3.4 ClassFinder needs better error handling --- Key: XBEAN-77 URL: https://issues.apache.org/jira/browse/XBEAN-77 Project: XBean Issue Type: Bug Affects Versions: 3.0 Reporter: David Jencks Fix For: 3.4 ClassFinder uses e.printStackTrace() as an error reporting mechanism. This needs to be fixed somehow. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (XBEAN-92) UrlSet excludePaths() method throws a nullpointer exception if the pathString argument is null
[
https://issues.apache.org/jira/browse/XBEAN-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Cabrera updated XBEAN-92:
--
Fix Version/s: 3.4
UrlSet excludePaths() method throws a nullpointer exception if the pathString
argument is null
--
Key: XBEAN-92
URL: https://issues.apache.org/jira/browse/XBEAN-92
Project: XBean
Issue Type: Bug
Environment: IBM JDK 5
Reporter: karan singh malhi
Assignee: David Blevins
Priority: Blocker
Fix For: 3.4
With IBM JDK 5, when we try to get the system property java.endorsed.dirs, it
returns null. This is a critical issue as it prevents OpenEjb from starting
In UrlSet, the following method will lead to a NullPointerException:
public UrlSet excludeJavaEndorsedDirs() throws MalformedURLException {
return excludePaths(System.getProperty(java.endorsed.dirs));
}
This is because the excludePaths() method assumes that the pathString
argument is always non-null.
public UrlSet excludePaths(String pathString) throws MalformedURLException
{
String[] paths = pathString.split(File.pathSeparator);
UrlSet urlSet = this;
for (String path : paths) {
File file = new File(path);
urlSet = urlSet.exclude(file);
}
return urlSet;
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3776) WebResourcePermission.getName() is not always the string URLPatternSpec is based on, making it impossible to find out the meaning of the permission except through implie
[ https://issues.apache.org/jira/browse/GERONIMO-3776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks closed GERONIMO-3776. -- Resolution: Fixed rev 614698, used in geronimo. releasing the spec jar will happen during 2.1 release cycle. WebResourcePermission.getName() is not always the string URLPatternSpec is based on, making it impossible to find out the meaning of the permission except through implies. --- Key: GERONIMO-3776 URL: https://issues.apache.org/jira/browse/GERONIMO-3776 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: specs Affects Versions: 2.0.x, 2.1 Reporter: David Jencks Assignee: David Jencks Priority: Blocker Fix For: 2.1 Attachments: GERONIMO-3776.diff getName() should return the same string as is used for the URLPatternSpec. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
XML schemas documentation for 2.1
Howdy, I'm working on documenting the deployment plans for 2.1, part of that documentation includes covering the XML schemas. While looking at the schemas I see attributes-1.1.xsd and attributes-1.2.xsd although I haven't found any reference to attributes-1.1. Are we still using this schema? Cheers! Hernan
XML schemas documentation for 2.1
Howdy, I'm working on documenting the deployment plans for 2.1, part of that documentation includes covering the XML schemas. While looking at the schemas I see attributes-1.1.xsd and attributes-1.2.xsd although I haven't found any reference to attributes-1.1. Are we still using this schema? Cheers! Hernan
[BUILD] 2.1: Failed for Revision: 614643
Geronimo Revision: 614643 built with tests included See the full build-1500.log file at http://geronimo.apache.org/maven/server/binaries/trunk/20080123/build-1500.log Download the binaries from http://geronimo.apache.org/maven/server/binaries/trunk/20080123 [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 29 minutes 25 seconds [INFO] Finished at: Wed Jan 23 15:43:32 EST 2008 [INFO] Final Memory: 309M/998M [INFO] TESTSUITE RESULTS (Failures only) = See detailed results at http://geronimo.apache.org/maven/server/testsuite/ResultsSummary.html Assembly: tomcat = See the full test.log file at http://geronimo.apache.org/maven/server/binaries/trunk/20080123/logs-1500-tomcat/test.log Assembly: jetty = See the full test.log file at http://geronimo.apache.org/maven/server/binaries/trunk/20080123/logs-1500-jetty/test.log [INFO] Running console-testsuite.advance-test [INFO] Tests run: 13, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 62.771 sec FAILURE!
Re: XML schemas documentation for 2.1
Hey Hernan, We should not be using 1.1 anymore. If you -had- found somewhere that it was being used, then that would have been a problem. The 1.2 version is where comment support was added to the config.xml file. Jay Hernan Cunico wrote: Howdy, I'm working on documenting the deployment plans for 2.1, part of that documentation includes covering the XML schemas. While looking at the schemas I see attributes-1.1.xsd and attributes-1.2.xsd although I haven't found any reference to attributes-1.1. Are we still using this schema? Cheers! Hernan
Re: XML schemas documentation for 2.1
My thunderbird just crashed and I lost all 2008 mails. I thought this one didn't make it, cool it still hit the list. I'm using rev #612130 and the binaries include a schema/attributes-1.1.xsd I'll skip documenting attributes-1.1.xsd but somebody should remove it from the build if we no longer use it. I would do it myself but don't where this one is coming from. Do we need a JIRA for this? Cheers! Hernan Jay D. McHugh wrote: Hey Hernan, We should not be using 1.1 anymore. If you -had- found somewhere that it was being used, then that would have been a problem. The 1.2 version is where comment support was added to the config.xml file. Jay Hernan Cunico wrote: Howdy, I'm working on documenting the deployment plans for 2.1, part of that documentation includes covering the XML schemas. While looking at the schemas I see attributes-1.1.xsd and attributes-1.2.xsd although I haven't found any reference to attributes-1.1. Are we still using this schema? Cheers! Hernan
[jira] Commented: (GERONIMO-3757) KeyStore type can't be changed
[ https://issues.apache.org/jira/browse/GERONIMO-3757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561855#action_12561855 ] Vasily Zakharov commented on GERONIMO-3757: --- Another idea maybe to add the idea of default keystore type - for now, for each gbean needing access to a keystore we have to specify it's type in the configs (and in more than one place), but we could inctroduce a default to use when keystore type is not specifed. KeyStore.getDefaultType() looks like a resonable default for that case. KeyStore type can't be changed -- Key: GERONIMO-3757 URL: https://issues.apache.org/jira/browse/GERONIMO-3757 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: security Affects Versions: 2.0.2, 2.0.x, 2.1 Reporter: Vasily Zakharov Attachments: Geronimo-3757.patch, GERONIMO-3757.patch For now (r612905), Geronimo is hardcoded to use JKS keystore type, which prevents Geronimo from running on Harmony or other JDKs that have no JKS implementation: org.apache.geronimo.security.keystore.FileKeystoreInstance, line 635: KeyStore tempKeystore = KeyStore.getInstance(JKS); org.apache.geronimo.security.keystore.FileKeystoreManager, line 364: KeyStore keystore = KeyStore.getInstance(FileKeystoreInstance.JKS); To workaround this issue, one can change JKS to KeyStore.getDefaultType() (this returns BKS for Harmony) or particular other keystore type, but this requires source recompilation. Replacing var/security/keystores/geronimo-default with the proper keystore type file is not a problem. A proper solution seems to apply the fix above to use the JDK-default keystore type, and provide FileKeystoreInstance with an additional configuration option, keystoreType, that would allow to change the keystore type through config.xml without recompilation, like this: module name=org.apache.geronimo.configs/server-security-config/2.0.2/car gbean name=geronimo-default attribute name=keystoreTypePKCS12/attribute attribute name=keystorePathvar/security/keystores/geronimo-pkcs12/attribute /gbean /module This issue if a follow up to GERONIMO-2015. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: XML schemas documentation for 2.1
Don't think we need a JIRA. I'll go ahead and get rid of the old version. It is still in use for Geronimo 2.0.x (and older). Jay Hernan Cunico wrote: My thunderbird just crashed and I lost all 2008 mails. I thought this one didn't make it, cool it still hit the list. I'm using rev #612130 and the binaries include a schema/attributes-1.1.xsd I'll skip documenting attributes-1.1.xsd but somebody should remove it from the build if we no longer use it. I would do it myself but don't where this one is coming from. Do we need a JIRA for this? Cheers! Hernan Jay D. McHugh wrote: Hey Hernan, We should not be using 1.1 anymore. If you -had- found somewhere that it was being used, then that would have been a problem. The 1.2 version is where comment support was added to the config.xml file. Jay Hernan Cunico wrote: Howdy, I'm working on documenting the deployment plans for 2.1, part of that documentation includes covering the XML schemas. While looking at the schemas I see attributes-1.1.xsd and attributes-1.2.xsd although I haven't found any reference to attributes-1.1. Are we still using this schema? Cheers! Hernan
[jira] Commented: (GERONIMO-3451) Restricted listeners property file not found error logged during Tomcat server startup
[ https://issues.apache.org/jira/browse/GERONIMO-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561891#action_12561891 ] Jay D. McHugh commented on GERONIMO-3451: - Resolved this issue on trunk with a new version of tomcat private snapshot including the latest security patch and djencks patch for the restricted listener fix. Sendingpom.xml Adding repository/org/apache/tomcat/6.0.14-G614585.README.TXT Adding repository/org/apache/tomcat/catalina/6.0.14-G614585 Adding (bin) repository/org/apache/tomcat/catalina/6.0.14-G614585/catalina-6.0.14-G614585.jar Adding repository/org/apache/tomcat/jasper/6.0.14-G614585 Adding (bin) repository/org/apache/tomcat/jasper/6.0.14-G614585/jasper-6.0.14-G614585.jar Transmitting file data Committed revision 614754. Restricted listeners property file not found error logged during Tomcat server startup Key: GERONIMO-3451 URL: https://issues.apache.org/jira/browse/GERONIMO-3451 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.x Reporter: Kevan Miller Assignee: Jay D. McHugh Fix For: 2.0.x During Tomcat server startup, the following log error is displayed on the console: 12:57:32,559 ERROR [[/]] Restricted listeners property file not found Althgough the log message can be ignored, users assume that something is broken... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3451) Restricted listeners property file not found error logged during Tomcat server startup
[ https://issues.apache.org/jira/browse/GERONIMO-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-3451. - Resolution: Fixed Fix Version/s: 2.1 Restricted listeners property file not found error logged during Tomcat server startup Key: GERONIMO-3451 URL: https://issues.apache.org/jira/browse/GERONIMO-3451 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.x Reporter: Kevan Miller Assignee: Jay D. McHugh Fix For: 2.0.x, 2.1 During Tomcat server startup, the following log error is displayed on the console: 12:57:32,559 ERROR [[/]] Restricted listeners property file not found Althgough the log message can be ignored, users assume that something is broken... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (GERONIMO-3451) Restricted listeners property file not found error logged during Tomcat server startup
[ https://issues.apache.org/jira/browse/GERONIMO-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561895#action_12561895 ] Jay D. McHugh commented on GERONIMO-3451: - Checked into branches/2.0 also: Sendingpom.xml Adding repository/org/apache/tomcat/catalina/6.0.14-G614585 Adding (bin) repository/org/apache/tomcat/catalina/6.0.14-G614585/catalina-6.0.14-G614585.jar Adding repository/org/apache/tomcat/jasper/6.0.14-G614585 Adding (bin) repository/org/apache/tomcat/jasper/6.0.14-G614585/jasper-6.0.14-G614585.jar Transmitting file data ... Committed revision 614758. Restricted listeners property file not found error logged during Tomcat server startup Key: GERONIMO-3451 URL: https://issues.apache.org/jira/browse/GERONIMO-3451 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.x Reporter: Kevan Miller Assignee: Jay D. McHugh Fix For: 2.0.x, 2.1 During Tomcat server startup, the following log error is displayed on the console: 12:57:32,559 ERROR [[/]] Restricted listeners property file not found Althgough the log message can be ignored, users assume that something is broken... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3451) Restricted listeners property file not found error logged during Tomcat server startup
[ https://issues.apache.org/jira/browse/GERONIMO-3451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh closed GERONIMO-3451. --- Restricted listeners property file not found error logged during Tomcat server startup Key: GERONIMO-3451 URL: https://issues.apache.org/jira/browse/GERONIMO-3451 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: Tomcat Affects Versions: 2.0, 2.0.x Reporter: Kevan Miller Assignee: Jay D. McHugh Fix For: 2.0.x, 2.1 During Tomcat server startup, the following log error is displayed on the console: 12:57:32,559 ERROR [[/]] Restricted listeners property file not found Althgough the log message can be ignored, users assume that something is broken... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-3549) Potential vulnerability in Apache Tomcat Webdav servlet
[
https://issues.apache.org/jira/browse/GERONIMO-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jay D. McHugh reassigned GERONIMO-3549:
---
Assignee: Jay D. McHugh
Potential vulnerability in Apache Tomcat Webdav servlet
---
Key: GERONIMO-3549
URL: https://issues.apache.org/jira/browse/GERONIMO-3549
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Tomcat
Affects Versions: 1.1.1, 1.2, 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1
Reporter: Donald Woods
Assignee: Jay D. McHugh
Fix For: 2.0.x, 2.1
Subject: [SECURITY] Potential vulnerability in Apache Tomcat Webdav
servlet
Date: Thu, 18 Oct 2007 13:40:24 -0400
From: Kevan Miller [EMAIL PROTECTED]
Reply-To: dev@geronimo.apache.org
To: Geronimo Dev dev@geronimo.apache.org
The Geronimo project has learned of a security vulnerability in the
Apache Tomcat Webdav Servlet implementation. If you use a Tomcat
configuration of Geronimo and configure a write-enabled Webdav servlet,
you may be affected by this vulnerability. If you do not configure the
Webdav servlet or configure read-only Webdav servlets, you are not
impacted by this vulnerability. Jetty configurations of Geronimo are not
affected by this vulnerability.
This vulnerability impacts all Geronimo releases. Up to and including
Geronimo 2.0.2.
For specific information regarding the Tomcat issue, see
http://mail-archives.apache.org/mod_mbox/tomcat-users/200710.mbox/[EMAIL
PROTECTED]
By default, Geronimo releases do not use the Webdav servlet. However, it
is possible for the Webdav Servlet to be configured or referenced by a
user-written application.
The Webdav Servlet could be explicitly configured in a web.xml
http://web.xml/ deployment descriptor as follows:
...
servlet
servlet-namewebdav/servlet-name
servlet-classorg.apache.catalina.servlets.WebdavServlet/servlet-class
init-param
param-namereadonly/param-name
param-valuefalse/param-value
/init-param
/servlet
Alternatively, a user's application could extend the WebdavServlet, for
example:
import org.apache.catalina.servlets.WebdavServlet;
public class MyServlet extends WebdavServlet {
...
If you configure a write-enabled Webdav servlet, we recommend that you:
- Disable write access to the Webdav Servlet until this problem has
been fixed, or
- Limit access to the Webdav servlet to only trusted users.
This vulnerability will be fixed in the next release of Geronimo (2.0.3
and/or 2.1).
--kevan
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3549) Potential vulnerability in Apache Tomcat Webdav servlet
[
https://issues.apache.org/jira/browse/GERONIMO-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jay D. McHugh resolved GERONIMO-3549.
-
Resolution: Fixed
Commits for Geronimo-3451 ('restricted listeners') also include necessary
security fixes for this issue.
Potential vulnerability in Apache Tomcat Webdav servlet
---
Key: GERONIMO-3549
URL: https://issues.apache.org/jira/browse/GERONIMO-3549
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Tomcat
Affects Versions: 1.1.1, 1.2, 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1
Reporter: Donald Woods
Assignee: Jay D. McHugh
Fix For: 2.0.x, 2.1
Subject: [SECURITY] Potential vulnerability in Apache Tomcat Webdav
servlet
Date: Thu, 18 Oct 2007 13:40:24 -0400
From: Kevan Miller [EMAIL PROTECTED]
Reply-To: dev@geronimo.apache.org
To: Geronimo Dev dev@geronimo.apache.org
The Geronimo project has learned of a security vulnerability in the
Apache Tomcat Webdav Servlet implementation. If you use a Tomcat
configuration of Geronimo and configure a write-enabled Webdav servlet,
you may be affected by this vulnerability. If you do not configure the
Webdav servlet or configure read-only Webdav servlets, you are not
impacted by this vulnerability. Jetty configurations of Geronimo are not
affected by this vulnerability.
This vulnerability impacts all Geronimo releases. Up to and including
Geronimo 2.0.2.
For specific information regarding the Tomcat issue, see
http://mail-archives.apache.org/mod_mbox/tomcat-users/200710.mbox/[EMAIL
PROTECTED]
By default, Geronimo releases do not use the Webdav servlet. However, it
is possible for the Webdav Servlet to be configured or referenced by a
user-written application.
The Webdav Servlet could be explicitly configured in a web.xml
http://web.xml/ deployment descriptor as follows:
...
servlet
servlet-namewebdav/servlet-name
servlet-classorg.apache.catalina.servlets.WebdavServlet/servlet-class
init-param
param-namereadonly/param-name
param-valuefalse/param-value
/init-param
/servlet
Alternatively, a user's application could extend the WebdavServlet, for
example:
import org.apache.catalina.servlets.WebdavServlet;
public class MyServlet extends WebdavServlet {
...
If you configure a write-enabled Webdav servlet, we recommend that you:
- Disable write access to the Webdav Servlet until this problem has
been fixed, or
- Limit access to the Webdav servlet to only trusted users.
This vulnerability will be fixed in the next release of Geronimo (2.0.3
and/or 2.1).
--kevan
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3549) Potential vulnerability in Apache Tomcat Webdav servlet
[
https://issues.apache.org/jira/browse/GERONIMO-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jay D. McHugh closed GERONIMO-3549.
---
Potential vulnerability in Apache Tomcat Webdav servlet
---
Key: GERONIMO-3549
URL: https://issues.apache.org/jira/browse/GERONIMO-3549
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: Tomcat
Affects Versions: 1.1.1, 1.2, 2.0, 2.0.1, 2.0.2, 2.0.x, 2.1
Reporter: Donald Woods
Assignee: Jay D. McHugh
Fix For: 2.0.x, 2.1
Subject: [SECURITY] Potential vulnerability in Apache Tomcat Webdav
servlet
Date: Thu, 18 Oct 2007 13:40:24 -0400
From: Kevan Miller [EMAIL PROTECTED]
Reply-To: dev@geronimo.apache.org
To: Geronimo Dev dev@geronimo.apache.org
The Geronimo project has learned of a security vulnerability in the
Apache Tomcat Webdav Servlet implementation. If you use a Tomcat
configuration of Geronimo and configure a write-enabled Webdav servlet,
you may be affected by this vulnerability. If you do not configure the
Webdav servlet or configure read-only Webdav servlets, you are not
impacted by this vulnerability. Jetty configurations of Geronimo are not
affected by this vulnerability.
This vulnerability impacts all Geronimo releases. Up to and including
Geronimo 2.0.2.
For specific information regarding the Tomcat issue, see
http://mail-archives.apache.org/mod_mbox/tomcat-users/200710.mbox/[EMAIL
PROTECTED]
By default, Geronimo releases do not use the Webdav servlet. However, it
is possible for the Webdav Servlet to be configured or referenced by a
user-written application.
The Webdav Servlet could be explicitly configured in a web.xml
http://web.xml/ deployment descriptor as follows:
...
servlet
servlet-namewebdav/servlet-name
servlet-classorg.apache.catalina.servlets.WebdavServlet/servlet-class
init-param
param-namereadonly/param-name
param-valuefalse/param-value
/init-param
/servlet
Alternatively, a user's application could extend the WebdavServlet, for
example:
import org.apache.catalina.servlets.WebdavServlet;
public class MyServlet extends WebdavServlet {
...
If you configure a write-enabled Webdav servlet, we recommend that you:
- Disable write access to the Webdav Servlet until this problem has
been fixed, or
- Limit access to the Webdav servlet to only trusted users.
This vulnerability will be fixed in the next release of Geronimo (2.0.3
and/or 2.1).
--kevan
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMO-3450) Unable to Run Pluto 1.1 on Geronimo 2.0
[ https://issues.apache.org/jira/browse/GERONIMO-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh resolved GERONIMO-3450. - Resolution: Invalid See Ramesh's comment. Unable to Run Pluto 1.1 on Geronimo 2.0 --- Key: GERONIMO-3450 URL: https://issues.apache.org/jira/browse/GERONIMO-3450 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M2 Environment: Operating System : Windows 2k3 Pluto Version: 1.1.0 Geronimo with Jetty Version 2.0.1 Reporter: Ramesh B Fix For: 2.0.x, 2.1 Attachments: geronimo-web.xml, geronimo.log Hi, I'm new to geronimo webserver. I've been trying to deploy pluto 1.1 on geronimo with jetty 2.0.1. For this I have done the following steps: 1) I've added the following additional jars to common libs before deployment: * pluto-container-1.1.0.jar * pluto-descriptor-api-1.1.0.jar * pluto-descriptor-impl-1.1.0.jar * pluto-taglib-1.1.0.jar * xalan 2.6.0 2) I've modified the castor.properties for pluto/web-inf/classes and set all parameters to false. 3) i've added a geronimo-web.xml to the /web-inf folder. I created a war of the pluto folder. however while deploying it it gives the following error: 3582: 11:02:34,501 ERROR [log] Nested in org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/pluto-portal-driver-services-config.xml]; nested exception is java.lang.IllegalArgumentException: Class [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the NamespaceHandler interface: After throwing this error on the console it shows as successfully deployed and successfully running. However when i'm trying to access the pluto portal, it says service unavailable. Please help me with this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-3450) Unable to Run Pluto 1.1 on Geronimo 2.0
[ https://issues.apache.org/jira/browse/GERONIMO-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jay D. McHugh closed GERONIMO-3450. --- Unable to Run Pluto 1.1 on Geronimo 2.0 --- Key: GERONIMO-3450 URL: https://issues.apache.org/jira/browse/GERONIMO-3450 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: deployment Affects Versions: 2.0-M2 Environment: Operating System : Windows 2k3 Pluto Version: 1.1.0 Geronimo with Jetty Version 2.0.1 Reporter: Ramesh B Fix For: 2.0.x, 2.1 Attachments: geronimo-web.xml, geronimo.log Hi, I'm new to geronimo webserver. I've been trying to deploy pluto 1.1 on geronimo with jetty 2.0.1. For this I have done the following steps: 1) I've added the following additional jars to common libs before deployment: * pluto-container-1.1.0.jar * pluto-descriptor-api-1.1.0.jar * pluto-descriptor-impl-1.1.0.jar * pluto-taglib-1.1.0.jar * xalan 2.6.0 2) I've modified the castor.properties for pluto/web-inf/classes and set all parameters to false. 3) i've added a geronimo-web.xml to the /web-inf folder. I created a war of the pluto folder. however while deploying it it gives the following error: 3582: 11:02:34,501 ERROR [log] Nested in org.springframework.beans.factory.BeanDefinitionStoreException: Unexpected exception parsing XML document from ServletContext resource [/WEB-INF/pluto-portal-driver-services-config.xml]; nested exception is java.lang.IllegalArgumentException: Class [org.apache.cxf.clustering.spring.NamespaceHandler] does not implement the NamespaceHandler interface: After throwing this error on the console it shows as successfully deployed and successfully running. However when i'm trying to access the pluto portal, it says service unavailable. Please help me with this problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r614754 - in /geronimo/server/trunk: ./ repository/org/apache/tomcat/ repository/org/apache/tomcat/catalina/6.0.14-G614585/ repository/org/apache/tomcat/jasper/6.0.14-G614585/
Jay, Did you miss the new patch file when you checked this in? Actually, would it be possible to create just one patch file that includes all the changes in your tomcat source image and check that in? That way we only need to apply one patch to recreate the image and all of the revision #s would be consistent (and we could delete all of the 604245 items). Thanks, Joe [EMAIL PROTECTED] wrote: Author: jaydm Date: Wed Jan 23 16:31:35 2008 New Revision: 614754 URL: http://svn.apache.org/viewvc?rev=614754view=rev Log: GERONIMO-3451 - Use a new snapshot of tomcat Includes security fix for webdav as well as 'restricted listeners' message Added: geronimo/server/trunk/repository/org/apache/tomcat/6.0.14-G614585.README.TXT geronimo/server/trunk/repository/org/apache/tomcat/catalina/6.0.14-G614585/ geronimo/server/trunk/repository/org/apache/tomcat/catalina/6.0.14-G614585/catalina-6.0.14-G614585.jar (with props) geronimo/server/trunk/repository/org/apache/tomcat/jasper/6.0.14-G614585/ geronimo/server/trunk/repository/org/apache/tomcat/jasper/6.0.14-G614585/jasper-6.0.14-G614585.jar (with props) Modified: geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?rev=614754r1=614753r2=614754view=diff == --- geronimo/server/trunk/pom.xml (original) +++ geronimo/server/trunk/pom.xml Wed Jan 23 16:31:35 2008 @@ -984,7 +984,7 @@ dependency groupIdorg.apache.tomcat/groupId artifactIdjasper/artifactId -version6.0.14-G604245/version +version6.0.14-G614585/version /dependency dependency @@ -1014,7 +1014,7 @@ dependency groupIdorg.apache.tomcat/groupId artifactIdcatalina/artifactId -version6.0.14-G604245/version +version6.0.14-G614585/version /dependency dependency @@ -1950,7 +1950,7 @@ dependency groupIdorg.apache.tomcat/groupId artifactIdjasper/artifactId -version6.0.14-G604245/version +version6.0.14-G614585/version /dependency /dependencies /plugin Added: geronimo/server/trunk/repository/org/apache/tomcat/6.0.14-G614585.README.TXT URL: http://svn.apache.org/viewvc/geronimo/server/trunk/repository/org/apache/tomcat/6.0.14-G614585.README.TXT?rev=614754view=auto == --- geronimo/server/trunk/repository/org/apache/tomcat/6.0.14-G614585.README.TXT (added) +++ geronimo/server/trunk/repository/org/apache/tomcat/6.0.14-G614585.README.TXT Wed Jan 23 16:31:35 2008 @@ -0,0 +1,87 @@ +Private Build of Tomcat for Geronimo. + +How to build Tomcat 6_0_14 with modifications for Geronimo: + +Checkout tomcat 6.0.14 + svn co https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_14 tomcat_6_0_14 + +svn info for Tomcat image: +Path: . +URL: https://svn.apache.org/repos/asf/tomcat/tc6.0.x/tags/TOMCAT_6_0_14 +Repository Root: https://svn.apache.org/repos/asf +Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68 +Revision: 604245 +Node Kind: directory +Schedule: normal +Last Changed Author: remm +Last Changed Rev: 557842 +Last Changed Date: 2007-07-19 21:43:38 -0400 (Thu, 19 Jul 2007) +Properties Last Updated: 2007-12-07 14:29:52 -0500 (Fri, 07 Dec 2007) + + +Apply the custom patch for Geronimo Annotation changes, Webdav fix, and build fix. + cd tomcat_6_0_14 + patch -p0 -u tomcat_6_0_14-G604245.patch (checked in as a peer to this file) + - Respond y to the 3 prompts Reversed (or previously applied) patch detected! Assume -R? [n] + +Force delete these three files + svn delete java/org/apache/jasper/runtime/AnnotationHelper.java --force + svn delete java/org/apache/AnnotationProcessor.java --force + svn delete java/org/apache/catalina/util/DefaultAnnotationProcessor.java --force + +Apply the 'restricted listeners' patch provided by djencks (already merged into Tomcat trunk) + patch -p0 -u tomcat_6_0_14-G614585.patch (cheked in as a peer to this file) + +Build tomcat + cd tomcat_6_0_14 + Per tomcat build instructions install ant-1.6.5 or later and set ANT_HOME as well as add ant/bin to PATH + You must run as the super user for the first build that downloads more ant eclipse artifacts + ant download - to setup build for tomcat + Exit super user + ant - to build tomcat artifacts + +Copy to appropriate jars and rename into geronimo/repository + cd tomcat_6_0_14 + cp output/build/lib/catalina.jar geronimo-root/repository/org/apache/tomcat/catalina/6.0.14-G614585/catalina-6.0.14-G614585.jar + cp
install-plugin option does not seem to be working
Hi All, I just checked out the latest trunk and am having trouble using the install-plugin option. Here is the stack trace 22:27:02,812 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/openejb/2.1-SNAPSHOT/c ar?configurationName=org.apache.geronimo.configs/openejb/2.1-SNAPSHOT/car org.apache.geronimo.kernel.repository.MissingDependencyException: Missing dependency: org.apache.geronimo.configs/system-database/2.1-SNAPSHOT/car at org.apache.geronimo.kernel.config.ConfigurationResolver.resolve(ConfigurationResolver.java:113) at org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:405) at org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:322) at org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:267) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:948) 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.kernel.basic.BasicKernel.startGBean(BasicKernel.java:361) at org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:160) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:312) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:280) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:255) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:111) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:633) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:559) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:799) at org.apache.geronimo.system.plugin.PluginInstallerGBean$4.run(PluginInstallerGBean.java:730) 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:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) 22:27:02,828 ERROR [PluginInstallerGBean] Unable to install plugin. org.apache.geronimo.kernel.config.LifecycleException: load of org.apache.geronimo.configs/openejb/2.1-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:327) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:280) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfiguration(SimpleConfigurationManager.java:255) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfiguration(KernelConfigurationManager.java:111) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:633) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:559) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install(PluginInstallerGBean.java:799) at org.apache.geronimo.system.plugin.PluginInstallerGBean$4.run(PluginInstallerGBean.java:730) 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:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) Caused by: org.apache.geronimo.kernel.config.InvalidConfigException: Error starting configuration gbean org.apache.geronimo.configs/openejb/2.1-SNAPSHOT/car at
Re: Trunk might break for a little while
Hmm... it looks like commons-logging-1.0.4.jar is getting included in multiple places now: [EMAIL PROTECTED]:~/target find . -name *logging*.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/configs/activemq-ra/2.1-SNAPSHOT/activemq-ra-2.1-SNAPSHOT.car/rar/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/plancreator-console-tomcat/2.1-SNAPSHOT/plancreator-console-tomcat-2.1-SNAPSHOT.car/WEB-INF/lib/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/console-tomcat/2.1-SNAPSHOT/console-tomcat-2.1-SNAPSHOT.car/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/console-tomcat/2.1-SNAPSHOT/console-tomcat-2.1-SNAPSHOT.car/base-portlets.war/WEB-INF/lib/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/console-tomcat/2.1-SNAPSHOT/console-tomcat-2.1-SNAPSHOT.car/portal-driver.war/WEB-INF/lib/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/mconsole-tomcat/2.1-SNAPSHOT/mconsole-tomcat-2.1-SNAPSHOT.car/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/mconsole-tomcat/2.1-SNAPSHOT/mconsole-tomcat-2.1-SNAPSHOT.car/mconsole.war/WEB-INF/lib/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/activemq-console-tomcat/2.1-SNAPSHOT/activemq-console-tomcat-2.1-SNAPSHOT.car/WEB-INF/lib/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/agent/2.1-SNAPSHOT/agent-2.1-SNAPSHOT.car/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/plugin-console-tomcat/2.1-SNAPSHOT/plugin-console-tomcat-2.1-SNAPSHOT.car/WEB-INF/lib/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/sysdb-console-tomcat/2.1-SNAPSHOT/sysdb-console-tomcat-2.1-SNAPSHOT.car/WEB-INF/lib/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/lib/commons-logging-1.0.4.jar Jarek On Jan 23, 2008 1:03 PM, Jason Dillon [EMAIL PROTECTED] wrote: On Jan 23, 2008, at 9:17 AM, Jarek Gawor wrote: Jason, Some modules there were moved from applications/ directory use org.apache.geronimo.applications as groupId and some use org.apache.geronimo.plugins. Should we use org.apache.geronimo.plugins for all these apps to be consistent? Yes, I tried to look for them and change, but I think my regex for s/r was bad. The org.apache.geronimo.applications groupId should be changed to org.apache.geronimo.plugins. --jason
Re: Trunk might break for a little while
There were some odd compile problems for webapps which needed jcl. I'm not sure why. Any help to fix would be appriciated. Also had to ad xmlbeans in a few places too. --jason -Original Message- From: Jarek Gawor [EMAIL PROTECTED] Date: Wed, 23 Jan 2008 23:40:38 To:dev@geronimo.apache.org Subject: Re: Trunk might break for a little while Hmm... it looks like commons-logging-1.0.4.jar is getting included in multiple places now: [EMAIL PROTECTED]:~/target find . -name *logging*.jar ../geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/commons-logging/commons-logging-api/1.0.4/commons-logging-api-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/commons-logging/commons-logging/1.0.4/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/configs/activemq-ra/2.1-SNAPSHOT/activemq-ra-2.1-SNAPSHOT.car/rar/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/plancreator-console-tomcat/2.1-SNAPSHOT/plancreator-console-tomcat-2.1-SNAPSHOT.car/WEB-INF/lib/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/console-tomcat/2.1-SNAPSHOT/console-tomcat-2.1-SNAPSHOT.car/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/console-tomcat/2.1-SNAPSHOT/console-tomcat-2.1-SNAPSHOT.car/base-portlets.war/WEB-INF/lib/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/console-tomcat/2.1-SNAPSHOT/console-tomcat-2.1-SNAPSHOT.car/portal-driver.war/WEB-INF/lib/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/mconsole-tomcat/2.1-SNAPSHOT/mconsole-tomcat-2.1-SNAPSHOT.car/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/mconsole-tomcat/2.1-SNAPSHOT/mconsole-tomcat-2.1-SNAPSHOT.car/mconsole.war/WEB-INF/lib/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/activemq-console-tomcat/2.1-SNAPSHOT/activemq-console-tomcat-2.1-SNAPSHOT.car/WEB-INF/lib/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/agent/2.1-SNAPSHOT/agent-2.1-SNAPSHOT.car/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/plugin-console-tomcat/2.1-SNAPSHOT/plugin-console-tomcat-2.1-SNAPSHOT.car/WEB-INF/lib/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/repository/org/apache/geronimo/plugins/sysdb-console-tomcat/2.1-SNAPSHOT/sysdb-console-tomcat-2.1-SNAPSHOT.car/WEB-INF/lib/commons-logging-1.0.4.jar ./geronimo-tomcat6-javaee5-2.1-SNAPSHOT/lib/commons-logging-1.0.4.jar Jarek On Jan 23, 2008 1:03 PM, Jason Dillon [EMAIL PROTECTED] wrote: On Jan 23, 2008, at 9:17 AM, Jarek Gawor wrote: Jason, Some modules there were moved from applications/ directory use org.apache.geronimo.applications as groupId and some use org.apache.geronimo.plugins. Should we use org.apache.geronimo.plugins for all these apps to be consistent? Yes, I tried to look for them and change, but I think my regex for s/r was bad. The org.apache.geronimo.applications groupId should be changed to org.apache.geronimo.plugins. --jason
Re: install-plugin option does not seem to be working
I think the install-plugin command only works for single plugins and for some reason doesn't figure out what repository to look for dependencies in. Try list-plugins where you specify the repo you want to use. thanks david jencks On Jan 23, 2008, at 8:16 PM, Viet Nguyen wrote: Hi All, I just checked out the latest trunk and am having trouble using the install-plugin option. Here is the stack trace 22:27:02,812 ERROR [GBeanInstanceState] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.configs/openejb/2.1-SNAPSHOT/c ar?configurationName=org.apache.geronimo.configs/openejb/2.1- SNAPSHOT/car org.apache.geronimo.kernel.repository.MissingDependencyException: Missing dependency: org.apache.geronimo.configs/system-database/2.1-SNAPSHOT/car at org.apache.geronimo.kernel.config.ConfigurationResolver.resolve (ConfigurationResolver.java:113) at org.apache.geronimo.kernel.config.Configuration.buildClassPath (Configuration.java:405) at org.apache.geronimo.kernel.config.Configuration.createConfigurationCla sssLoader(Configuration.java:322) at org.apache.geronimo.kernel.config.Configuration.init (Configuration.java:267) at sun.reflect.NativeConstructorAccessorImpl.newInstance0 (Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance (NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance (DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance (Constructor.java:494) at org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance (GBeanInstance.java:948) 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.kernel.basic.BasicKernel.startGBean (BasicKernel.java:361) at org.apache.geronimo.kernel.config.KernelConfigurationManager.load (KernelConfigurationManager.java:160) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfi guration(SimpleConfigurationManager.java:312) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfi guration(SimpleConfigurationManager.java:280) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfi guration(SimpleConfigurationManager.java:255) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfi guration(KernelConfigurationManager.java:111) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install (PluginInstallerGBean.java:633) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install (PluginInstallerGBean.java:559) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install (PluginInstallerGBean.java:799) at org.apache.geronimo.system.plugin.PluginInstallerGBean $4.run(PluginInstallerGBean.java:730) 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:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) 22:27:02,828 ERROR [PluginInstallerGBean] Unable to install plugin. org.apache.geronimo.kernel.config.LifecycleException: load of org.apache.geronimo.configs/openejb/2.1-SNAPSHOT/car failed at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfi guration(SimpleConfigurationManager.java:327) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfi guration(SimpleConfigurationManager.java:280) at org.apache.geronimo.kernel.config.SimpleConfigurationManager.loadConfi guration(SimpleConfigurationManager.java:255) at org.apache.geronimo.kernel.config.KernelConfigurationManager.loadConfi guration(KernelConfigurationManager.java:111) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install (PluginInstallerGBean.java:633) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install (PluginInstallerGBean.java:559) at org.apache.geronimo.system.plugin.PluginInstallerGBean.install (PluginInstallerGBean.java:799) at org.apache.geronimo.system.plugin.PluginInstallerGBean $4.run(PluginInstallerGBean.java:730) 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
[jira] Commented: (GERONIMO-3778) downloadStatus page in plugin installer isn't grabbing correct configIds array
[
https://issues.apache.org/jira/browse/GERONIMO-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12561967#action_12561967
]
David Jencks commented on GERONIMO-3778:
Would you consider some code something like this, except working?
fmt:message key=car.downloadStatus.processing/
c:forEach var=configId items=${configIds}
br/configId
/c:forEach
This involves modifying the message string to remove {0} which is not a great
loss here. I'm not thrilled about string processing in a jsp. I played with
this for a few minutes but haven't gotten it to display anything yet.
Also I sometimes get a basic auth screen up just before the status screen and
can't run through the install plugins wizard more than once -- the second time
I see I had a problem! instead of the progress bar.
downloadStatus page in plugin installer isn't grabbing correct configIds array
--
Key: GERONIMO-3778
URL: https://issues.apache.org/jira/browse/GERONIMO-3778
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: console
Affects Versions: 2.1
Environment: Ubuntu 7.10, Firefox 2.0.0.6
Reporter: Joseph Leong
Assignee: Joseph Leong
Priority: Minor
Fix For: 2.1
Attachments: GERONIMO-3778.patch
On the downloadStatus page of the plugin installer, the list of plugins to
install shows null because the configIds array isn't being requested properly.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Retire unused modules?
On Jan 23, 2008, at 12:42 PM, Dain Sundstrom wrote: I think we have some modules that are no longer used by anyone and the developer has given up on them, and was wondering if we should retire them? Off the top of my head this is where we stand: Keep: xbean-classloader - Geronimo and others xbean-finder - OpenEJB xbean-naming - Geronimo xbean-reflect - Geronimo and OpenEJB xbean-spring - Lots of users xbean-telnet - I think Blevins is still work in progress xbean-classpath - Looks like useful stuff Retire: xbean-jaxb - we don't even build this xbean-osgi - I gave up on this xbean-kernel - I think Service Mix moved to OSGi and I gave up on developing a long time ago xbean-server - I gave up on this xbean-tiger - Contains a single class MBeanServerFactoryBean, which I don't think is used What do you think? Also, how do you think we should retire them? I'm thinking we just delete the modules, and if someone wants them back, we can just cp the directory revision to a new location. I would move what we hope someone else to pick up into the sandbox. Everything else can get trashed. Regards, Alan
