date:20081208

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

2008-12-08 Thread Delos Dai (JIRA)


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

Delos Dai commented on GERONIMODEVTOOLS-540:


Anyway, I agree with you, Francisco. It  is a problem of Geronimo Devtools, so 
you don't have other chioce.

I think the key to contaminate Tomcat is not the  server path,  but the 
deploy path. So, Geronimo Devtools may consider to set difference deploy path 
for workspaces, instead of deploy modules into the GERONIMO_HOME/repository.

Does anyone know how to change the default deploy path of Geronimo Server?

Thanks!

 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
Affects Versions: 2.2.0, 2.1.4
Reporter: Francisco Peredo
Assignee: Tim McConnell
 Attachments: screenshot-1.jpg, screenshot-tomcat-adapter.jpg


 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.

Re: [DISCUSS] Release Concurrent Spec jar (1.0) version 1.0-EA

2008-12-08 Thread Joe Bohn


Kevan Miller wrote:


On Dec 7, 2008, at 11:44 PM, Joe Bohn wrote:

ummm ... does anybody else want to vote (or comment) beyond Jarek and 
myself?


Point of law reminder -- a minimum of 3 PMC +1's are required for any 
release votes. So, someone else *must* vote.


Right ... I wasn't planning to call the vote ... just trying to get some 
response.




Since you ask -- it looks like we've dropped LICENSE/NOTICE files from 
the root directory.


https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-concurrent_1.0_spec-1.0-EA should 
contain a LICENSE and NOTICE file (even if it's the standard format). 
Looks like a few other recent specs are missing this. Not sure when the 
problem started.


Yes, I noticed that too.  But the LICENSE/NOTICE files are included in 
specs-parent and pulled into the artifacts from there.  I was thinking 
that was sufficient.


Joe

Re: [discussion] Using Apache Commons Deamon to run Geronimo as a Windows service

2008-12-08 Thread Jack Cai

Thanks for the comments! I would agree with Jarek that two long-run java
processes just for Geronimo service might not be a good idea. So I'll stick
to the plain command method.

While waiting for my patches to be committed by the Commons community, for
now I'll use the simple stupid command line option to start the Windows
service, instead of the JVM or JAVA mode. The latter provides better
configuration UI, while the command line method need the user to edit the
long command line string if they want to change any argument (like JVM
options). This way I minimize the code difference, as only one patch is
necessary which fixes a real defect:
https://issues.apache.org/jira/browse/DAEMON-118.

Next I'll start to create the G plugin for this. We can update the contained
EXE files when my patches are accepted by Commons Daemon project.

-Jack

2008/12/5 Jarek Gawor [EMAIL PROTECTED]

On Thu, Dec 4, 2008 at 4:54 AM, Jack Cai [EMAIL PROTECTED] wrote:
I have been working on enabling Geronimo to run as a Windows service
using
Apache Commons Deamon procrun utility. I have been making good progress.
Now
I have some problems and would like to hear your opinions.

1. I have gone through all the open JIRAs of that project and are fixing
some of them. I have also reported and fixed several found by myself, and
a
few improvements too. But nobody is helping to commit my patches. Will it
be
OK that Geronimo just use the binary code built by me without maintaining
the latest code (I mean, which includes my patches)? Tomcat only include
procrun's binary today (as tomcat6.exe and tomcat6w.exe) which is
probably
built with the latest code from Apache Commons.

That sucks, maybe somebody will eventually commit it. Or maybe we
should svn copy that code into Geronimo sandbox and maintain it here?

2. Currently procrun need the starter class and stopper class to be on
the
same classpath. Unfortunately our server.jar and shutdown.jar contains
different config.ser, which screws things up. So I tried various ways to
work around this problem before I change procrun's design -

A. write a wrapper, which use a URLClassloader to load different jar for
startup and shutdown. To do so, I had to first remove the jpa agent, as
the
system classloader (parent of my URLClassloader) will load the config.ser
in
jpa.jar. After that Geronimo starts to boot, until the below exception
occurs:

17:43:19,421 WARN [1/car,j2eeType=GBean,name=JMXService] Failure in
JMXConnector
service:jmx:rmi://0.0.0.0:/jndi/rmi://0.0.0.0:1099/JMXConnector
17:43:19,421 ERROR [GBeanInstanceState] Error while starting; GBean is
now
in the FAILED state:

abstractName=org.apache.geronimo.framework/j2ee-security/2.1.1/car?ServiceModule=org.apache.geronimo.framework/j2ee-security/2.1.1/car,j2eeType=GBean,name=JMXService
java.lang.NoClassDefFoundError:
org.apache.geronimo.kernel.rmi.RMIClassLoaderSpiImpl
at

java.rmi.server.RMIClassLoader.initializeProvider(RMIClassLoader.java:680)

Try putting all the geronimo-kernel, geronimo-system jars on the
system classpath and only create URLClassLoader with shutdown.jar or
server.jar (and delegating to the system classloader).

Does Apache Commons Deamon restart the process automatically if if
detects abnormal shutdown? Personally, I'm against using GShell for
this as there is no need to start two Java processes just to run the
server.

Jarek

Re: [DISCUSS] Release Concurrent Spec jar (1.0) version 1.0-EA

2008-12-08 Thread Donald Woods


I'll vote on it... :-)


-Donald


Joe Bohn wrote:
ummm ... does anybody else want to vote (or comment) beyond Jarek and 
myself?


Joe


Joe Bohn wrote:

Discussion thread for Concurrent Spec release 1.0-EA

Joe

Re: [DISCUSS] DayTrader 2.1.3 release

2008-12-08 Thread Donald Woods

Seems to be a maven problem, in that only one of the CARs is being
published This will probably take a reorg of the source tree to
fix, like moving the plugin builds into their own /plugins directory
like the server builds and only building one plugin per subdirectory.

Should I cancel the vote and spend time fixing this, or release what we
have and fix it in trunk for DayTrader 2.2?

-Donald

Joe Bohn wrote:

Donald Woods wrote:
I was thinking of going with what we have, which is to manually
install the app clients. There are instructions in the README on how
to do that.

I'm confused by this. The tomcat client plugins *are* built when you do
a local build (as the README mentions) ... and supposedly they can be
installed as plugins according to the README as well (I didn't try this).

So why are these tomcat client car files not included in the
staging-repo content that we are voting on?

We're voting on both the source and the artifacts ... so if the source
when built produces the artifacts it seems like we should be voting on
those too.

BTW, only the tomcat cars exist as an archive file ... there are jetty
versions but they only exist in an unpacked form.

Here are the artifacts for the clients produced by the build:
./daytrader-jetty/target/repository/org/apache/geronimo/daytrader/daytrader-streamer-client/2.1.3/daytrader-streamer-client-2.1.3.car

./daytrader-tomcat/target/daytrader-streamer-client-2.1.3.car
./daytrader-tomcat/target/repository/org/apache/geronimo/daytrader/daytrader-streamer-client/2.1.3/daytrader-streamer-client-2.1.3.car

./daytrader-jetty/target/repository/org/apache/geronimo/daytrader/daytrader-ws-client/2.1.3/daytrader-ws-client-2.1.3.car

./daytrader-tomcat/target/daytrader-ws-client-2.1.3.car
./daytrader-tomcat/target/repository/org/apache/geronimo/daytrader/daytrader-ws-client/2.1.3/daytrader-ws-client-2.1.3.car

Is there some strange build processing that is creating these which is
not honored by the mvn release plugin?

Joe

Maybe we can get them setup as plugins in daytrader/trunk for the 2.2
release.

-Donald

Lin Sun wrote:

Hi Donald,

Thanks for getting this out for vote!

Do we plan to allow users to install the app client as G plugin? If
so, I think there is a manual work, that is to add the app client's
plugin.xml file to the plugin catalog (geronimo-plugins.xml). I think
we've got code to pack the app client car file and copy it onto local
.m2 repo.

Thanks

Lin

On Tue, Dec 2, 2008 at 5:03 PM, Donald Woods [EMAIL PROTECTED] wrote:
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] Updated: (GERONIMO-4451) locking and unlocking for availability of a keystore results in duplicate attributes in config.xml

2008-12-08 Thread Donald Woods (JIRA)

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

Donald Woods updated GERONIMO-4451:
---

Component/s: console
Fix Version/s: 2.2
2.1.4

adding target fix versions

locking and unlocking for availability of a keystore results in duplicate
attributes in config.xml
--

Key: GERONIMO-4451
URL: https://issues.apache.org/jira/browse/GERONIMO-4451
Project: Geronimo
Issue Type: Bug
Security Level: public(Regular issues)
Components: console, security
Affects Versions: 2.1.3
Environment: Ubuntu Linux 8.10, Sun Java 1.6, Geronimo 2.1.3 w/ Jetty.
Reporter: Christian Svensson
Fix For: 2.1.4, 2.2

Transcribing mail conversation:
Hello!
I've been trying for the better part of today getting keystores to
automatically unlock on startup - with very limited success.
Is there something that I should know about keystore password / key password?
Digging around some old mailing list threads said something about key
password must be equal to keystore password - any more of those gotchas?
The problem is that I create (or change password on geronimo-default for that
matter) a new keystore, assign SSL to use the certificate and restart the
server:
org.apache.geronimo.management.geronimo.KeystoreIsLocked: Keystore
'plasma-ssl' is locked; please use the keystore page in the admin console to
unlock it
at
org.apache.geronimo.security.keystore.FileKeystoreManager.createSSLContext(FileKeystoreManager.java:343)
at
org.apache.geronimo.jetty6.connector.GeronimoSelectChannelSSLListener.createSSLContext(GeronimoSelectChannelSSLListener.java:54)
Resetting the SSL connector to using geronimo-default / geronimo with secret
/ secret as passwords makes it work again - but why on earth doesn't Geronimo
unlock my keystores on startup? I mean, it saves the password (or something
like it) in config.xml.
-
This is how I created my setup:
1. Create a new keystore 'plasma-ssl'
2. Create a new private key 'wildcard'
3. Now the text on Available says trust only or something like that, I
lock it and then unlock it in order for it to change to 1 key ready
4. Then I configure my HTTPS connector to use the new keystore
5. Since the web server does not seem to do anything when I press Shutdown
in the console, I use Ctrl+C to kill it.
6. Start the server again
7. Message appears.
---
Hmm... the 3rd step is indeed unearthing a bug. At that step, a second
attribute element is getting added (instead of replacing the existing
element) to the keystore gbean for keystorePassword and keyPasswords
attributes in config.xml . Can you create an issue in the JIRA [1]? The
problem summary is, locking and unlocking for availability of a keystore
results in duplicate attributes in config.xml.

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

[jira] Updated: (GERONIMODEVTOOLS-545) initial version of the Server Plugin Manager code

2008-12-08 Thread Donald Woods (JIRA)


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

Donald Woods updated GERONIMODEVTOOLS-545:
--

Summary: initial version of the Server Plugin Manager code  (was: initial 
version of the code)

made title more meaningful

 initial version of the Server Plugin Manager code
 -

 Key: GERONIMODEVTOOLS-545
 URL: 
 https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-545
 Project: Geronimo-Devtools
  Issue Type: Sub-task
  Components: eclipse-plugin
Affects Versions: 2.2.0, 2.1.4
Reporter: B.J. Reed
Assignee: B.J. Reed
 Fix For: 2.2.0, 2.1.4


 Just a place holder for checking in all the original files that make this 
 work for simple test cases.

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

Re: [VOTE] Release Concurrent Spec jar (1.0) version 1.0-EA

2008-12-08 Thread Donald Woods


+1


-Donald


Joe Bohn wrote:
I've prepared a release candidate of the Concurrent spec for your review 
and vote.  This is spec is still under development so we are using an 
artifact version of 1.0-EA to indicate that it is not yet final.  I'm 
just the release vehicle here ... Jarek did all the work :-)



The source level is Rev723453 in the following svn tag:
https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-concurrent_1.0_spec-1.0-EA 



Staging repo:
http://people.apache.org/~jbohn/staging-repo/specs/geronimo-concurrent_1.0_spec/ 



Staging site:
http://people.apache.org/~jbohn/staging-site/specs/geronimo-concurrent_1.0_spec/1.0-EA/ 



The artifacts were created using the maven-release-plugin.


When the release vote is approved, the maven artifacts will be moved to 
the m2-ibiblio-rsync-repository at Apache.



[ ] +1 Release Concurrent Spec 1.0 version 1.0-EA
[ ] 0 No opinion
[ ] -1 Do not release Concurrent Spec 1.0 version 1.0-EA(please provide 
rationale)


The voting will be open for 72 hours (ending approx. 6:00PM ET on 
12/07/08) or until we have enough votes, whichever is longer.


Joe

Re: [DISCUSS] DayTrader 2.1.3 release

2008-12-08 Thread Lin Sun

Hi Joe/Donald,

Yes the tomcat client plugin is built when you do a local build and
the car artifact can be installed as a plugin when you supply the .car
file during the plugin installation. The prob IIRC is that we don't
have a way to automatically update the plugin catalog file yet, thus
if you choose to select plugins from a repo, you won't be able to see
this client plugin in the repo as it is not in the plugin catalog.

One apporach is to manually update the plugin catalog in the repo, by
copying the content of the geronimo-plugin.xml inside of the client
car artifact.This worked well when I tested it.

For the jetty version, I think I forgot to work on them :-( I think
it would be nice to get it completed as well.

Lin

On Fri, Dec 5, 2008 at 12:05 PM, Joe Bohn [EMAIL PROTECTED] wrote:

I'm confused by this. The tomcat client plugins *are* built when you do a
local build (as the README mentions) ... and supposedly they can be
installed as plugins according to the README as well (I didn't try this).

So why are these tomcat client car files not included in the staging-repo
content that we are voting on?

We're voting on both the source and the artifacts ... so if the source when
built produces the artifacts it seems like we should be voting on those too.

BTW, only the tomcat cars exist as an archive file ... there are jetty
versions but they only exist in an unpacked form.

Here are the artifacts for the clients produced by the build:
./daytrader-jetty/target/repository/org/apache/geronimo/daytrader/daytrader-streamer-client/2.1.3/daytrader-streamer-client-2.1.3.car
./daytrader-tomcat/target/daytrader-streamer-client-2.1.3.car
./daytrader-tomcat/target/repository/org/apache/geronimo/daytrader/daytrader-streamer-client/2.1.3/daytrader-streamer-client-2.1.3.car
./daytrader-jetty/target/repository/org/apache/geronimo/daytrader/daytrader-ws-client/2.1.3/daytrader-ws-client-2.1.3.car
./daytrader-tomcat/target/daytrader-ws-client-2.1.3.car
./daytrader-tomcat/target/repository/org/apache/geronimo/daytrader/daytrader-ws-client/2.1.3/daytrader-ws-client-2.1.3.car

Is there some strange build processing that is creating these which is not
honored by the mvn release plugin?

Joe

Maybe we can get them setup as plugins in daytrader/trunk for the 2.2
release.

-Donald

Lin Sun wrote:

Hi Donald,

Thanks for getting this out for vote!

Thanks

Lin

On Tue, Dec 2, 2008 at 5:03 PM, Donald Woods [EMAIL PROTECTED] wrote:

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

Re: [VOTE] Release DayTrader v2.1.3

2008-12-08 Thread Donald Woods


Still need people to look at this


-Donald


Donald Woods wrote:

All,

I've prepared a release candidate of DayTrader 2.1.3 for your review and 
vote.  This release can only be installed on Geronimo 2.1.3 server or 
later.


The source level is Rev723010 from the following svn branch:
https://svn.apache.org/repos/asf/geronimo/daytrader/branches/2.1.3/

When the release vote is approved, I will svn mv the code to:
https://svn.apache.org/repos/asf/geronimo/daytrader/tags/2.1.3/

The following staging directory contains the maven artifacts to be 
released:

http://people.apache.org/~dwoods/staging-repo/daytrader/

For your convenience, you can add the following as a plugin repo to 
install DayTrader as a plugin from the staging repo:

http://people.apache.org/~dwoods/

The README and source files can be found here:
http://people.apache.org/~dwoods/staging-repo/README-daytrader.txt
http://people.apache.org/~dwoods/staging-repo/daytrader/org/apache/geronimo/daytrader/daytrader/2.1.3/daytrader-2.1.3-src.zip 



When the release vote is approved, the maven artifacts will be moved to 
the m2-ibiblio-rsync-repository at Apache.



[ ] +1 Release DayTrader 2.1.3
[ ] 0 No opinion
[ ] -1 Do not release DayTrader 2.1.3 (please provide rationale)

The voting will be open for 72 hours or until we have enough votes, 
whichever is longer.



-Donald

Re: [DISCUSS] DayTrader 2.1.3 release

2008-12-08 Thread Donald Woods

Given the lack of interest of getting a DayTrader out for the 2.1 
codebase, I'm going to move it to samples/trunk for 2.2 unless I get a 
lot of input and votes on 2.1.3 this week.



-Donald


Donald Woods wrote:
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

Re: Update on documentation progress of Geronimo v2.2

2008-12-08 Thread Donald Woods


I still think these topics are more geared towards developers...

As long as we cover using the console/gshell in the Admin section and 
leave all maven related usage to the developer section (and note that 
this is only for advanced users), then I'm fine with keeping them in the 
2.2 User Docs.



-Donald


RunHua Chi wrote:

Thanks David for your comments.

I guess we have some different understandings regarding Users of
Geronimo.My understanding is that Geronimo is an application server and its
primary user would be application developers. While they might need to know
what a plugin or a gbean is in Geronimo but don't have to build the source
code. That's where my proposal comes from. And mostly they would read
GMOxDOC to learn how to utilize Geronimo for their application development.

And we have another group of Users(actually I'd rather call them
developers ^_^), they are more interested in Geronimo structure, kernel
and keen on breakthroughs. In my understanding, they would go to GMOXDEV for
more information. 

Any other ideas, please speak up. :) 


Jeff



djencks wrote:


On Dec 3, 2008, at 5:55 PM, RunHua Chi wrote:

Do we need to move following topics to GMOXDEV as they are also  
about how to

build

1. build a plugin as part of a maven build using the car-maven-plugin.
2. install a plugin using the car-maven-plugin
3. Assembling a server using Maven
These all need to stay in the regular documentation.  We expect many  
users to do all these activities every day, even if they don't build  
geronimo.


thanks
david jencks


If the answer is yes. Maybe we could have a page to collect all  
informations
on how to build with maven at GMOXDEV?So far, I have some topics  
coming up

my mind:

a. build Geronimo source code;
b. build/install a plugin using car-maven-plugin;
c. build a new server from the existing one;
d. build GEP
..and more

Any comments?

Jeff



Donald Woods-2 wrote:

Agree.  Using the eclipse/build.xml file from svn should go in the
GMOxDEV space, as that is really only for developers.  Maybe we could
include a Note and pointer over to the Dev docs for anyone who is
interested in using it.


-Donald

Re: [DISCUSS] DayTrader 2.1.3 release

2008-12-08 Thread Donald Woods

Sounds like a TODO for DayTrader 2.2.

-Donald

Lin Sun wrote:

Hi Joe/Donald,

One apporach is to manually update the plugin catalog in the repo, by
copying the content of the geronimo-plugin.xml inside of the client
car artifact.This worked well when I tested it.

For the jetty version, I think I forgot to work on them :-( I think
it would be nice to get it completed as well.

Lin

On Fri, Dec 5, 2008 at 12:05 PM, Joe Bohn [EMAIL PROTECTED] wrote:

I'm confused by this. The tomcat client plugins *are* built when you do a
local build (as the README mentions) ... and supposedly they can be
installed as plugins according to the README as well (I didn't try this).

So why are these tomcat client car files not included in the staging-repo
content that we are voting on?

We're voting on both the source and the artifacts ... so if the source when
built produces the artifacts it seems like we should be voting on those too.

BTW, only the tomcat cars exist as an archive file ... there are jetty
versions but they only exist in an unpacked form.

Is there some strange build processing that is creating these which is not
honored by the mvn release plugin?

Joe

Maybe we can get them setup as plugins in daytrader/trunk for the 2.2
release.

-Donald

Lin Sun wrote:

Hi Donald,

Thanks for getting this out for vote!

Thanks

Lin

On Tue, Dec 2, 2008 at 5:03 PM, Donald Woods [EMAIL PROTECTED] wrote:

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] Commented: (GERONIMO-4451) locking and unlocking for availability of a keystore results in duplicate attributes in config.xml

2008-12-08 Thread Jarek Gawor (JIRA)

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

Jarek Gawor commented on GERONIMO-4451:
---

Can you please try this with the latest 2.1
(http://people.apache.org/builds/geronimo/server/binaries/2.1/latest/) or 2.2
(http://people.apache.org/builds/geronimo/server/binaries/trunk/latest/) code?
This problem might be related to GERONIMO-4407 which is already fixed.

locking and unlocking for availability of a keystore results in duplicate
attributes in config.xml
--

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

Re: [DISCUSS] DayTrader 2.1.3 release

2008-12-08 Thread Joe Bohn

Lin,

Thanks for the information. IIUC then, the plugin catalog entries and
lack of jetty client plugins seem to be independent issues from the
tomcat client cars not being released. So there are a few issues then.
Given that this is a sample they might not be show-stoppers.

Joe

Lin Sun wrote:

Hi Joe/Donald,

One apporach is to manually update the plugin catalog in the repo, by
copying the content of the geronimo-plugin.xml inside of the client
car artifact.This worked well when I tested it.

For the jetty version, I think I forgot to work on them :-( I think
it would be nice to get it completed as well.

Lin

On Fri, Dec 5, 2008 at 12:05 PM, Joe Bohn [EMAIL PROTECTED] wrote:

I'm confused by this. The tomcat client plugins *are* built when you do a
local build (as the README mentions) ... and supposedly they can be
installed as plugins according to the README as well (I didn't try this).

So why are these tomcat client car files not included in the staging-repo
content that we are voting on?

We're voting on both the source and the artifacts ... so if the source when
built produces the artifacts it seems like we should be voting on those too.

BTW, only the tomcat cars exist as an archive file ... there are jetty
versions but they only exist in an unpacked form.

Is there some strange build processing that is creating these which is not
honored by the mvn release plugin?

Joe

Maybe we can get them setup as plugins in daytrader/trunk for the 2.2
release.

-Donald

Lin Sun wrote:

Hi Donald,

Thanks for getting this out for vote!

Thanks

Lin

On Tue, Dec 2, 2008 at 5:03 PM, Donald Woods [EMAIL PROTECTED] wrote:

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

Re: [DISCUSS] DayTrader 2.1.3 release

2008-12-08 Thread Joe Bohn

Donald Woods wrote:
Seems to be a maven problem, in that only one of the CARs is being
published This will probably take a reorg of the source tree to
fix, like moving the plugin builds into their own /plugins directory
like the server builds and only building one plugin per subdirectory.

Should I cancel the vote and spend time fixing this, or release what we
have and fix it in trunk for DayTrader 2.2?

I'm a bit undecided on this. I guess I'm ok with releasing this as is
for 2.1.3. It's been a long time since we've had a Daytrader release
and it seems that this is providing the primary functionality. And ...
after all it is a sample ... so perhaps releasing what we have and
fixing it in trunk for Daytrader 2.2 makes the most sense.

Joe

-Donald

Joe Bohn wrote:

Donald Woods wrote:
I was thinking of going with what we have, which is to manually
install the app clients. There are instructions in the README on how
to do that.

I'm confused by this. The tomcat client plugins *are* built when you
do a local build (as the README mentions) ... and supposedly they can
be installed as plugins according to the README as well (I didn't try
this).