date:20081202




David Jencks wrote:
In order to get the build to work with my use of nexus I've added the 
trunk svn repo (server/trunk/repository) to the nexus repositories.


This makes me wonder if we should just set up a single repo in svn and 
put all our private builds there rather than having branch-specific 
repos.  Would this result in more or less or the same load on the svn 
server?


Seems that moving the artifacts out into a unique svn branch (from 
geronimo/server/trunk/repository to geronimo/private/repo) would 
increase the load, as now every server build would be hitting the svn 
repo for artifacts (instead of just the /samples or /plugins builds.)




I also wonder if our policy of patching apache projects and coming up 
with our own psuedo releases is really the best idea or if we should 
just copy their code over in svn and build it more directly.




I could go either way on this.  I would like to see us at least check-in 
a tar/zip of the source for the patched artifacts into a branch, to make 
it easier to reproduce patched builds if needed (and so end users can 
rebuild everything if needed or used the patched source in a debugger.)




I also discovered a couple of weeks back that the lack of poms in this 
repo was causing significant build delays while maven was looking 
everywhere it could think of for them so I added them when I could 
easily find them in the artifacts.  I think we should add them for the 
other artifacts as well.


Agree.



thanks
david jencks

[jira] Updated: (GERONIMO-4229) clarify use of GERONIMO_HOME vs. GERONIMO_BASE in shell scripts


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

Donald Woods updated GERONIMO-4229:
---

Fix Version/s: 2.2
   2.1.4
 Assignee: Jarek Gawor

Added fix versions and Jarek as the owner for now.
We need to resolve the server instance problem before we release 2.2 and 2.1.4.

 clarify use of GERONIMO_HOME vs. GERONIMO_BASE in shell scripts
 ---

 Key: GERONIMO-4229
 URL: https://issues.apache.org/jira/browse/GERONIMO-4229
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: startup/shutdown
Affects Versions: 2.1.1
 Environment: ALL
Reporter: Russell E Glaue
Assignee: Jarek Gawor
Priority: Minor
 Fix For: 2.1.4, 2.2

 Attachments: geronimo-shell-home-base-2.patch


 I was not seeing consistent usage in the shell scripts of the following:
  - GERONIMO_HOME
  - GERONIMO_BASE
  - org.apache.geronimo.base.dir
 In 4 of the scripts, GERONIMO_BASE was used where GERONIMO_HOME should have 
 been used, or GERONIMO_BASE should be used to complete the path to the temp 
 file, otherwise the GeronimoInstallationPath is used to complete the temp 
 file path.
 The attached patch corrects these.
 For more information, please see my thread on [EMAIL PROTECTED]
 Subject: GERONIMO_BASE vs. GERONIMO_HOME and org.apache.geronimo.base.dir
 And as an additional note, this patch resolves a few errors, but not these 
 two:
 (1)-
 Using GERONIMO_BASE:   /usr/local/geronimo/server1
 Using GERONIMO_HOME:   /usr/local/geronimo
 Using GERONIMO_TMPDIR: var/temp
 Using JRE_HOME:/usr/jdk1.5.0_07/jre
 10:45:33,914 ERROR [LocalAttributeManager] Caught exception 
 java.io.FileNotFoundException: 
 /usr/local/geronimo-jetty6-javaee5-2.1.1/var/config/config-substitutions.properties
  (No such file or directory) trying to open properties file 
 /usr/local/geronimo-jetty6-javaee5-2.1.1/var/config/config-substitutions.properties
 -
 Geronimo looks for the 'var/config/config-substitutions.properties' file 
 according to 'org.apache.geronimo.server.dir' variable.
 However the bin/geronimo.sh script only sets 
 -Dorg.apache.geronimo.base.dir=$GERONIMO_BASE
 But I do not see how org.apache.geronimo.base.dir is used inside Geronimo.
 To fix we would have to set the variable 
 -Dorg.apache.geronimo.server.dir=$GERONIMO_BASE too - but we cannot do that 
 if we want users to be able to supply the 
 -Dorg.apache.geronimo.server.name=relative_path variable outside of 
 bin/geronimo.sh in $GERONIMO_OPTS env var.
 -
 So I could not figure out a good way to address this error, unless we 
 overrided org.apache.geronimo.base.dir variable with whatever is in the 
 org.apache.geronimo.server.dir variable, then change Geronimo to look for the 
 configSubstitutionFile as 
 'org.apache.geronimo.base.dir/var/config/config-substitutions.properties'
 And it appears that Geronimo ignores org.apache.geronimo.base.dir in favor of 
 org.apache.geronimo.home.dir anyway, so removing the configured 
 org.apache.geronimo.base.dir property in bin/geronimo.sh does not seem to 
 hurt anything - at first test, at least, it works for me.
 Then we just always set org.apache.geronimo.base.dir = 
 org.apache.geronimo.server.dir
 -
 I would appreciate if someone shed light on the proper intended usage of the 
 org.apache.geronimo.base.dir property.
 -
 (2)-
 Using GERONIMO_BASE:   /usr/local/geronimo/server1
 Using GERONIMO_HOME:   /usr/local/geronimo
 Using GERONIMO_TMPDIR: var/temp
 Using JRE_HOME:/usr/jdk1.5.0_07/jre
 ...
 The java.io.tmpdir system property specifies a non-existent directory: 
 /usr/local/geronimo-jetty6-javaee5-2.1.2/var/temp
 -
 read: /usr/local/geronimo/bin/geronimo.sh
 #   GERONIMO_TMPDIR (Optional) Directory path location of temporary directory
 #   the JVM should use (java.io.tmpdir).
 #   Defaults to $GERONIMO_BASE/var/temp.
 if [ -z $GERONIMO_TMPDIR ] ; then
   # Define the java.io.tmpdir to use for Geronimo
   # A relative value will be resolved relative to each instance
   GERONIMO_TMPDIR=var/temp
 fi
 -
 This is incorrect documentation, as the error message illustrates.
 GERONIMO_TMPDIR does not default to $GERONIMO_BASE/var/temp
 Nor does it default to $GERONIMO_HOME/var/temp
 Instead: It defaults to Geronimo_install_directory/var/temp
 Or also org.apache.geronimo.server.dir/var/temp
 GERONIMO_TMPDIR should be set with $GERONIMO_BASE/var/temp
 Or also org.apache.geronimo.base.dir/var/temp to comply with the documentation
 -
 Setting GERONIMO_TMPDIR=$GERONIMO_BASE/var/temp in bin/geronimo.sh will 
 actually conflict with anyone using the 
 -Dorg.apache.geronimo.server.name=relative_path to run multiple instances 
 as documented in the geronimo

[jira] Commented: (GERONIMO-4415) monitoring console code needs improvement


[ 
https://issues.apache.org/jira/browse/GERONIMO-4415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652364#action_12652364
 ] 

Donald Woods commented on GERONIMO-4415:


We need to resolve this before we release 2.2, as we want users to change the 
default system pwd.

 monitoring console code needs improvement
 -

 Key: GERONIMO-4415
 URL: https://issues.apache.org/jira/browse/GERONIMO-4415
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: monitoring
Affects Versions: 2.2
Reporter: David Jencks
Assignee: David Jencks
 Fix For: 2.2


 The code quality in the monitoring console is not ideal.  There are oddities 
 such as static variables in stateless ejbs and a lot of code duplication for 
 generating the graph javascript.  In addition the monitoring console should 
 be using jpa rather than direct db access for easier maintenance.
 Whether the agent should be using jpa is certainly debatable, I don't plan to 
 change that right now.

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

Re: Move monitoring console out of server to plugins?


+1 to not include Monitoring in the default server assemblies for 2.2.

+0 for moving to geronimo/plugins, as leaving it in the server branch 
would be fine for now (wondering if we'll need a new version of the 
plugin for every major release, due to newer levels of OpenEJB and/or 
OpenJPA.)



-Donald


David Jencks wrote:
We've discussed at various times trying to make the server build more 
manageable by moving peripheral plugins out of the server/trunk/pluings 
into plugins/trunk


I'd like to start this by moving monitoring before 2.2.

Any objections?

We have a few options as far as including the console in actual server 
assemblies:


1. don't include it.
2. get the monitoring plugins to depend on say g 2.1.4 and include 
compatibility stuff so it also works on 2.2 when released

3. follow the following release process for 2.2:

a. release framework.  IMO this should include the maven plugins and 
framework assembly, but people argued when I suggested this svn 
organization before.

b. release plugins, at an appropriate rate, including monitoring
c. release the assemblies.

I'm happy with any of these approaches or probably any others someone 
comes up with but slightly prefer (1) or (3).


thanks
david jencks

[jira] Updated: (GERONIMO-4343) Tuscany Geronimo plugin bring up

2008-12-02 Thread ant elder (JIRA)


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

ant elder updated GERONIMO-4343:


Attachment: helloworld-jsf.diff

The helloworld-jsf.diff patch adds the start of a JSF sample which uses SCA in 
a JSF managed bean. Work in progress, it doesn't quite work yet

 Tuscany Geronimo plugin bring up
 

 Key: GERONIMO-4343
 URL: https://issues.apache.org/jira/browse/GERONIMO-4343
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
Reporter: ant elder
 Attachments: add-jms-sca-binding.diff, 
 addComponentContextLocator.diff, asm.diff, GeronimoServletHost1.diff, 
 GeronimoServletHost2.diff, helloworld-jsf.diff, helloworld-jsp.diff, 
 helloworld-jsp.war, helloworld-jsp2.diff, helloworld-service.diff, 
 helloworld-servlet.diff, helloworld-web.diff, 
 implementation-web-runtime.diff, tuscany-core-1.3.jar, 
 tuscany-xsd-dependency.diff, up-to-tuscany-1.4-snapshot.diff, 
 wsdlgen-depenency.diff


 JIRA to cover getting the Tuscany Geronimo Plugin working again with the 
 latest releases of Tuscany and Geronimo. 

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

[jira] Commented: (GSHELL-81) Depdendency on sun.* packages


[ 
https://issues.apache.org/jira/browse/GSHELL-81?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652369#action_12652369
 ] 

Jason Dillon commented on GSHELL-81:


Why was this reopened?

 Depdendency on sun.* packages
 -

 Key: GSHELL-81
 URL: https://issues.apache.org/jira/browse/GSHELL-81
 Project: GShell
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: Support - Marshal
Reporter: Guillaume Nodet
Assignee: Jason Dillon
 Fix For: 1.0-alpha-3


 It seems that GShell is currently unable to run without the sun.* packages in 
 the classloader.
 The reason is that it uses xstream advanced mode which make use of these 
 packages.
 If these packages are not on the classpath, xstream will default to the pure 
 java reflection provider which will cause exceptions like the following:
 {noformat}
 Caused by: com.thoughtworks.xstream.converters.ConversionException: Cannot 
 construct org.apache.geronimo.gshell.layout.model.CommandNode as it does not 
 have a no-args constructor
  Debugging information 
 message : Cannot construct 
 org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
 no-args constructor
 cause-exception : 
 com.thoughtworks.xstream.converters.reflection.ObjectAccessException
 cause-message   : Cannot construct 
 org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
 no-args constructor
 class   : org.apache.geronimo.gshell.layout.model.Layout
 required-type   : org.apache.geronimo.gshell.layout.model.CommandNode
 path: /layout/nodes/command
 ---
 {noformat}
 I'm not sure if this is a good idea or if we should support that pure java 
 mode...

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

Re: Status of server/trunk wrt any release?


There are some code and configuration changes to use the latest gshell.

--jason


On Dec 1, 2008, at 10:31 PM, Jarek Gawor wrote:


Jason,

Will the existing gshell commands need to be updated to work with the
latest gshell?

Jarek

On Fri, Nov 28, 2008 at 4:59 AM, Jason Dillon [EMAIL PROTECTED]  
wrote:
Is there any release planned for server/trunk soonerish?  I ask  
because I'm

about ready to release GShell 1.0-alpha-2, and I'd like to update
server/trunk to use its awesome goodness.  Anyone see any problems  
with

that?

--jason

Re: private repo in svn questions...


Donald Woods wrote:



David Jencks wrote:
In order to get the build to work with my use of nexus I've added the 
trunk svn repo (server/trunk/repository) to the nexus repositories.


This makes me wonder if we should just set up a single repo in svn and 
put all our private builds there rather than having branch-specific 
repos.  Would this result in more or less or the same load on the svn 
server?


Seems that moving the artifacts out into a unique svn branch (from 
geronimo/server/trunk/repository to geronimo/private/repo) would 
increase the load, as now every server build would be hitting the svn 
repo for artifacts (instead of just the /samples or /plugins builds.)


I think there is value in having all of the required elements for a G 
release in one svn branch.  It keeps everything together when we release 
in the tag.  How would we manage the artifacts if there were in a unique 
svn branch without the release process?  I know we don't exactly release 
these artifacts as the specified versions - but we implicitly release 
them when we create the Geronimo release.  Would they ever move to a tag 
if they were in a unique svn?






I also wonder if our policy of patching apache projects and coming up 
with our own psuedo releases is really the best idea or if we should 
just copy their code over in svn and build it more directly.




I could go either way on this.  I would like to see us at least check-in 
a tar/zip of the source for the patched artifacts into a branch, to make 
it easier to reproduce patched builds if needed (and so end users can 
rebuild everything if needed or used the patched source in a debugger.)


I guess the benefit of including all the code in our svn would be that a 
user could easily debug the code if necessary.  But I'm nervous that the 
changes might be difficult to track and migrate to newer releases 
without the patch (and an optional patch can be easily 
ignored/forgotten).  So I think I favor the process as it is today.  I 
think we really need to work harder to remove these private builds.






I also discovered a couple of weeks back that the lack of poms in this 
repo was causing significant build delays while maven was looking 
everywhere it could think of for them so I added them when I could 
easily find them in the artifacts.  I think we should add them for the 
other artifacts as well.


Agree.



thanks
david jencks

Re: Move monitoring console out of server to plugins?

Our track record on releasing independent plugins isn't very good.  It 
seems to add a lot of overhead and process for little value.


How about the following:
- Keep the monitoring console in the server svn branch
- Release the monitoring console plugin when the server is released 
(versioned to match the server).

- Remove the monitoring console from the javaee5 assemblies.

I know this doesn't provide the same degree of independence but it would 
ensure that the plugin is released regularly and we can always fork it 
to plugins/trunk if necessary to fix some critical issue if the need arises.


Joe


David Jencks wrote:
We've discussed at various times trying to make the server build more 
manageable by moving peripheral plugins out of the server/trunk/pluings 
into plugins/trunk


I'd like to start this by moving monitoring before 2.2.

Any objections?

We have a few options as far as including the console in actual server 
assemblies:


1. don't include it.
2. get the monitoring plugins to depend on say g 2.1.4 and include 
compatibility stuff so it also works on 2.2 when released

3. follow the following release process for 2.2:

a. release framework.  IMO this should include the maven plugins and 
framework assembly, but people argued when I suggested this svn 
organization before.

b. release plugins, at an appropriate rate, including monitoring
c. release the assemblies.

I'm happy with any of these approaches or probably any others someone 
comes up with but slightly prefer (1) or (3).


thanks
david jencks

Re: GERONIMO-4229



I agree

Joe

Donald Woods wrote:

If it is no longer used, then #1 sounds like the right approach.


-Donald


Jarek Gawor wrote:

Hi,

I was looking at GERONIMO-4229 today (please see the bug and my
comments for details). There is a remaining issue with the
GERONIMO_BASE property and what it does. The Java system property that
it sets is not used anywhere in the code and therefore that property
is useless.  I have a couple of ideas what we can do with it or how to
fix it:

1) Totally get rid off GERONIMO_BASE in the shell scripts. It doesn't
do anything right now anyway and it just confuses people. People that
want to use multiple server instances will need to pass
org.apache.geronimo.server.dir or org.apache.geronimo.server.name
property using the GERONIMO_OPTS env. property (as it is documented
today).

or

2) Keep GERONIMO_BASE but only pass org.apache.geronimo.server.dir
property (to the java process) if the user has set the GERONIMO_BASE
env. property explicitly. That is, do not set GERONIMO_BASE property
automatically within the script as it is done now. If it would be
automatically set, the org.apache.geronimo.server.name property
(passed via GERONIMO_OPTS) would always be ignored.

Thoughts?

Jarek

Re: GERONIMO-4229

2008-12-02 Thread Anita Kulshreshtha

comments inline...

--- On Mon, 12/1/08, Jarek Gawor [EMAIL PROTECTED] wrote:
From: Jarek Gawor [EMAIL PROTECTED]
Subject: GERONIMO-4229
To: Geronimo Dev dev@geronimo.apache.org
Date: Monday, December 1, 2008, 5:33 PM

Hi,

I was looking at GERONIMO-4229 today (please see the bug and my
comments for details). There is a remaining issue with the
GERONIMO_BASE property and what it does. The Java system property that
it sets is not used anywhere in the code and therefore that property
is useless.  I have a couple of ideas what we can do with it or how to
fix it:

1) Totally get rid off GERONIMO_BASE in the shell scripts. It doesn't
do anything right now anyway and it just confuses people. People that
want to use multiple server instances will need to pass
org.apache.geronimo.server.dir or
org.apache.geronimo.server.name
property using the GERONIMO_OPTS env. property (as it is documented
today).

+1 

Thanks
Anita

or

2) Keep GERONIMO_BASE but only pass org.apache.geronimo.server.dir
property (to the java process) if the user has set the GERONIMO_BASE
env. property explicitly. That is, do not set GERONIMO_BASE property
automatically within the script as it is done now. If it would be
automatically set, the org.apache.geronimo.server.name property
(passed via GERONIMO_OPTS) would always be ignored.

Thoughts?

Jarek

Re: Tuscany Geronimo integration and the SCA JEE spec

2008-12-02 Thread Kevan Miller

Hi JS,
Vamsi generated some doc --
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Installing+the+Tuscany+Plugin+for+Geronimo

Although it's not working for me, at the moment... Vamsi, do those
instructions work for you?

More comments below...

On Dec 1, 2008, at 12:40 PM, mobyjobs wrote:

I tried to install the plug in but seeing missing dependency message
(as

bellow), not sure what I have missed:

C:\geronimo-tomcat6-javaee5-2.1.3\bindeploy --user system --password
manager in
stall-plugin
i:\workspaces\workspaceGME\trunk\tuscanyPlugin\tuscany\tuscany-tomc
at\target\tuscany-tomcat-1.0-SNAPSHOT.car
Using GERONIMO_BASE: C:\geronimo-tomcat6-javaee5-2.1.3
Using GERONIMO_HOME: C:\geronimo-tomcat6-javaee5-2.1.3
Using GERONIMO_TMPDIR: c:\tmp
Using JRE_HOME:C:\Program Files\Java\jdk1.5.0_15\jre
Checking for status every 1000ms:
Installation FAILED: Configuration
org.apache.geronimo.plugins/tuscany-tomcat/1.0-SNAPSHOT/car is already
installed.
Missing dependency:
org.apache.geronimo.plugins/tuscany-tomcat/1.0-SNAPSHOT/car

I have checked I have all the dependency files in repository; Here
are the

steps I followed;

- Installed geronimo-tomcat6-javaee5-2.1.3-bin to c:\
- changed .m2\settings.xml filed to set repository in
geronimo-tomcat6-javaee5-2.1.3 as the default location: i.e.
localRepositoryc:/geronimo-tomcat6-javaee5- 2.1.3/repository/;

You should not be using the geronimo server's repository in this
manner -- it's not intended to be a generic maven repository. Just use
the default location for your local maven repository
(i.e. .m2\repository). Geronimo will copy the necessary artifacts into
the server's repository as needed.

Your server is confused because it's trying to install tuscany-tomcat,
but there are already artifacts in repository/org/apache/geronimo/
plugins/tuscany-tomcat directory.

- checkout out code for geronimo plug-in code from
https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/trunk/
- build the plug-in using 'mvn install' ; build was successful and
all the

files copied to repository.
3. Deploy plugin using the command g_install_dir\bin\deploy.bat
install-plugin tuscany tomcat\target\tuscany-tomcat-1.0-SNAPSHOT.car

After building, I'd use the admin console to install the plugin:
http://localhost:8080/console/portal/Applications/Plugins

Click Show Plugins in selected repository, select Geronimo ::
Tuscany Plugin for Geronimo Tomcat and click the install button
(scroll down to the bottom of the screen), then click install again.
This should installs the Tuscany plugin and dependencies into my 2.1.4-
SNAPSHOT server.

You'll also need the config.xml changes mentioned in
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Installing+the+Tuscany+Plugin+for+Geronimo

Even with these, things don't seem to be working. I can deploy the
sample jsp app, but it doesn't seem to be working... Hoping that Vamsi
can comment.

--kevan

Re: GERONIMO-4229


If it is no longer used, then #1 sounds like the right approach.


-Donald


Jarek Gawor wrote:

Hi,

I was looking at GERONIMO-4229 today (please see the bug and my
comments for details). There is a remaining issue with the
GERONIMO_BASE property and what it does. The Java system property that
it sets is not used anywhere in the code and therefore that property
is useless.  I have a couple of ideas what we can do with it or how to
fix it:

1) Totally get rid off GERONIMO_BASE in the shell scripts. It doesn't
do anything right now anyway and it just confuses people. People that
want to use multiple server instances will need to pass
org.apache.geronimo.server.dir or org.apache.geronimo.server.name
property using the GERONIMO_OPTS env. property (as it is documented
today).

or

2) Keep GERONIMO_BASE but only pass org.apache.geronimo.server.dir
property (to the java process) if the user has set the GERONIMO_BASE
env. property explicitly. That is, do not set GERONIMO_BASE property
automatically within the script as it is done now. If it would be
automatically set, the org.apache.geronimo.server.name property
(passed via GERONIMO_OPTS) would always be ignored.

Thoughts?

Jarek

[jira] Resolved: (GERONIMO-4436) The address of httpbinding port in the WSDL query is not updated

2008-12-02 Thread Jarek Gawor (JIRA)


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

Jarek Gawor resolved GERONIMO-4436.
---

   Resolution: Fixed
Fix Version/s: 2.2
   2.1.4
 Assignee: Jarek Gawor

Patch committed to trunk (revision 722502) and branches/2.1 (revision 722504). 
Thanks a lot again!


 The address of httpbinding port in the WSDL query is not updated
 

 Key: GERONIMO-4436
 URL: https://issues.apache.org/jira/browse/GERONIMO-4436
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: webservices
Affects Versions: 2.1.4, 2.2
 Environment: Windows XP
 JDK 1.5.0
Reporter: Ivan
Assignee: Jarek Gawor
Priority: Minor
 Fix For: 2.1.4, 2.2

 Attachments: Geronimo-4436.patch


 While querying the WSDL file, the address of httpbinding port is not updated 
 to the actual request url.

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

Re: private repo in svn questions...




Joe Bohn wrote:

Donald Woods wrote:



David Jencks wrote:
In order to get the build to work with my use of nexus I've added the 
trunk svn repo (server/trunk/repository) to the nexus repositories.


This makes me wonder if we should just set up a single repo in svn 
and put all our private builds there rather than having 
branch-specific repos.  Would this result in more or less or the same 
load on the svn server?


Seems that moving the artifacts out into a unique svn branch (from 
geronimo/server/trunk/repository to geronimo/private/repo) would 
increase the load, as now every server build would be hitting the svn 
repo for artifacts (instead of just the /samples or /plugins builds.)


I think there is value in having all of the required elements for a G 
release in one svn branch.  It keeps everything together when we release 
in the tag.  How would we manage the artifacts if there were in a unique 
svn branch without the release process?  I know we don't exactly release 
these artifacts as the specified versions - but we implicitly release 
them when we create the Geronimo release.  Would they ever move to a tag 
if they were in a unique svn?






I also wonder if our policy of patching apache projects and coming up 
with our own psuedo releases is really the best idea or if we should 
just copy their code over in svn and build it more directly.




I could go either way on this.  I would like to see us at least 
check-in a tar/zip of the source for the patched artifacts into a 
branch, to make it easier to reproduce patched builds if needed (and 
so end users can rebuild everything if needed or used the patched 
source in a debugger.)


I guess the benefit of including all the code in our svn would be that a 
user could easily debug the code if necessary.  But I'm nervous that the 
changes might be difficult to track and migrate to newer releases 
without the patch (and an optional patch can be easily 
ignored/forgotten).  So I think I favor the process as it is today.  I 
think we really need to work harder to remove these private builds.


I meant the patch file(s) + source tar/zip.  Having the patched source 
would help debug and patch future problems.








I also discovered a couple of weeks back that the lack of poms in 
this repo was causing significant build delays while maven was 
looking everywhere it could think of for them so I added them when I 
could easily find them in the artifacts.  I think we should add them 
for the other artifacts as well.


Agree.



thanks
david jencks

[jira] Commented: (GERONIMO-3316) warn but don't prevent deployment if an ear's manifest cps are messed up, and provide more info on where.

2008-12-02 Thread Jeff Lu (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-3316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652419#action_12652419
 ] 

Jeff Lu commented on GERONIMO-3316:
---

I will test it this week and let you know.  Thank you.

 warn but don't prevent deployment if an ear's manifest cps are messed up, and 
 provide more info on where.
 -

 Key: GERONIMO-3316
 URL: https://issues.apache.org/jira/browse/GERONIMO-3316
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: deployment
Affects Versions: 2.0-M6, 2.0-M7, 2.0, 2.0.1, 2.0.2, 2.0.3, 2.1, 2.1.1, 
 2.1.2, 2.1.3, 2.1.4, 2.2
Reporter: David Jencks
Assignee: Joe Bohn
 Fix For: 2.1.4, 2.2


 DeploymentContext.getCompleteManifestClassPath figures out the whole set of 
 jars in an ear in a modules classpath.  If somethings missing it throws an 
 exception and prevents deployment.  We need a switch to be more lenient, and 
 we need to provide more info when there's a problem on which jar has the 
 problem and how we found it.
 Thanks to David Harbige on the user list for pointing out that this is a big 
 usability problem.

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

Re: 2.2 (trunk) bucket-o-snapshots


Hi Jarek,

It looks like the Axis2 1.5 release didn't happen yet.  Is there a new 
target?


Also, my offer still stands to help with the concurrent spec release if 
you want.  Let me know.


Thanks,
Joe


Jarek Gawor wrote:

Axiom, XmlSchema, and Woden are all dependencies of Axis2. There is a
plan for Axis2 release at the end of this month but I'm not sure if
it's going to happen with all these dependencies. So getting Axis2
release might be an issue to us.

As to geronimo-concurrent_1.0_spec 1.0-SNAPSHOT, we can get that
released now. I have no pending updates for it.

Jarek

On Tue, Nov 11, 2008 at 6:04 PM, Joe Bohn [EMAIL PROTECTED] wrote:

It has been mentioned several times that we should be looking to release
Geronimo 2.2 before the end of the year (preferrably mid-December).


Before we can consider a release there are a large number of snapshots that
need to be removed/replaced in our project.  Can anybody shed any light on
these (or others that I may have missed)?


OpenEJB 3.1-SNAPSHOT  - Actually, OpenEJB 3.1 was released in late October.
 However, the trunk version was never updated and some additional changes
have been included.  Recent changes in Geronimo trunk now require this
snapshot that is actually newer than the 3.1 release. IMO we should revert
the trunk change and attempt to work with the released OpenEJB 3.1.

Axis2 SNAPSHOT (yep, it's just SNAPSHOT without a number).  IIUC correctly
we need to get an Axis2 release before we can consider a Geronimo 2.2
release.  Does anybody know how close we are to getting an Axis2 release?

Axiom SNAPSHOT (yep. it's just SNAPSHOT too).  I believe this is required by
Axis2 ... so if Axis2 is released then they will have to get Axiom released
as well (and we can pick up the released version).

-xBean 3.5-SNAPSHOT.  Is this snapshot really required (I presume it must
be)?  In branches/2.1 we're still using 3.3.  It looks like the latest
released version is 3.4.3.  I'll give that a shot if I don't hear from
anybody that we really need 3.5.

-wadi 2.1-SNAPSHOT.  Is this snapshot really required (I presume it must
be)?  In branches/2.1 we're using 2.0.  What function requires 2.1-SNAPSHOT
and is can somebody directly involved with wadi provide an estimate on when
this might be released?

-geronimo_j2ee-connector_1.6_spec 1.0-EA-SNAPSHOT.  Are we at a point where
we can release this spec or do we need to wait until we verify tck?

- geronimo-jaspi_1.0_spec 1.0-SNAPSHOT.  Are we at a point where we can
release this spec or do we need to wait until we verify tck?

- geronimo-servlet_3.0_spec 1.0-EA-SNAPSHOT.  Are we at a point where we can
release this spec or do we need to wait until we verify tck?

- geronimo-jaspi 1.0-SNAPSHOT.  This is a new geronimo component.  How close
is this to being able to be released?

- geronimo-concurrent_1.0_spec 1.0-SNAPSHOT.  How close is this to being
able to be released?

- XmlSchema SNAPSHOT (yep, it's just SNAPSHOT).  I believe this is also
related to Axis2 dependencies and will have to be resolved by Axis2 as they
release.

- woden* 1.0-SNAPSHOT.  This is also related to Axis2 and will have to be
resolved for an Axis2 release so we will pull in whatever they require.

- selenium-maven-plugin 1.0-rc-1-SNAPSHOT.  I believe that we pulled this in
trying to resolve the FF3 issues.  It's not clear to me if we would have to
remove this SNAPSHOT prior to a release but I think it would be best to
ensure that the tagged release can always be built and run with tests -
therefore I think we should remove it.  Any other opinions?

- jspc-maven-plugin 2.0-alpha-2-SNAPSHOT.  I'm not sure why this is updated
(in branches/2.1 we use 2.0-alpha-1-20070806).  Anybody know? We should
remove it.

- jspc-compiler-tomcat6 2.0-alpha-2-SNAPSHOT.  I'm not sure why this was
updated either.  In branches/2.1 we updated the maven plugin (above) but not
the compiler but in trunk both were updated to the alpha-2-SNAPSHOT.
 Anybody know why?

- ianal-maven-plugin  1.0-alpha-1-SNAPSHOT.  No doubt to support the new
legal file processing.  Is there a released version we can use instead of
the SNAPSHOT or do we need to get a release here are well?


Joe

xbean 3.5 release?


As many of you already know from the Geronimo dev list - we're looking to
release Geronimo 2.2 by mid January.  However, we need a number of snapshots
released prior to that and xBean trunk (3.5-SNAPSHOT) is among them for
xbean-finder, xbean-naming, and xbean-reflect.  Any possibility we could get
an xBean 3.5 release within the next few weeks?

Thanks,
Joe
-- 
View this message in context: 
http://www.nabble.com/xbean-3.5-release--tp20795885p20795885.html
Sent from the xbean-dev mailing list archive at Nabble.com.

[jira] Created: (GERONIMO-4437) Upgrade to Jetty 6.1.14

Upgrade to Jetty 6.1.14
---

 Key: GERONIMO-4437
 URL: https://issues.apache.org/jira/browse/GERONIMO-4437
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public (Regular issues)
  Components: dependencies, Jetty
Affects Versions: 2.2
Reporter: Donald Woods
Assignee: Donald Woods
 Fix For: 2.2


Jetty 6.1.14 was released on Nov 18.
There are several classes in the Geronimo Jetty integration that will need to 
be updated, due to org.mortbay.component.LifeCycle needing to be implemented in 
anything that implements/extends a Handler derived class.


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

Re: xbean 3.5 release?

2008-12-02 Thread Guillaume Nodet

Sounds good to me.

On Tue, Dec 2, 2008 at 6:12 PM, Joe Bohn [EMAIL PROTECTED] wrote:

 As many of you already know from the Geronimo dev list - we're looking to
 release Geronimo 2.2 by mid January.  However, we need a number of snapshots
 released prior to that and xBean trunk (3.5-SNAPSHOT) is among them for
 xbean-finder, xbean-naming, and xbean-reflect.  Any possibility we could get
 an xBean 3.5 release within the next few weeks?

 Thanks,
 Joe
 --
 View this message in context: 
 http://www.nabble.com/xbean-3.5-release--tp20795885p20795885.html
 Sent from the xbean-dev mailing list archive at Nabble.com.





-- 
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Open Source SOA
http://fusesource.com

[jira] Closed: (GERONIMO-4437) Upgrade to Jetty 6.1.14


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

Donald Woods closed GERONIMO-4437.
--

Resolution: Fixed

Rev722538 in trunk (2.2-SNAPSHOT)

 Upgrade to Jetty 6.1.14
 ---

 Key: GERONIMO-4437
 URL: https://issues.apache.org/jira/browse/GERONIMO-4437
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: dependencies, Jetty
Affects Versions: 2.2
Reporter: Donald Woods
Assignee: Donald Woods
 Fix For: 2.2


 Jetty 6.1.14 was released on Nov 18.
 There are several classes in the Geronimo Jetty integration that will need to 
 be updated, due to org.mortbay.component.LifeCycle needing to be implemented 
 in anything that implements/extends a Handler derived class.

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

Re: private repo in svn questions...

2008-12-02 Thread David Jencks



On Dec 2, 2008, at 5:41 AM, Donald Woods wrote:




David Jencks wrote:
In order to get the build to work with my use of nexus I've added  
the trunk svn repo (server/trunk/repository) to the nexus  
repositories.
This makes me wonder if we should just set up a single repo in svn  
and put all our private builds there rather than having branch- 
specific repos.  Would this result in more or less or the same load  
on the svn server?


Seems that moving the artifacts out into a unique svn branch (from  
geronimo/server/trunk/repository to geronimo/private/repo) would  
increase the load, as now every server build would be hitting the  
svn repo for artifacts (instead of just the /samples or /plugins  
builds.)


I don't understand your reasoning here.  Right now anyone working with  
any source version of geronimo such as trunk is going to check out the  
artifacts they need whether or not they have other copies on their  
local system and every time they do svn up they will be hitting the  
svn repo.  If they are in one svn location then maven will fetch them  
once per machine no matter how many branches and copies are checked  
out.  I don't know which results in more svn server load, but I can  
imagine that either choice is less load.


I may not have made it clear that if you use nexus you can't build  
geronimo at all unless you tell nexus where to get the artifacts that  
are in server/trunk/repository.  I first tried listing my local  
checkout as a file system repo but couldn't get that to work: using  
the svn repo did work.





I also wonder if our policy of patching apache projects and coming  
up with our own psuedo releases is really the best idea or if we  
should just copy their code over in svn and build it more directly.


I could go either way on this.  I would like to see us at least  
check-in a tar/zip of the source for the patched artifacts into a  
branch, to make it easier to reproduce patched builds if needed (and  
so end users can rebuild everything if needed or used the patched  
source in a debugger.)


I guess scenarios like this are strong arguments for distributed  
version control systems like svk and git.



I also discovered a couple of weeks back that the lack of poms in  
this repo was causing significant build delays while maven was  
looking everywhere it could think of for them so I added them when  
I could easily find them in the artifacts.  I think we should add  
them for the other artifacts as well.


Agree.


thanks
david jencks


thanks
david jencks

Re: private repo in svn questions...

I delete my local m2 repo at least once a week (usually when switching 
between 2.1.4 and 2.2 builds to ensure truly clean builds.)


Also, the automated 2.0/2.1/trunk builds that run several times a day 
always use a clean m2 repo.


Seems that we would be increasing the load on svn.apache.org just to 
make it easier for a few people who want to use Nexus




-Donald


David Jencks wrote:


On Dec 2, 2008, at 5:41 AM, Donald Woods wrote:




David Jencks wrote:
In order to get the build to work with my use of nexus I've added the 
trunk svn repo (server/trunk/repository) to the nexus repositories.
This makes me wonder if we should just set up a single repo in svn 
and put all our private builds there rather than having 
branch-specific repos.  Would this result in more or less or the same 
load on the svn server?


Seems that moving the artifacts out into a unique svn branch (from 
geronimo/server/trunk/repository to geronimo/private/repo) would 
increase the load, as now every server build would be hitting the svn 
repo for artifacts (instead of just the /samples or /plugins builds.)


I don't understand your reasoning here.  Right now anyone working with 
any source version of geronimo such as trunk is going to check out the 
artifacts they need whether or not they have other copies on their local 
system and every time they do svn up they will be hitting the svn repo.  
If they are in one svn location then maven will fetch them once per 
machine no matter how many branches and copies are checked out.  I don't 
know which results in more svn server load, but I can imagine that 
either choice is less load.


I may not have made it clear that if you use nexus you can't build 
geronimo at all unless you tell nexus where to get the artifacts that 
are in server/trunk/repository.  I first tried listing my local checkout 
as a file system repo but couldn't get that to work: using the svn repo 
did work.





I also wonder if our policy of patching apache projects and coming up 
with our own psuedo releases is really the best idea or if we should 
just copy their code over in svn and build it more directly.


I could go either way on this.  I would like to see us at least 
check-in a tar/zip of the source for the patched artifacts into a 
branch, to make it easier to reproduce patched builds if needed (and 
so end users can rebuild everything if needed or used the patched 
source in a debugger.)


I guess scenarios like this are strong arguments for distributed version 
control systems like svk and git.



I also discovered a couple of weeks back that the lack of poms in 
this repo was causing significant build delays while maven was 
looking everywhere it could think of for them so I added them when I 
could easily find them in the artifacts.  I think we should add them 
for the other artifacts as well.


Agree.


thanks
david jencks


thanks
david jencks

Re: Tuscany Geronimo integration and the SCA JEE spec

2008-12-02 Thread mobyjobs


Thanks for help. The issue with my setup turned out was wrong tuscany-core
version. I was using latest tuscany-core.1.4-SNAPSHOT.jar. As I thought the
fix in tuscany-core.1.3.jar submitted in the Jira was also applied to the
tuscany branch. But it looks like I needed to change version from
1.4-SNAPSHOT to 1.3 and then change tuscany-core.1.3.jar with the one in
Jira.

Now I am trying example and to see at least RIM and web bindings are working
(which is what I am looking for at this time).

-Jamil



Kevan Miller wrote:
 
 
 Hi JS,
 Vamsi generated some doc --
 http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Installing+the+Tuscany+Plugin+for+Geronimo
 
 Although it's not working for me, at the moment... Vamsi, do those  
 instructions work for you?
 
 More comments below...
 
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Tuscany-Geronimo-integration-and-the-SCA-JEE-spec-tp19794900s134p20798460.html
Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.

[jira] Created: (GERONIMODEVTOOLS-540) Prevent geronimo contamination from deployments from multiple workspaces

2008-12-02 Thread Francisco Peredo (JIRA)

Prevent geronimo contamination from deployments from multiple workspaces


 Key: GERONIMODEVTOOLS-540
 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-540
 Project: Geronimo-Devtools
  Issue Type: New Feature
  Components: eclipse-plugin
Reporter: Francisco Peredo
Assignee: Tim McConnell


When doing development of several independent applications over the Geronimo, 
that Geronimo installation gets contaminated by those applications

If I create workspaces1, and inside it I create dynamic webproject 1, and run 
it on Geronimo, then I switch to workspace2, and create dynamic webproject 2, 
and run it on Geronimo, since it is the same Geronimoinstance, both dynamic 
webproject 1 and dynamic webproject 2 will start (and there is no way, from 
inside eclipse to undeploy dynamic webproject 1 unless I go back to workspaces1 
and undeploy it.

But, if one is working with Tomcat, there is no problem, applications do not 
contaminate the shared Tomcat, why is that? well the Tomcat WTP Adapter has a 
configuration option enabled by default under Server Location, that reads: 
Use workspace metadata (does not modify Tomcat installation). I would like to 
have an option like that for Geronimo.

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

[jira] Commented: (GERONIMO-4295) Upgrade to Derby 10.4.2.0


[ 
https://issues.apache.org/jira/browse/GERONIMO-4295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652489#action_12652489
 ] 

Donald Woods commented on GERONIMO-4295:


Rev722599 in trunk (2.2-SNAPSHOT)

 Upgrade to Derby 10.4.2.0
 -

 Key: GERONIMO-4295
 URL: https://issues.apache.org/jira/browse/GERONIMO-4295
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: dependencies
Affects Versions: 2.0.3, 2.1.3, 2.2
Reporter: Donald Woods
Assignee: Donald Woods
Priority: Minor
 Fix For: 2.0.4, 2.1.4, 2.2


 Upgrade to Derby 10.4.2.0, which was released on Sept. 5, 2008.

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

[DISCUSS] DayTrader 2.1.3 release

I'm working on updating the daytrader/branches/2.1 for a 2.1.3 release 
(will rename it to branches/2.1.3 shortly.)  Once everything is ready, 
I'll put it up for a vote.


BTW - I'm not creating a branches/2.1 for on-going maintenance, as if it 
is ever needed, we can copy over the 2.1.3 tag to create it.  I'm just 
wanting to get this overdue Daytrader 2.1.x out so we can focus on the 
2.2 release.



-Donald

[jira] Created: (GERONIMO-4438) TransactionSynchronizationRegistry.getTransactionKey should return null when transaction is not associated with the current thread

2008-12-02 Thread Lin Sun (JIRA)

TransactionSynchronizationRegistry.getTransactionKey should return null when 
transaction is not associated with the current thread
--

 Key: GERONIMO-4438
 URL: https://issues.apache.org/jira/browse/GERONIMO-4438
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: transaction manager
Reporter: Lin Sun
Assignee: Lin Sun
Priority: Minor


per JTA 1.1 spec, the TransactionSynchronizationRegistry.getTransactionKey 
method should return null, if a transaction is not associated with the current 
thread.   The Geronimo transaction impl (v2.1.1) throws an 
IllegalStateException which is incorrect.

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

[jira] Created: (GERONIMO-4439) Add MTOM feature testing in the webservice testsuite

2008-12-02 Thread Ivan (JIRA)

Add MTOM feature testing in the webservice testsuite


 Key: GERONIMO-4439
 URL: https://issues.apache.org/jira/browse/GERONIMO-4439
 Project: Geronimo
  Issue Type: Test
  Security Level: public (Regular issues)
  Components: webservices
Affects Versions: 2.2
 Environment: Windows XP
JDK 1.5
Reporter: Ivan
Priority: Minor


I try to write some testcases about MTOM features in the webservice testsuite.
Please help to review it, and thanks for any comment !

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

[jira] Resolved: (GERONIMO-4438) TransactionSynchronizationRegistry.getTransactionKey should return null when transaction is not associated with the current thread

2008-12-02 Thread Lin Sun (JIRA)


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

Lin Sun resolved GERONIMO-4438.
---

   Resolution: Fixed
Fix Version/s: 2.2

fixed in txmanager 2.2-snapshot and 2.1.1 branch (see subversion commit).   
this behavior is documented in page 45 of the jta 1.1 spec.

 TransactionSynchronizationRegistry.getTransactionKey should return null when 
 transaction is not associated with the current thread
 --

 Key: GERONIMO-4438
 URL: https://issues.apache.org/jira/browse/GERONIMO-4438
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: transaction manager
Reporter: Lin Sun
Assignee: Lin Sun
Priority: Minor
 Fix For: 2.2


 per JTA 1.1 spec, the TransactionSynchronizationRegistry.getTransactionKey 
 method should return null, if a transaction is not associated with the 
 current thread.   The Geronimo transaction impl (v2.1.1) throws an 
 IllegalStateException which is incorrect.

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

Re: private repo in svn questions...

I think this could become reality if we have a geronimo/repository in  
svn, then have it automatically exported to our zone for access by  
builds.  I still don't think that accessing the svn tree directly from  
maven is a good idea.


--jason


On Dec 2, 2008, at 9:08 PM, Joe Bohn wrote:


Donald Woods wrote:

David Jencks wrote:
In order to get the build to work with my use of nexus I've added  
the trunk svn repo (server/trunk/repository) to the nexus  
repositories.


This makes me wonder if we should just set up a single repo in svn  
and put all our private builds there rather than having branch- 
specific repos.  Would this result in more or less or the same  
load on the svn server?
Seems that moving the artifacts out into a unique svn branch (from  
geronimo/server/trunk/repository to geronimo/private/repo) would  
increase the load, as now every server build would be hitting the  
svn repo for artifacts (instead of just the /samples or /plugins  
builds.)


I think there is value in having all of the required elements for a  
G release in one svn branch.  It keeps everything together when we  
release in the tag.  How would we manage the artifacts if there were  
in a unique svn branch without the release process?  I know we don't  
exactly release these artifacts as the specified versions - but we  
implicitly release them when we create the Geronimo release.  Would  
they ever move to a tag if they were in a unique svn?




I also wonder if our policy of patching apache projects and coming  
up with our own psuedo releases is really the best idea or if we  
should just copy their code over in svn and build it more directly.


I could go either way on this.  I would like to see us at least  
check-in a tar/zip of the source for the patched artifacts into a  
branch, to make it easier to reproduce patched builds if needed  
(and so end users can rebuild everything if needed or used the  
patched source in a debugger.)


I guess the benefit of including all the code in our svn would be  
that a user could easily debug the code if necessary.  But I'm  
nervous that the changes might be difficult to track and migrate to  
newer releases without the patch (and an optional patch can be  
easily ignored/forgotten).  So I think I favor the process as it is  
today.  I think we really need to work harder to remove these  
private builds.




I also discovered a couple of weeks back that the lack of poms in  
this repo was causing significant build delays while maven was  
looking everywhere it could think of for them so I added them when  
I could easily find them in the artifacts.  I think we should add  
them for the other artifacts as well.

Agree.


thanks
david jencks

Re: svn commit: r722725 - in /geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1.1/geronimo-transaction/src: main/java/org/apache/geronimo/transaction/manager/ test/java/org/apache/g


Hi Lin,

A few questions:

- Why modify branches/2.1.1?  I'm not sure, but it looks like this is an 
old branch that was subsequently copied to tags/2.1.1 (rather than moved 
to tags).
- Where is the new testTransactionKey() method used that was added here 
and in trunk?

- Is this something that we need to consider including with Geronimo 2.2?

Joe

[EMAIL PROTECTED] wrote:

Author: linsun
Date: Tue Dec  2 18:51:11 2008
New Revision: 722725

URL: http://svn.apache.org/viewvc?rev=722725view=rev
Log:
GERONIMO-4438 - TransactionSynchronizationRegistry.getTransactionKey should 
return null when transaction is not associated with the current thread

Modified:

geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1.1/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/TransactionManagerImpl.java

geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1.1/geronimo-transaction/src/test/java/org/apache/geronimo/transaction/manager/TransactionSynchronizationRegistryTest.java

Modified: 
geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1.1/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/TransactionManagerImpl.java
URL: 
http://svn.apache.org/viewvc/geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1.1/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/TransactionManagerImpl.java?rev=722725r1=722724r2=722725view=diff
==
--- 
geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1.1/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/TransactionManagerImpl.java
 (original)
+++ 
geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1.1/geronimo-transaction/src/main/java/org/apache/geronimo/transaction/manager/TransactionManagerImpl.java
 Tue Dec  2 18:51:11 2008
@@ -205,8 +205,8 @@
 }
 
 public Object getTransactionKey() {

-TransactionImpl tx = getActiveTransactionImpl();
-return tx.getTransactionKey();
+   TransactionImpl tx = (TransactionImpl) getTransaction();
+return tx == null ? null: tx.getTransactionKey();
 }
 
 public int getTransactionStatus() {


Modified: 
geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1.1/geronimo-transaction/src/test/java/org/apache/geronimo/transaction/manager/TransactionSynchronizationRegistryTest.java
URL: 
http://svn.apache.org/viewvc/geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1.1/geronimo-transaction/src/test/java/org/apache/geronimo/transaction/manager/TransactionSynchronizationRegistryTest.java?rev=722725r1=722724r2=722725view=diff
==
--- 
geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1.1/geronimo-transaction/src/test/java/org/apache/geronimo/transaction/manager/TransactionSynchronizationRegistryTest.java
 (original)
+++ 
geronimo/components/txmanager/branches/geronimo-txmanager-parent-2.1.1/geronimo-transaction/src/test/java/org/apache/geronimo/transaction/manager/TransactionSynchronizationRegistryTest.java
 Tue Dec  2 18:51:11 2008
@@ -57,6 +57,15 @@
 tm.getTransaction().registerSynchronization(normalSync);
 }
 
+public void testTransactionKey() throws Exception {

+   normalSync = new CountingSync();
+   assertNull(tm.getTransactionKey());
+   setUpInterposedSync();
+   tm.getTransaction().registerSynchronization(normalSync);
+   assertNotNull(tm.getTransactionKey());
+   tm.commit();
+   assertNull(tm.getTransactionKey());
+}
 
 public void testInterposedSynchIsCalledOnCommit() throws Exception {

 setUpInterposedSync();

Re: svn commit: r722730 - in /geronimo/server/trunk: plugins/jasper/jasper/src/main/history/dependencies.xml plugins/tomcat/tomcat6/src/main/history/dependencies.xml pom.xml repository/org/apache/tomc

2008-12-02 Thread Jarek Gawor

I'm not sure which recent changes are causing this but I'm getting the
following build error in trunk now:

[ERROR] FATAL ERROR
[INFO] 
[INFO] 
file:/home/jgawor/development/geronimo/plugins/activemq/activemq-portlets/src/main/webapp/WEB-INF/view/jmsmanager/viewDLQ.jsp(43,8)
${fn:length(messages)  0} contains invalid expression(s):
javax.el.ELException: Function 'f:length' not found

Jarek

On Tue, Dec 2, 2008 at 10:03 PM,  [EMAIL PROTECTED] wrote:
 Author: dwoods
 Date: Tue Dec  2 19:03:40 2008
 New Revision: 722730

 URL: http://svn.apache.org/viewvc?rev=722730view=rev
 Log:
 updates related to Rev722685, which introduced new depends for some of the 
 patched Tomcat artifacts

 Modified:

 geronimo/server/trunk/plugins/jasper/jasper/src/main/history/dependencies.xml

 geronimo/server/trunk/plugins/tomcat/tomcat6/src/main/history/dependencies.xml
geronimo/server/trunk/pom.xml

 geronimo/server/trunk/repository/org/apache/tomcat/jasper/6.0.18-G678601/jasper-6.0.18-G678601.pom

 Modified: 
 geronimo/server/trunk/plugins/jasper/jasper/src/main/history/dependencies.xml
 URL: 
 http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/jasper/jasper/src/main/history/dependencies.xml?rev=722730r1=722729r2=722730view=diff
 ==
 --- 
 geronimo/server/trunk/plugins/jasper/jasper/src/main/history/dependencies.xml 
 (original)
 +++ 
 geronimo/server/trunk/plugins/jasper/jasper/src/main/history/dependencies.xml 
 Tue Dec  2 19:03:40 2008
 @@ -12,6 +12,11 @@
 typejar/type
 /dependency
 dependency
 +groupIdorg.apache.tomcat/groupId
 +artifactIdcatalina/artifactId
 +typejar/type
 +/dependency
 +dependency
 groupIdorg.apache.geronimo.configs/groupId
 artifactIdj2ee-server/artifactId
 typecar/type

 Modified: 
 geronimo/server/trunk/plugins/tomcat/tomcat6/src/main/history/dependencies.xml
 URL: 
 http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/tomcat/tomcat6/src/main/history/dependencies.xml?rev=722730r1=722729r2=722730view=diff
 ==
 --- 
 geronimo/server/trunk/plugins/tomcat/tomcat6/src/main/history/dependencies.xml
  (original)
 +++ 
 geronimo/server/trunk/plugins/tomcat/tomcat6/src/main/history/dependencies.xml
  Tue Dec  2 19:03:40 2008
 @@ -12,11 +12,6 @@
 typecar/type
 /dependency
 dependency
 -groupIdorg.apache.tomcat/groupId
 -artifactIdcatalina/artifactId
 -typejar/type
 -/dependency
 -dependency
 groupIdorg.apache.geronimo.configs/groupId
 artifactIdj2ee-server/artifactId
 typecar/type

 Modified: geronimo/server/trunk/pom.xml
 URL: 
 http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?rev=722730r1=722729r2=722730view=diff
 ==
 --- geronimo/server/trunk/pom.xml (original)
 +++ geronimo/server/trunk/pom.xml Tue Dec  2 19:03:40 2008
 @@ -1402,12 +1402,36 @@
 groupIdorg.apache.tomcat/groupId
 artifactIdjasper/artifactId
 version6.0.18-G678601/version
 +exclusions
 +exclusion
 +groupIdorg.apache.tomcat/groupId
 +artifactIdservlet-api/artifactId
 +/exclusion
 +exclusion
 +groupIdorg.apache.tomcat/groupId
 +artifactIdjuli/artifactId
 +/exclusion
 +exclusion
 +groupIdorg.apache.tomcat/groupId
 +artifactIdjsp-api/artifactId
 +/exclusion
 +exclusion
 +groupIdorg.apache.tomcat/groupId
 +artifactIdel-api/artifactId
 +/exclusion
 +/exclusions
 /dependency

 dependency
 groupIdorg.apache.tomcat/groupId
 artifactIdjasper-el/artifactId
 version6.0.18-G678601/version
 +exclusions
 +exclusion
 +groupIdorg.apache.tomcat/groupId
 +artifactIdel-api/artifactId
 +/exclusion
 +/exclusions
 /dependency

 dependency
 @@ -1444,6 +1468,20 @@
 groupIdorg.apache.tomcat/groupId
 artifactIdcatalina/artifactId
 version6.0.18-G678601/version
 +exclusions
 +exclusion
 +groupIdorg.apache.tomcat/groupId
 +artifactIdservlet-api/artifactId
 +/exclusion
 +exclusion
 +

Re: svn commit: r722730 - in /geronimo/server/trunk: plugins/jasper/jasper/src/main/history/dependencies.xml plugins/tomcat/tomcat6/src/main/history/dependencies.xml pom.xml repository/org/apache/tomc

2008-12-02 Thread Jarek Gawor

Never mind. I got things going again after doing rm -rf
~/.m2/repository/org/apache/tomcat

Jarek

On Tue, Dec 2, 2008 at 10:50 PM, Jarek Gawor [EMAIL PROTECTED] wrote:
 I'm not sure which recent changes are causing this but I'm getting the
 following build error in trunk now:

 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] 
 file:/home/jgawor/development/geronimo/plugins/activemq/activemq-portlets/src/main/webapp/WEB-INF/view/jmsmanager/viewDLQ.jsp(43,8)
 ${fn:length(messages)  0} contains invalid expression(s):
 javax.el.ELException: Function 'f:length' not found

 Jarek

 On Tue, Dec 2, 2008 at 10:03 PM,  [EMAIL PROTECTED] wrote:
 Author: dwoods
 Date: Tue Dec  2 19:03:40 2008
 New Revision: 722730

 URL: http://svn.apache.org/viewvc?rev=722730view=rev
 Log:
 updates related to Rev722685, which introduced new depends for some of the 
 patched Tomcat artifacts

 Modified:

 geronimo/server/trunk/plugins/jasper/jasper/src/main/history/dependencies.xml

 geronimo/server/trunk/plugins/tomcat/tomcat6/src/main/history/dependencies.xml
geronimo/server/trunk/pom.xml

 geronimo/server/trunk/repository/org/apache/tomcat/jasper/6.0.18-G678601/jasper-6.0.18-G678601.pom

 Modified: 
 geronimo/server/trunk/plugins/jasper/jasper/src/main/history/dependencies.xml
 URL: 
 http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/jasper/jasper/src/main/history/dependencies.xml?rev=722730r1=722729r2=722730view=diff
 ==
 --- 
 geronimo/server/trunk/plugins/jasper/jasper/src/main/history/dependencies.xml
  (original)
 +++ 
 geronimo/server/trunk/plugins/jasper/jasper/src/main/history/dependencies.xml
  Tue Dec  2 19:03:40 2008
 @@ -12,6 +12,11 @@
 typejar/type
 /dependency
 dependency
 +groupIdorg.apache.tomcat/groupId
 +artifactIdcatalina/artifactId
 +typejar/type
 +/dependency
 +dependency
 groupIdorg.apache.geronimo.configs/groupId
 artifactIdj2ee-server/artifactId
 typecar/type

 Modified: 
 geronimo/server/trunk/plugins/tomcat/tomcat6/src/main/history/dependencies.xml
 URL: 
 http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/tomcat/tomcat6/src/main/history/dependencies.xml?rev=722730r1=722729r2=722730view=diff
 ==
 --- 
 geronimo/server/trunk/plugins/tomcat/tomcat6/src/main/history/dependencies.xml
  (original)
 +++ 
 geronimo/server/trunk/plugins/tomcat/tomcat6/src/main/history/dependencies.xml
  Tue Dec  2 19:03:40 2008
 @@ -12,11 +12,6 @@
 typecar/type
 /dependency
 dependency
 -groupIdorg.apache.tomcat/groupId
 -artifactIdcatalina/artifactId
 -typejar/type
 -/dependency
 -dependency
 groupIdorg.apache.geronimo.configs/groupId
 artifactIdj2ee-server/artifactId
 typecar/type

 Modified: geronimo/server/trunk/pom.xml
 URL: 
 http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?rev=722730r1=722729r2=722730view=diff
 ==
 --- geronimo/server/trunk/pom.xml (original)
 +++ geronimo/server/trunk/pom.xml Tue Dec  2 19:03:40 2008
 @@ -1402,12 +1402,36 @@
 groupIdorg.apache.tomcat/groupId
 artifactIdjasper/artifactId
 version6.0.18-G678601/version
 +exclusions
 +exclusion
 +groupIdorg.apache.tomcat/groupId
 +artifactIdservlet-api/artifactId
 +/exclusion
 +exclusion
 +groupIdorg.apache.tomcat/groupId
 +artifactIdjuli/artifactId
 +/exclusion
 +exclusion
 +groupIdorg.apache.tomcat/groupId
 +artifactIdjsp-api/artifactId
 +/exclusion
 +exclusion
 +groupIdorg.apache.tomcat/groupId
 +artifactIdel-api/artifactId
 +/exclusion
 +/exclusions
 /dependency

 dependency
 groupIdorg.apache.tomcat/groupId
 artifactIdjasper-el/artifactId
 version6.0.18-G678601/version
 +exclusions
 +exclusion
 +groupIdorg.apache.tomcat/groupId
 +artifactIdel-api/artifactId
 +/exclusion
 +/exclusions
 /dependency

 dependency
 @@ -1444,6 +1468,20 @@
 groupIdorg.apache.tomcat/groupId
 artifactIdcatalina/artifactId
 version6.0.18-G678601/version
 +exclusions
 +exclusion
 +

Genesis 2.0 site muck

I've been working on the Genesis 2.0 site muck for the upcoming GShell  
release, and I have the site generation bits work, but not the custom  
skin.  I think the entire skin needs to be re-crafted.  I don't think  
I am going to have time to do this for the first Genesis 2.0 release,  
maybe 2.0.1 or something.  And since we don't use the site stuff very  
much I don't think this is a big deal.  If anyone thinks that is the  
wrong assumption please speak up.


--jason

[jira] Updated: (GERONIMODEVTOOLS-521) Sign features so the eclipse update manager recognizes them as signed

2008-12-02 Thread Delos Dai (JIRA)


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

Delos Dai updated GERONIMODEVTOOLS-521:
---

Attachment: 521.patch

 Sign features so the eclipse update manager recognizes them as signed
 -

 Key: GERONIMODEVTOOLS-521
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-521
 Project: Geronimo-Devtools
  Issue Type: Bug
  Components: eclipse-plugin
Affects Versions: 2.0.0, 2.1.0, 2.1.1, 2.1.2, 2.1.3
Reporter: Ted Kirby
Assignee: Tim McConnell
 Fix For: 2.2.0

 Attachments: 521.patch




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

[jira] Commented: (GERONIMODEVTOOLS-521) Sign features so the eclipse update manager recognizes them as signed

2008-12-02 Thread Delos Dai (JIRA)

[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12652692#action_12652692
]

Delos Dai commented on GERONIMODEVTOOLS-521:

I think you mean we should add signature for each plugin.

For this bug, maven plugin keytool-maven-plugin will be used to generate
certification and jar:sign goal in maven-jar-plugin will be needed to sign
the jar packages.

Attachment is a patch for this.Then, after building, generated GEP will be
shown as signed in eclipse plugins list.

The added properties in eclipse-plugin/trunk/pom.xml are:
keystoreAliasdevtools/keystoreAlias
keystoreFilekeystore/keystoreFile
keystoreDnamecn=http://geronimo.apache.org/keystoreDname
keystoreKeypassdevtools/keystoreKeypass
keystoreStorepassgeronimo/keystoreStorepass
keystoreValDays180/keystoreValDays
They're the parameters used to generate signature. I just give sample here, you
can replace them. The parameters here are similar to the parameters of
keytool and jarsigner.

Could anyone help to review it? Thanks!

Sign features so the eclipse update manager recognizes them as signed
-

Key: GERONIMODEVTOOLS-521
URL:
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-521
Project: Geronimo-Devtools
Issue Type: Bug
Components: eclipse-plugin
Affects Versions: 2.0.0, 2.1.0, 2.1.1, 2.1.2, 2.1.3
Reporter: Ted Kirby
Assignee: Tim McConnell
Fix For: 2.2.0

Attachments: 521.patch

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

Re: Tuscany Geronimo integration and the SCA JEE spec

2008-12-02 Thread Vamsavardhana Reddy

On Tue, Dec 2, 2008 at 9:14 PM, Kevan Miller [EMAIL PROTECTED] wrote:

Hi JS,
Vamsi generated some doc --
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Installing+the+Tuscany+Plugin+for+Geronimo

Although it's not working for me, at the moment... Vamsi, do those
instructions work for you?

Yes, those instructions work for me. What is the error you are seeing?

More comments below...

On Dec 1, 2008, at 12:40 PM, mobyjobs wrote:

I tried to install the plug in but seeing missing dependency message (as
bellow), not sure what I have missed:

I have checked I have all the dependency files in repository; Here are the
steps I followed;

You should not be using the geronimo server's repository in this manner --
it's not intended to be a generic maven repository. Just use the default
location for your local maven repository (i.e. .m2\repository). Geronimo
will copy the necessary artifacts into the server's repository as needed.

Your server is confused because it's trying to install tuscany-tomcat, but
there are already artifacts in
repository/org/apache/geronimo/plugins/tuscany-tomcat directory.

- checkout out code for geronimo plug-in code from
https://svn.apache.org/repos/asf/geronimo/plugins/tuscany/trunk/
- build the plug-in using 'mvn install' ; build was successful and all the
files copied to repository.
3. Deploy plugin using the command g_install_dir\bin\deploy.bat
install-plugin tuscany tomcat\target\tuscany-tomcat-1.0-SNAPSHOT.car

After building, I'd use the admin console to install the plugin:
http://localhost:8080/console/portal/Applications/Plugins

Click Show Plugins in selected repository, select Geronimo :: Tuscany
Plugin for Geronimo Tomcat and click the install button (scroll down to the
bottom of the screen), then click install again. This should installs the
Tuscany plugin and dependencies into my 2.1.4-SNAPSHOT server.

I will add these instructions to the wiki page.

You'll also need the config.xml changes mentioned in
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Installing+the+Tuscany+Plugin+for+Geronimo

Even with these, things don't seem to be working. I can deploy the sample
jsp app, but it doesn't seem to be working... Hoping that Vamsi can comment.

Are you using Geronimo v2.1.3? That is the version on which I have verified
that the instructions work.

--kevan

--
Vamsi

Subscribe mail list dev@geronimo.apache.org

2008-12-02 Thread han hongfang

Hi,

I'm interested with Geronimo development and already had Apache CLA
signed. I want to subscribe mail list [EMAIL PROTECTED]

Thanks!

Best regard,

Han Hong Fang

[BUILD] trunk: Failed for Revision: 722714

2008-12-02 Thread gawor

Geronimo Revision: 722714 built with tests included
 
See the full build-2100.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081203/build-2100.log
 
 
See the unit test reports at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20081203/unit-test-reports
 
[INFO] [resources:resources]
[WARNING] Using platform encoding (ANSI_X3.4-1968 actually) to copy filtered 
resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory 
/home/geronimo/geronimo/trunk/plugins/jasper/geronimo-jasper/src/main/resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] [compiler:compile]
[INFO] Compiling 3 source files to 
/home/geronimo/geronimo/trunk/plugins/jasper/geronimo-jasper/target/classes
[INFO] [resources:testResources]
[WARNING] Using platform encoding (ANSI_X3.4-1968 actually) to copy filtered 
resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory 
/home/geronimo/geronimo/trunk/plugins/jasper/geronimo-jasper/src/test/resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] [compiler:testCompile]
[INFO] No sources to compile
[INFO] [surefire:test]
[INFO] Surefire report directory: 
/home/geronimo/geronimo/trunk/plugins/jasper/geronimo-jasper/target/surefire-reports

---
 T E S T S
---
There are no tests to run.

Results :

Tests run: 0, Failures: 0, Errors: 0, Skipped: 0

[INFO] [jar:jar]
[INFO] Building jar: 
/home/geronimo/geronimo/trunk/plugins/jasper/geronimo-jasper/target/geronimo-jasper-2.2-SNAPSHOT.jar
[INFO] [ianal:verify-legal-files {execution: default}]
[INFO] Checking legal files in: geronimo-jasper-2.2-SNAPSHOT.jar
[INFO] [install:install]
[INFO] Installing 
/home/geronimo/geronimo/trunk/plugins/jasper/geronimo-jasper/target/geronimo-jasper-2.2-SNAPSHOT.jar
 to 
/home/geronimo/.m2/repository/org/apache/geronimo/modules/geronimo-jasper/2.2-SNAPSHOT/geronimo-jasper-2.2-SNAPSHOT.jar
[INFO] 
[INFO] Building Geronimo Plugins, Jasper :: Jasper
[INFO]task-segment: [install]
[INFO] 
Downloading: 
http://repo1.maven.org/maven2/org/apache/tomcat/extras/juli-adapters/6.0.18/juli-adapters-6.0.18.pom
1K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/tomcat/extras/juli/6.0.18/juli-6.0.18.pom
1K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/tomcat/extras/juli-adapters/6.0.18/juli-adapters-6.0.18.jar
22K downloaded
Downloading: 
http://repo1.maven.org/maven2/org/apache/tomcat/extras/juli/6.0.18/juli-6.0.18.jar
58K downloaded
[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: process}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[WARNING] Using platform encoding (ANSI_X3.4-1968 actually) to copy filtered 
resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory 
/home/geronimo/geronimo/trunk/plugins/jasper/jasper/src/main/resources
[INFO] Copying 3 resources
[INFO] Copying 3 resources
[INFO] [car:validate-configuration]
[INFO] [car:prepare-plan]
[INFO] Generated: 
/home/geronimo/geronimo/trunk/plugins/jasper/jasper/target/resources/META-INF/plan.xml
[INFO] [car:verify-no-dependency-change]
[INFO] 
[ERROR] BUILD FAILURE
[INFO] 
[INFO] Dependencies have changed:
Added dependencies are saved here: 
/home/geronimo/geronimo/trunk/plugins/jasper/jasper/src/main/history/dependencies.added.xml
Tree listing is saved here: 
/home/geronimo/geronimo/trunk/plugins/jasper/jasper/src/main/history/treeListing.xml
Delete 
/home/geronimo/geronimo/trunk/plugins/jasper/jasper/src/main/history/dependencies.xml
 if you are happy with the dependency changes.
[INFO] 
[INFO] Trace
org.apache.maven.BuildFailureException: Dependencies have changed:
Added dependencies are saved here: 
/home/geronimo/geronimo/trunk/plugins/jasper/jasper/src/main/history/dependencies.added.xml
Tree listing is saved here: 
/home/geronimo/geronimo/trunk/plugins/jasper/jasper/src/main/history/treeListing.xml
Delete 
/home/geronimo/geronimo/trunk/plugins/jasper/jasper/src/main/history/dependencies.xml
 if you are happy with the dependency changes.
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:579)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at

Re: Subscribe mail list dev@geronimo.apache.org

2008-12-02 Thread Vamsavardhana Reddy

Send mail to [EMAIL PROTECTED] .

++Vamsi

On Wed, Dec 3, 2008 at 11:23 AM, han hongfang [EMAIL PROTECTED] wrote:

 Hi,

 I'm interested with Geronimo development and already had Apache CLA
 signed. I want to subscribe mail list [EMAIL PROTECTED]

 Thanks!

 Best regard,

 Han Hong Fang




-- 
Vamsi

[jira] Closed: (GSHELL-81) Depdendency on sun.* packages


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

Jason Dillon closed GSHELL-81.
--

   Resolution: Won't Fix
Fix Version/s: (was: 1.0-alpha-3)
   1.0-alpha-2

XStream is currently not used directly, so this is not something that needs to 
be fixed.

 Depdendency on sun.* packages
 -

 Key: GSHELL-81
 URL: https://issues.apache.org/jira/browse/GSHELL-81
 Project: GShell
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: Support - Marshal
Reporter: Guillaume Nodet
Assignee: Jason Dillon
 Fix For: 1.0-alpha-2


 It seems that GShell is currently unable to run without the sun.* packages in 
 the classloader.
 The reason is that it uses xstream advanced mode which make use of these 
 packages.
 If these packages are not on the classpath, xstream will default to the pure 
 java reflection provider which will cause exceptions like the following:
 {noformat}
 Caused by: com.thoughtworks.xstream.converters.ConversionException: Cannot 
 construct org.apache.geronimo.gshell.layout.model.CommandNode as it does not 
 have a no-args constructor
  Debugging information 
 message : Cannot construct 
 org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
 no-args constructor
 cause-exception : 
 com.thoughtworks.xstream.converters.reflection.ObjectAccessException
 cause-message   : Cannot construct 
 org.apache.geronimo.gshell.layout.model.CommandNode as it does not have a 
 no-args constructor
 class   : org.apache.geronimo.gshell.layout.model.Layout
 required-type   : org.apache.geronimo.gshell.layout.model.CommandNode
 path: /layout/nodes/command
 ---
 {noformat}
 I'm not sure if this is a good idea or if we should support that pure java 
 mode...

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

[jira] Updated: (GSHELL-82) Bring the testsuite back


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

Jason Dillon updated GSHELL-82:
---

Fix Version/s: (was: 1.0-alpha-2)
   1.0-alpha-3

Defer until next release.

 Bring the testsuite back
 

 Key: GSHELL-82
 URL: https://issues.apache.org/jira/browse/GSHELL-82
 Project: GShell
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: Build
Reporter: Jason Dillon
Assignee: Jason Dillon
Priority: Blocker
 Fix For: 1.0-alpha-3


 Need to bring the testsuite back so that we can create integration tests for 
 commands.  Actually need to see if we can use SHITTY to allow command modules 
 to create localized integration tests.

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

[jira] Updated: (GSHELL-47) Add flag (and support) to capture the output of a gsh run to a log-file configured on the cli


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

Jason Dillon updated GSHELL-47:
---

Fix Version/s: (was: 1.0-alpha-2)
   1.0-alpha-3

Defer until next release.

 Add flag (and support) to capture the output of a gsh run to a log-file 
 configured on the cli
 -

 Key: GSHELL-47
 URL: https://issues.apache.org/jira/browse/GSHELL-47
 Project: GShell
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: CLI
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Priority: Minor
 Fix For: 1.0-alpha-3


 Should be able to specify something like:
 {noformat}
 ./bin/gsh --logfile output.log
 {noformat}
 And have all of the output captured to a file named {{output.log}}, or 
 whatever was given to the {{--logfile}} option.

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

[jira] Updated: (GSHELL-69) gsh -c should soak up all remaining arguments and build a command-line


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

Jason Dillon updated GSHELL-69:
---

Fix Version/s: (was: 1.0-alpha-2)
   1.0-alpha-3

Defer until next release.

 gsh -c should soak up all remaining arguments and build a command-line
 --

 Key: GSHELL-69
 URL: https://issues.apache.org/jira/browse/GSHELL-69
 Project: GShell
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: CLI
Affects Versions: 1.0-alpha-1
Reporter: Jason Dillon
Assignee: Jason Dillon
Priority: Minor
 Fix For: 1.0-alpha-3


 Right now {{-c}} takes a list of arguments to run non-interactively.  It 
 should instead take all remaining arguments for execution non-interactively.
 This means that {{-c}} can contain easily quoted arguments if needed and 
 should simplify usage of gsh for non-interactive usage.

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

[jira] Updated: (GSHELL-68) CLP should allow -vvv to be treated like -v -v -v


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

Jason Dillon updated GSHELL-68:
---

Fix Version/s: (was: 1.0-alpha-2)
   1.0-alpha-3

Defer until next release.

 CLP should allow -vvv to be treated like -v -v -v
 -

 Key: GSHELL-68
 URL: https://issues.apache.org/jira/browse/GSHELL-68
 Project: GShell
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: Support - CLP
Reporter: Jason Dillon
Priority: Minor
 Fix For: 1.0-alpha-3




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

[jira] Updated: (GSHELL-67) Allow the clp to generate help text with ANSI colors


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

Jason Dillon updated GSHELL-67:
---

Fix Version/s: (was: 1.0-alpha-2)
   1.0-alpha-3

Defer until next release.

 Allow the clp to generate help text with ANSI colors
 

 Key: GSHELL-67
 URL: https://issues.apache.org/jira/browse/GSHELL-67
 Project: GShell
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: Support - CLP
Reporter: Jason Dillon
Priority: Trivial
 Fix For: 1.0-alpha-3


 Generated {{--help}} text should probably use ANSI to highlight things, and 
 allow embedded {{|@xxx yyy|}} syntax for implementors to provide specific 
 coloring.
 This basically means using the ANSI renderer in the CLP printer.

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

Re: svn commit: r722730 - in /geronimo/server/trunk: plugins/jasper/jasper/src/main/history/dependencies.xml plugins/tomcat/tomcat6/src/main/history/dependencies.xml pom.xml repository/org/apache/tomc

2008-12-02 Thread David Jencks

Thanks for fixing this, I ran out of time after realizing it caused a  
problem.  I made a couple more tweaks to get the dependencies.xml back  
to where they were in rev 722795


david jencks

On Dec 2, 2008, at 7:03 PM, [EMAIL PROTECTED] wrote:


Author: dwoods
Date: Tue Dec  2 19:03:40 2008
New Revision: 722730

URL: http://svn.apache.org/viewvc?rev=722730view=rev
Log:
updates related to Rev722685, which introduced new depends for some  
of the patched Tomcat artifacts


Modified:
   geronimo/server/trunk/plugins/jasper/jasper/src/main/history/ 
dependencies.xml
   geronimo/server/trunk/plugins/tomcat/tomcat6/src/main/history/ 
dependencies.xml

   geronimo/server/trunk/pom.xml
   geronimo/server/trunk/repository/org/apache/tomcat/jasper/6.0.18- 
G678601/jasper-6.0.18-G678601.pom


Modified: geronimo/server/trunk/plugins/jasper/jasper/src/main/ 
history/dependencies.xml

URL: 
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/jasper/jasper/src/main/history/dependencies.xml?rev=722730r1=722729r2=722730view=diff
= 
= 
= 
= 
= 
= 
= 
= 
==
--- geronimo/server/trunk/plugins/jasper/jasper/src/main/history/ 
dependencies.xml (original)
+++ geronimo/server/trunk/plugins/jasper/jasper/src/main/history/ 
dependencies.xml Tue Dec  2 19:03:40 2008

@@ -12,6 +12,11 @@
typejar/type
/dependency
dependency
+groupIdorg.apache.tomcat/groupId
+artifactIdcatalina/artifactId
+typejar/type
+/dependency
+dependency
groupIdorg.apache.geronimo.configs/groupId
artifactIdj2ee-server/artifactId
typecar/type

Modified: geronimo/server/trunk/plugins/tomcat/tomcat6/src/main/ 
history/dependencies.xml

URL: 
http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/tomcat/tomcat6/src/main/history/dependencies.xml?rev=722730r1=722729r2=722730view=diff
= 
= 
= 
= 
= 
= 
= 
= 
==
--- geronimo/server/trunk/plugins/tomcat/tomcat6/src/main/history/ 
dependencies.xml (original)
+++ geronimo/server/trunk/plugins/tomcat/tomcat6/src/main/history/ 
dependencies.xml Tue Dec  2 19:03:40 2008

@@ -12,11 +12,6 @@
typecar/type
/dependency
dependency
-groupIdorg.apache.tomcat/groupId
-artifactIdcatalina/artifactId
-typejar/type
-/dependency
-dependency
groupIdorg.apache.geronimo.configs/groupId
artifactIdj2ee-server/artifactId
typecar/type

Modified: geronimo/server/trunk/pom.xml
URL: 
http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?rev=722730r1=722729r2=722730view=diff
= 
= 
= 
= 
= 
= 
= 
= 
==

--- geronimo/server/trunk/pom.xml (original)
+++ geronimo/server/trunk/pom.xml Tue Dec  2 19:03:40 2008
@@ -1402,12 +1402,36 @@
groupIdorg.apache.tomcat/groupId
artifactIdjasper/artifactId
version6.0.18-G678601/version
+exclusions
+exclusion
+groupIdorg.apache.tomcat/groupId
+artifactIdservlet-api/artifactId
+/exclusion
+exclusion
+groupIdorg.apache.tomcat/groupId
+artifactIdjuli/artifactId
+/exclusion
+exclusion
+groupIdorg.apache.tomcat/groupId
+artifactIdjsp-api/artifactId
+/exclusion
+exclusion
+groupIdorg.apache.tomcat/groupId
+artifactIdel-api/artifactId
+/exclusion
+/exclusions
/dependency

dependency
groupIdorg.apache.tomcat/groupId
artifactIdjasper-el/artifactId
version6.0.18-G678601/version
+exclusions
+exclusion
+groupIdorg.apache.tomcat/groupId
+artifactIdel-api/artifactId
+/exclusion
+/exclusions
/dependency

dependency
@@ -1444,6 +1468,20 @@
groupIdorg.apache.tomcat/groupId
artifactIdcatalina/artifactId
version6.0.18-G678601/version
+exclusions
+exclusion
+groupIdorg.apache.tomcat/groupId
+artifactIdservlet-api/artifactId
+/exclusion
+exclusion
+groupIdorg.apache.tomcat/groupId
+artifactIdjuli/artifactId
+/exclusion
+exclusion
+groupIdorg.apache.tomcat/groupId
+artifactIdannotations-api/artifactId
+/exclusion
+

[jira] Updated: (GSHELL-43) Add role-based layout selection


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

Jason Dillon updated GSHELL-43:
---

Fix Version/s: (was: 1.0-alpha-3)
   1.0-alpha-2

 Add role-based layout selection
 ---

 Key: GSHELL-43
 URL: https://issues.apache.org/jira/browse/GSHELL-43
 Project: GShell
  Issue Type: New Feature
  Security Level: public(Regular issues) 
Reporter: Jason Dillon
Priority: Minor
 Fix For: 1.0-alpha-2


 Add support to select a different layout based on the user who is logged in.  
 Some users might need only basic commands while others might need a full 
 range (of admin or potentially harmful commands).

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

[jira] Closed: (GSHELL-23) Command pipe-lines


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

Jason Dillon closed GSHELL-23.
--

   Resolution: Fixed
Fix Version/s: (was: 1.0-alpha-3)
   1.0-alpha-2
 Assignee: Jason Dillon  (was: Erik B. Craig)

Basic support is in for this.

 Command pipe-lines
 --

 Key: GSHELL-23
 URL: https://issues.apache.org/jira/browse/GSHELL-23
 Project: GShell
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: Parser
Reporter: Jason Dillon
Assignee: Jason Dillon
 Fix For: 1.0-alpha-2


 Add support for piping the output of one command into another, as in:
 {noformat}
 echo hi | cat  /tmp/foo
 {noformat}
 This should write hi to the /tmp/foo file.
 Follow zsh style, allowing | to concat both stdout+stderr

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

Re: private repo in svn questions...