date:20060403

Oh the excludes ! Thanks Anita. Yes, I have to update that so that
this new dir doesn't get included in the m1 build.

The new dir doesn't have a project.xml. So I wonder if it would still
gets included (if we don't specifically exclude it) in a m1 build.

The new console dir structure will be in the HEAD and work only with
M2. M1 builds will remain untouched.

Cheers
Prasad.



On 4/3/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote:
>  The project.properties file is used to define the 'includes' and
> 'excludes' for m1 build :
>
> maven.geronimo.applications.includes=\
> applications/*/project.xml,\
> applications/daytrader/*/project.xml
>
> Thanks
> Anita
> --- Prasad Kashyap <[EMAIL PROTECTED]> wrote:
>
> > I'm sorry. I didn't get that.  project.properties in m2 ?
> >
> > Cheers
> > Prasad
> >
> > On 4/3/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote:
> > > +1
> > > If you have not done it already, please update
> > project.properties
> > > at the top level.
> > >
> > > Thanks
> > > Anita
> > >
> > > --- Prasad Kashyap <[EMAIL PROTECTED]> wrote:
> > >
> > > > Last week Aaron, Joe, Paul and I discussed on IRC the intent to
> > > > restructure the src dirs of the console under the application
> > > > directory.
> > > > (http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20060330)
> > > >
> > > > Geronimo-1660
> > (http://issues.apache.org/jira/browse/GERONIMO-1660)
> > > > will seek to achieve this. Just wanted to send this out to the
> > larger
> > > > community before we commit the patch.
> > > >
> > > > Currently, the console is made up of 4 dirs under applications
> > > > - geronimo
> > > >   -  applications
> > > >  + console-core
> > > >  + console-ear
> > > >  + console-standard
> > > >  + console-framework
> > > >
> > > > The new structure will be as follows
> > > > - geronimo
> > > >   -  applications
> > > >  - console   <<---  new dir added here. existing console
> > > > sub-dirs moved under this.
> > > > + console-core
> > > > + console-ear
> > > > + console-standard
> > > > + console-framework
> > > >
> > > > This will keep all the console dirs in one place. As the console
> > > > grows
> > > > to add more components/directories, it won't clutter up the
> > > > applications dir.
> > > >
> > > > Comments welcome.
> > > >
> > > > Cheers
> > > > Prasad
> > > >
> > >
> > >
> > > __
> > > Do You Yahoo!?
> > > Tired of spam?  Yahoo! Mail has the best spam protection around
> > > http://mail.yahoo.com
> > >
> >
>
>
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>

Re: svn commit: r391214 - /geronimo/trunk/configs/client-deployer/project.xml

2006-04-03 Thread Aaron Mulder

Thanks for putting in the fix.  But I do wonder why is this one is
still one 3.2.1...?

Aaron

On 4/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Author: chirino
> Date: Mon Apr  3 19:42:50 2006
> New Revision: 391214
>
> URL: http://svn.apache.org/viewcvs?rev=391214&view=rev
> Log:
> added missing dependencies (would only notice if you were doing a build with 
> a clean repo)
>
> Modified:
> geronimo/trunk/configs/client-deployer/project.xml
>
> Modified: geronimo/trunk/configs/client-deployer/project.xml
> URL: 
> http://svn.apache.org/viewcvs/geronimo/trunk/configs/client-deployer/project.xml?rev=391214&r1=391213&r2=391214&view=diff
> ==
> --- geronimo/trunk/configs/client-deployer/project.xml (original)
> +++ geronimo/trunk/configs/client-deployer/project.xml Mon Apr  3 19:42:50 
> 2006
> @@ -335,6 +335,22 @@
>  ${wadi_activecluster_version}
>  
>
> +
> +axion
> +axion
> +1.0-M3-dev
> +
> +
> +activemq
> +activemq-core
> +3.2.1
> +
> +
> +commons-primitives
> +commons-primitives
> +1.0
> +
> +
>  
>  
>
>
>
>

Re: Restructuring the console src dirs

2006-04-03 Thread anita kulshreshtha

 The project.properties file is used to define the 'includes' and
'excludes' for m1 build :

maven.geronimo.applications.includes=\
applications/*/project.xml,\
applications/daytrader/*/project.xml

Thanks
Anita
--- Prasad Kashyap <[EMAIL PROTECTED]> wrote:

> I'm sorry. I didn't get that.  project.properties in m2 ?
> 
> Cheers
> Prasad
> 
> On 4/3/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote:
> > +1
> > If you have not done it already, please update
> project.properties
> > at the top level.
> >
> > Thanks
> > Anita
> >
> > --- Prasad Kashyap <[EMAIL PROTECTED]> wrote:
> >
> > > Last week Aaron, Joe, Paul and I discussed on IRC the intent to
> > > restructure the src dirs of the console under the application
> > > directory.
> > > (http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20060330)
> > >
> > > Geronimo-1660
> (http://issues.apache.org/jira/browse/GERONIMO-1660)
> > > will seek to achieve this. Just wanted to send this out to the
> larger
> > > community before we commit the patch.
> > >
> > > Currently, the console is made up of 4 dirs under applications
> > > - geronimo
> > >   -  applications
> > >  + console-core
> > >  + console-ear
> > >  + console-standard
> > >  + console-framework
> > >
> > > The new structure will be as follows
> > > - geronimo
> > >   -  applications
> > >  - console   <<---  new dir added here. existing console
> > > sub-dirs moved under this.
> > > + console-core
> > > + console-ear
> > > + console-standard
> > > + console-framework
> > >
> > > This will keep all the console dirs in one place. As the console
> > > grows
> > > to add more components/directories, it won't clutter up the
> > > applications dir.
> > >
> > > Comments welcome.
> > >
> > > Cheers
> > > Prasad
> > >
> >
> >
> > __
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
> >
> 


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

Re: Geronimo JDK 1.5 Status

Without going through this with a fine tooth comb, this has more-or-less
been my experience as well.

Aaron Mulder wrote:
> I've heard a bit of misinformation floating around, and I'm not 100%
> sure I have the full picture, so I want to see if everyone agrees on
> these basic facts:
> 
> 1) Geronimo is not certified on JDK 1.5, and will not be until we have
> a JDK-portable CORBA implementation (e.g. Yoko)
> 
> 2) There are 2 features of Geronimo 1.x that don't work under JDK 1.5
> (and *everything else* works perfectly):
>  - CORBA (EJBs exposed via CORBA & references to remote CORBA EJBs)
>  - Instances of javax.xml.namespace.QName serialized under JDK 1.4 and
> deserialized under JDK 1.5
> 
> 3) Geronimo ships with CORBA disabled by default, so that is not a
> problem for the out-of-box Geronimo configuration.
> 
> 4) Geronimo 1.0 ships with the DayTrader sample application which uses
> serialized QNames, and therefore fails to start under Geronimo 1.0
> with JDK 1.5
> 
> 5) In conclusion, to run Geronimo 1.0 under JDK 1.5, make sure to
> undeploy the DayTrader sample application and don't turn on CORBA and
> everything will work fine.
> 
> Is that right?
> 
> Thanks,
> Aaron

I believe that list is accurate Aaron. I'd like to talk about not shipping with DayTrader installed
for 1.1. This will reduce our footprint and eliminate the QName problem we have. It would be nice
to have the auto install stuff you did to pull down the samples and install them but don't know how
hard that would be to integrate into 1.1.

The only other item someone might have is if they deploy any applications that use the QName when
running on 1.5 and then try to start under 1.4 (or vice versa).

Matt

Aaron Mulder wrote:

I've heard a bit of misinformation floating around, and I'm not 100%
sure I have the full picture, so I want to see if everyone agrees on
these basic facts:

1) Geronimo is not certified on JDK 1.5, and will not be until we have
a JDK-portable CORBA implementation (e.g. Yoko)

2) There are 2 features of Geronimo 1.x that don't work under JDK 1.5
(and *everything else* works perfectly):
- CORBA (EJBs exposed via CORBA & references to remote CORBA EJBs)
- Instances of javax.xml.namespace.QName serialized under JDK 1.4 and
deserialized under JDK 1.5

3) Geronimo ships with CORBA disabled by default, so that is not a
problem for the out-of-box Geronimo configuration.

4) Geronimo 1.0 ships with the DayTrader sample application which uses
serialized QNames, and therefore fails to start under Geronimo 1.0
with JDK 1.5

5) In conclusion, to run Geronimo 1.0 under JDK 1.5, make sure to
undeploy the DayTrader sample application and don't turn on CORBA and
everything will work fine.

Is that right?

Thanks,
Aaron

Re: Restructuring the console src dirs

I'm sorry. I didn't get that.  project.properties in m2 ?

Cheers
Prasad

On 4/3/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote:
> +1
> If you have not done it already, please update project.properties
> at the top level.
>
> Thanks
> Anita
>
> --- Prasad Kashyap <[EMAIL PROTECTED]> wrote:
>
> > Last week Aaron, Joe, Paul and I discussed on IRC the intent to
> > restructure the src dirs of the console under the application
> > directory.
> > (http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20060330)
> >
> > Geronimo-1660 (http://issues.apache.org/jira/browse/GERONIMO-1660)
> > will seek to achieve this. Just wanted to send this out to the larger
> > community before we commit the patch.
> >
> > Currently, the console is made up of 4 dirs under applications
> > - geronimo
> >   -  applications
> >  + console-core
> >  + console-ear
> >  + console-standard
> >  + console-framework
> >
> > The new structure will be as follows
> > - geronimo
> >   -  applications
> >  - console   <<---  new dir added here. existing console
> > sub-dirs moved under this.
> > + console-core
> > + console-ear
> > + console-standard
> > + console-framework
> >
> > This will keep all the console dirs in one place. As the console
> > grows
> > to add more components/directories, it won't clutter up the
> > applications dir.
> >
> > Comments welcome.
> >
> > Cheers
> > Prasad
> >
>
>
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>

Geronimo JDK 1.5 Status

2006-04-03 Thread Aaron Mulder

I've heard a bit of misinformation floating around, and I'm not 100%
sure I have the full picture, so I want to see if everyone agrees on
these basic facts:

1) Geronimo is not certified on JDK 1.5, and will not be until we have
a JDK-portable CORBA implementation (e.g. Yoko)

2) There are 2 features of Geronimo 1.x that don't work under JDK 1.5
(and *everything else* works perfectly):
 - CORBA (EJBs exposed via CORBA & references to remote CORBA EJBs)
 - Instances of javax.xml.namespace.QName serialized under JDK 1.4 and
deserialized under JDK 1.5

3) Geronimo ships with CORBA disabled by default, so that is not a
problem for the out-of-box Geronimo configuration.

4) Geronimo 1.0 ships with the DayTrader sample application which uses
serialized QNames, and therefore fails to start under Geronimo 1.0
with JDK 1.5

5) In conclusion, to run Geronimo 1.0 under JDK 1.5, make sure to
undeploy the DayTrader sample application and don't turn on CORBA and
everything will work fine.

Is that right?

Thanks,
Aaron

[jira] Updated: (GERONIMO-1722) Module migration to Maven 2: activemq-embedded-rar

2006-04-03 Thread Andrew Steeley (JIRA)

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

Andrew Steeley updated GERONIMO-1722:
-

Attachment: GERONIMO-1722.patch

A patch for the M2 pom that explicitly excludes dependencies for the ActiveMQ 
modules.  I wish there was a way to exclude all transitive dependencies of a 
given dependency, but if there is I dunno it.

> Module migration to Maven 2: activemq-embedded-rar
> --
>
>  Key: GERONIMO-1722
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1722
>  Project: Geronimo
> Type: Sub-task
> Security: public(Regular issues) 
>   Components: ActiveMQ
> Versions: 1.x
> Reporter: Jacek Laskowski
> Assignee: Andrew Steeley
>  Attachments: GERONIMO-1722.patch
>
> It's a task to help keep track of the progress of the module build migration 
> to Maven2

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Restructuring the console src dirs

2006-04-03 Thread anita kulshreshtha

+1 
If you have not done it already, please update project.properties
at the top level.

Thanks
Anita

--- Prasad Kashyap <[EMAIL PROTECTED]> wrote:

> Last week Aaron, Joe, Paul and I discussed on IRC the intent to
> restructure the src dirs of the console under the application
> directory.
> (http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20060330)
> 
> Geronimo-1660 (http://issues.apache.org/jira/browse/GERONIMO-1660)
> will seek to achieve this. Just wanted to send this out to the larger
> community before we commit the patch.
> 
> Currently, the console is made up of 4 dirs under applications
> - geronimo
>   -  applications
>  + console-core
>  + console-ear
>  + console-standard
>  + console-framework
> 
> The new structure will be as follows
> - geronimo
>   -  applications
>  - console   <<---  new dir added here. existing console
> sub-dirs moved under this.
> + console-core
> + console-ear
> + console-standard
> + console-framework
> 
> This will keep all the console dirs in one place. As the console
> grows
> to add more components/directories, it won't clutter up the
> applications dir.
> 
> Comments welcome.
> 
> Cheers
> Prasad
> 


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

Re: Restructuring the console src dirs

Jason, yes it will.

On 4/3/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
> +1
>
> Is console/ going to get a pom.xml for m2?
>
> --jason
>
> -Original Message-
> From: "Prasad Kashyap" <[EMAIL PROTECTED]>
> Date: Mon, 3 Apr 2006 10:42:28
> To:dev@geronimo.apache.org
> Subject: Restructuring the console src dirs
>
> Last week Aaron, Joe, Paul and I discussed on IRC the intent to
> restructure the src dirs of the console under the application
> directory. (http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20060330)
>
> Geronimo-1660 (http://issues.apache.org/jira/browse/GERONIMO-1660)
> will seek to achieve this. Just wanted to send this out to the larger
> community before we commit the patch.
>
> Currently, the console is made up of 4 dirs under applications
> - geronimo
>   -  applications
>  + console-core
>  + console-ear
>  + console-standard
>  + console-framework
>
> The new structure will be as follows
> - geronimo
>   -  applications
>  - console   <<---  new dir added here. existing console
> sub-dirs moved under this.
> + console-core
> + console-ear
> + console-standard
> + console-framework
>
> This will keep all the console dirs in one place. As the console grows
> to add more components/directories, it won't clutter up the
> applications dir.
>
> Comments welcome.
>
> Cheers
> Prasad
>

[jira] Closed: (GERONIMO-1799) SPECjAppServer2004 Deployment Descriptors

2006-04-03 Thread Matt Hogstrom (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1799?page=all ]
 
Matt Hogstrom closed GERONIMO-1799:
---

Resolution: Incomplete

Closed at user request.

> SPECjAppServer2004 Deployment Descriptors
> -
>
>  Key: GERONIMO-1799
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1799
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
> Reporter: Vasily Zakharov

>
> Here're the deployment descriptors I'm trying to use to deploy the 
> SPECjAppServer2004 benchmark.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Release 1.1 Schedule and To Dos

2006-04-03 Thread Matt Hogstrom

First off, thanks to Dain and David for the hours of work it took to improve the config issues
discovered in 1.0. Unfortunately, you saved the human race from certain destruction but because you
were so adept most users probably won't notice. So from our side thanks for the hours you guys put
in to address this.

Looks like the majority of the server work has been completed and the server now build, starts and
can run DayTrader. I'd like to get 1.1 out by April 28th so we can announce it on May 1st. If we
can do it earlier then all the better. Of course this all depends on several factors.

1. When do we ship the 1.1?
1. How many things do we put into 1.1?
2. How long it takes to pass CTS?
3. Who has time and energy to get 1.1 out the door?

For question 1 I propose a straw man date for freezing the branch as 23:59 PST on 4/14. This gives
us approximately two weeks to get bug fixes, features and other stuff into 1.1. After that its no
changes unless they're fixing the build. Binaries are to be complete on 4/28 and on the apache
Server signed sealed and ready for download. We'll announce on 5/1 that 1.1 is available. Please
let's coordinate announcements through the Release Manager (me :) so we don't have another
availability announcement go out with no deliverable.

To answer question number 2 I have a proposed list of content for 1.1. This includes bug fixes,
feature improvements, and CTS.

Next, for question number 2 there are the bug fixes, improvements, etc. At the end of this e-mail
are the items from JIRA currently targeted for 1.1. I have sorted them by category (bugs,
improvements, features, etc.) and included who currently has the JIRA assigned to them. Please take
a few minutes and review the list. If you can get this item fixed for 1.1 then that's excellent. If
you can't please either move the item to a new release or unassign it from yourself so someone else
can take it. I'll start moving unassigned items out of 1.1. It you feel it is a must fix but can't
do it then speak up.

I think we need to be able to tolerate (if not flat out certify on) JDK 1.5. This was the number
one item users are asking for. If we can't certify then we should at least note that RMI isn't
supported. I'm researching the issue related to QName and serialization between 1.4 and 1.5.

Next, we need some volunteers to coordinate the CTS activity. I think Kevan has been working on
this but I expect a few more volunteers would be helpful.

So, when we deliver 1.1 by May 1st we'll be on a 4 month release schedule. Let me know your
feedback and thoughts.

*J I R A I T E M S*

*Bugs*
*GERONIMO-1426*
Aaron Mulder
DatabasePoolPortlet gets NPE when saving

*GERONIMO-1451*
Aaron Mulder
A new TCP listener for ActiveMQ is not persisting across server startups

*GERONIMO-1503*
Aaron Mulder
keystore generated by KeyStore portlet could not be used to add either Jetty or
Tomcat HTTPS Listeners

*GERONIMO-1506*
Aaron Mulder
DB info portlet should use new GeronimoVersion

*GERONIMO-1472*
David Jencks
packaging plugin creates client cars with wrong version

*GERONIMO-1599*
David Jencks
HOWLLog throws NPE because XidFactory is missing

*GERONIMO-1475*
Donald Woods
Configs needing updated to not include Xerces files in the Repository as
duplicates to lib\endorsed

*GERONIMO-1476*
Donald Woods
Changes to default log4j.rootCategory are not dynamic

*GERONIMO-1791*
Donald Woods
LDAP Security Realm created via Console can fail deployment

*GERONIMO-1759*
Paul McMahan
getConsoleFrameworkServletPath broken

*GERONIMO-1410*
Unassigned
Configuration geronimo/jetty/1.0-SNAPSHOT/car defines Spring Framework - Hibernate based Web-app do
not work

*GERONIMO-1417*
Unassigned
[daytrader] daytrader/docs/tradeFAQ.html out of date

*GERONIMO-1423*
Unassigned
log4j.properties's category is ignored

*GERONIMO-1491*
Unassigned
ActiveMQ plan uses hardcoded obsolete org/apache/geronimo/ActiveMQ module name

*GERONIMO-1492*
Unassigned
Many "org/apache/geronimo" configIds still live in source tree

*GERONIMO-1510*
Unassigned
NPE in connector DConfigBeans if no config params present on connection
definition instance

*GERONIMO-1567*
Unassigned
Plan XML files aren't included in Geronimo distributions (was included in M5
release)

*GERONIMO-1579*
Unassigned
NPE while deploying EJB as Web Service

*GERONIMO-1580*
Unassigned
Better error message for missing WSDL file for EJB web service

*GERONIMO-1581*
Unassigned
webservices.xml and values can't start with /

*GERONIMO-1582*
Unassigned
NPE for EJB webservices.xml with bad

*GERONIMO-1583*
Unassigned
Servlet web service is created once and destroyed many times

*GERONIMO-1584*
Unassigned
Servlet web service WSDL mangling ha

[jira] Closed: (GERONIMO-1466) Preparing 1.0 branch for development of 1.0.1

2006-04-03 Thread Matt Hogstrom (JIRA)

 [ http://issues.apache.org/jira/browse/GERONIMO-1466?page=all ]
 
Matt Hogstrom closed GERONIMO-1466:
---

Resolution: Fixed

> Preparing 1.0 branch for development of 1.0.1
> -
>
>  Key: GERONIMO-1466
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1466
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
>  Environment: All
> Reporter: Matt Hogstrom
> Assignee: Matt Hogstrom
>  Fix For: 1.1

>
> Update the 1.0 Branch with the changes to prepare it for 1.0.1
> This JIRA will be used to track all changes required to version for 1.0.1 so 
> moving from SNAPSHOT to a release will be a bit simpler.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1800) SPECjAppServer2004 Deployment Descriptors

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

Vasily Zakharov updated GERONIMO-1800:
--

Attachment: specj2004-deployment-plan.xml

SPECjAppServer2004 application DD

> SPECjAppServer2004 Deployment Descriptors
> -
>
>  Key: GERONIMO-1800
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1800
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
> Reporter: Vasily Zakharov
>  Attachments: specdb.xml, specj2004-deployment-plan.xml, specjms.xml
>
> Here're the deployment descriptors I'm trying to use to deploy the 
> SPECjAppServer2004 benchmark.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1800) SPECjAppServer2004 Deployment Descriptors

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

Vasily Zakharov updated GERONIMO-1800:
--

Attachment: specjms.xml

JMS connector DD

> SPECjAppServer2004 Deployment Descriptors
> -
>
>  Key: GERONIMO-1800
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1800
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
> Reporter: Vasily Zakharov
>  Attachments: specdb.xml, specj2004-deployment-plan.xml, specjms.xml
>
> Here're the deployment descriptors I'm trying to use to deploy the 
> SPECjAppServer2004 benchmark.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-1800) SPECjAppServer2004 Deployment Descriptors

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

Vasily Zakharov updated GERONIMO-1800:
--

Attachment: specdb.xml

Derby database connector DD

> SPECjAppServer2004 Deployment Descriptors
> -
>
>  Key: GERONIMO-1800
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1800
>  Project: Geronimo
> Type: Task
> Security: public(Regular issues) 
> Reporter: Vasily Zakharov
>  Attachments: specdb.xml
>
> Here're the deployment descriptors I'm trying to use to deploy the 
> SPECjAppServer2004 benchmark.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1800) SPECjAppServer2004 Deployment Descriptors

SPECjAppServer2004 Deployment Descriptors
-

 Key: GERONIMO-1800
 URL: http://issues.apache.org/jira/browse/GERONIMO-1800
 Project: Geronimo
Type: Task
Security: public (Regular issues) 
Reporter: Vasily Zakharov


Here're the deployment descriptors I'm trying to use to deploy the 
SPECjAppServer2004 benchmark.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-1799) SPECjAppServer2004 Deployment Descriptors

SPECjAppServer2004 Deployment Descriptors
-

 Key: GERONIMO-1799
 URL: http://issues.apache.org/jira/browse/GERONIMO-1799
 Project: Geronimo
Type: Task
Security: public (Regular issues) 
Reporter: Vasily Zakharov


Here're the deployment descriptors I'm trying to use to deploy the 
SPECjAppServer2004 benchmark.


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: Restructuring the console src dirs

2006-04-03 Thread Jason Dillon

+1 

Is console/ going to get a pom.xml for m2?

--jason

-Original Message-
From: "Prasad Kashyap" <[EMAIL PROTECTED]>
Date: Mon, 3 Apr 2006 10:42:28 
To:dev@geronimo.apache.org
Subject: Restructuring the console src dirs

Last week Aaron, Joe, Paul and I discussed on IRC the intent to
restructure the src dirs of the console under the application
directory. (http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20060330)

Geronimo-1660 (http://issues.apache.org/jira/browse/GERONIMO-1660)
will seek to achieve this. Just wanted to send this out to the larger
community before we commit the patch.

Currently, the console is made up of 4 dirs under applications
- geronimo
  -  applications
 + console-core
 + console-ear
 + console-standard
 + console-framework

The new structure will be as follows
- geronimo
  -  applications
 - console   <<---  new dir added here. existing console
sub-dirs moved under this.
+ console-core
+ console-ear
+ console-standard
+ console-framework

This will keep all the console dirs in one place. As the console grows
to add more components/directories, it won't clutter up the
applications dir.

Comments welcome.

Cheers
Prasad

Re: Geronimo Documentation update - hibernate migration

As usual...nice work Hernan!

Hernan Cunico wrote:
> Hi All,
> here is a doc update for migrating apps using Hibermate.
> 
> http://opensource.atlassian.com/confluence/oss/display/GERONIMO/JBoss+to+Geronimo+-+Hibernate+Migration
> 
> 
> As usual, comments/suggestions are welcome :)
> 
> Cheers!
> Hernan

Geronimo Documentation update - hibernate migration

2006-04-03 Thread Hernan Cunico


Hi All,
here is a doc update for migrating apps using Hibermate.

http://opensource.atlassian.com/confluence/oss/display/GERONIMO/JBoss+to+Geronimo+-+Hibernate+Migration

As usual, comments/suggestions are welcome :)

Cheers!
Hernan

Re: [continuum] BUILD FAILURE: Geronimo

2006-04-03 Thread Kevan Miller



On Apr 3, 2006, at 1:00 PM, Jacek Laskowski wrote:


On 4/3/06, continuum <[EMAIL PROTECTED]> wrote:
Online report : http://ci.gbuild.org/continuum/servlet/continuum/ 
target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/1880

Build statistics:
  State: Failed


How can I know what has caused it? The only way as I see is to log
into the server Continuum is running on and look at the log file. The
complete log file doesn't seem to show up in the browser. Does anyone
know why? And, who could let me in to the server? I could probably be
of help sometimes ;)


Hi Jacek,
You'd need a login onto the GBuild machines -- in particular  
stan.gbuild.org. Seems like you and I discussed this previously.  
You'll need to check with David Blevins.


I this case, I think I can tell you what's going on (since i applied  
the patch). Commonj timer junit tests have some configuration values  
for running tests. I reduced some of the times to speed up build  
times (2 minutes down to 30 seconds). The tests aren't completely  
deterministic. Quite possible that I made some of the tolerances too  
tight -- I haven't had any build problems locally. I'll take a look  
at this later today...


--kevan



Jacek

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

Re: [VOTE] ActiveMQ 4.0 RC2

2006-04-03 Thread Bruce Snyder

On 4/3/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> Hi Guys,
>
> This RC1 failed to pass incubator approval.  There was a small issue
> with some of the logging message produced on start up.  So I've done a
> new RC2 release from trunk and has all the latest bug fixes.
>
> I've posted it here:
> http://people.apache.org/~chirino/incubator-activemq-4.0-RC2/
> I've tagged the source for that build as:
> https://svn.apache.org/repos/asf/incubator/activemq/tags/activemq-4.0-RC2/activemq
>
>
> [ ] +1 Release the binary as ActiveMQ 4.0-RC2
> [ ] -1 Veto the release (provide specific comments)

+1

Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL 
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://geronimo.apache.org/)

Castor (http://castor.org/)

Re: What about moving applications into its own source tree?

2006-04-03 Thread Matt Hogstrom

Here are some additional thoughts.  I think the console would stay as Paul 
indicated as well as the jmxdebug (isn't there a better version out there? 
Simon?)  Not sure about the UDDI stuff.


Here is what might remain:

drwxr-xr-x   11 hogstrom  hogstrom   374 Mar 17 11:20 console-core
drwxr-xr-x   11 hogstrom  hogstrom   374 Mar 17 11:21 console-ear
drwxr-xr-x   11 hogstrom  hogstrom   374 Mar 28 10:52 console-framework
drwxr-xr-x   11 hogstrom  hogstrom   374 Mar 28 10:52 console-standard
drwxr-xr-x   14 hogstrom  hogstrom   476 Apr  2 16:23 jmxdebug
drwxr-xr-x   14 hogstrom  hogstrom   476 Apr  2 16:23 remote-deploy
drwxr-xr-x   14 hogstrom  hogstrom   476 Apr  2 16:23 remote-deploy-lib
drwxr-xr-x   12 hogstrom  hogstrom   408 Apr  2 16:23 uddi-db
drwxr-xr-x   14 hogstrom  hogstrom   476 Apr  2 16:23 uddi-server

Already moving out
drwxr-xr-x   17 hogstrom  hogstrom   578 Mar 28 10:52 daytrader

Should move out to samples someplace
drwxr-xr-x   18 hogstrom  hogstrom   612 Apr  2 16:23 magicGball
drwxr-xr-x   14 hogstrom  hogstrom   476 Apr  2 16:23 demo
drwxr-xr-x   12 hogstrom  hogstrom   408 Apr  2 16:23 ldap-realm-demo
drwxr-xr-x   14 hogstrom  hogstrom   476 Apr  2 16:23 welcome

Paul McMahan wrote:

Hi Jacek,  since the console application is so intricately tied to the
kernel and deployment APIs and since it is also an important part of
the resulting assemblies I think it would be best to keep at least
that one application in the same repository as the application server.

Best wishes,
Paul

On 4/2/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote:


Hi,

While migrating the applications to M2 I came up with the idea to move
that directory to its own repository, just like daytrader or devtools,
off Geronimo the application server tree. What do you think?

Jacek

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

Re: Restructuring the console src dirs

2006-04-03 Thread Matt Hogstrom


+1

Matt

Prasad Kashyap wrote:

Last week Aaron, Joe, Paul and I discussed on IRC the intent to
restructure the src dirs of the console under the application
directory. (http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20060330)

Geronimo-1660 (http://issues.apache.org/jira/browse/GERONIMO-1660)
will seek to achieve this. Just wanted to send this out to the larger
community before we commit the patch.

Currently, the console is made up of 4 dirs under applications
- geronimo
  -  applications
 + console-core
 + console-ear
 + console-standard
 + console-framework

The new structure will be as follows
- geronimo
  -  applications
 - console   <<---  new dir added here. existing console
sub-dirs moved under this.
+ console-core
+ console-ear
+ console-standard
+ console-framework

This will keep all the console dirs in one place. As the console grows
to add more components/directories, it won't clutter up the
applications dir.

Comments welcome.

Cheers
Prasad

Re: setPersistenceFactory() on BrokerService

2006-04-03 Thread ErinO


Thank you very much.

We have our own proprietary system for message persistence, the
DefaultPersistenceAdapterFactory won't do, so we have to write our own, but
it will use Journal too for performance.

Thanks.

Erin
--
View this message in context: 
http://www.nabble.com/setPersistenceFactory%28%29-on-BrokerService-t1388212.html#a3730839
Sent from the ActiveMQ - Dev forum at Nabble.com.

Re: 1.1 build problem with Daytrader config - rev 390949

2006-04-03 Thread Dain Sundstrom


Should be fixed now.

-dain

On Apr 3, 2006, at 5:38 AM, Kevan Miller wrote:



On Apr 3, 2006, at 2:25 AM, John Sisson wrote:

I tried building 1.1 on Solaris and got the following error (note  
the FileNotFoundException at the bottom):


I read on IRC that DayTrader was working on 1.1, are there changes  
that haven't been committed?


Hi John,
The problem isn't specific to DayTrader. Aaron reported a similar  
problem on Saturday (a Junit test failure). Continuum build of  
Geronimo 1.1 on Gbuild have also been failing.


However, I built successfully last night on current sources (Mac  
OSX). So, it doesn't look like we're dealing with a straight- 
forward bug.


--kevan



John

+
| configurations Daytrader using derby deployed on jetty
| Memory: 46M/66M
+
DEPRECATED: the default goal should be specified in the   
section of project.xml instead of maven.xml
DEPRECATED: the default goal should be specified in the   
section of project.xml instead of maven.xml


build:end:

Attempting to download geronimo-daytrader-derby-db-1.1-SNAPSHOT.jar.
Attempting to download daytrader-ear-1.1-SNAPSHOT.ear.
build:start:

multiproject:install-callback:
   [echo] Running car:install for Daytrader using derby deployed  
on jetty


   Packaging configuration /home/sissonj/OpenSourceJava/asf/ 
geronimo/branches/1.1/configs/daytrader-jetty/target/plan/plan.xml


Retrieving document at 'WEB-INF/wsdl/TradeServices.wsdl'.
Retrieving document at 'META-INF/wsdl/TradeServices.wsdl'.
118443 [main] ERROR  
org.apache.geronimo.plugin.packaging.PackageBuilder -  
org.apache.geronimo.common.DeploymentException: Could not write  
out class bytes
org.apache.geronimo.common.DeploymentException: Could not write  
out class bytes
   at  
org.apache.geronimo.axis.builder.AxisBuilder.createServiceInterfacePr 
oxy(AxisBuilder.java:229)
   at  
org.apache.geronimo.axis.builder.AxisBuilder.createService 
(AxisBuilder.java:202)
   at  
org.apache.geronimo.axis.builder.AxisBuilder.createService 
(AxisBuilder.java:184)
   at org.apache.geronimo.axis.builder.AxisBuilder$ 
$FastClassByCGLIB$$16a52a9a.invoke()

   at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
   at  
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke 
(FastMethodInvoker.java:38)
   at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke 
(GBeanOperation.java:122)
   at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke 
(GBeanInstance.java:813)
   at org.apache.geronimo.gbean.runtime.RawInvoker.invoke 
(RawInvoker.java:57)
   at  
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke 
(RawOperationInvoker.java:35)
   at  
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept 
(ProxyMethodInterceptor.java:96)
   at  
org.apache.geronimo.j2ee.deployment.ServiceReferenceBuilder$ 
$EnhancerByCGLIB$$6d9b44d1.createService()
   at  
org.apache.geronimo.j2ee.deployment.RefContext.getServiceReference 
(RefContext.java:88)
   at  
org.apache.geronimo.naming.deployment.ENCConfigBuilder.addServiceRefs 
(ENCConfigBuilder.java:494)
   at  
org.apache.geronimo.naming.deployment.ENCConfigBuilder.buildComponent 
Context(ENCConfigBuilder.java:695)
   at  
org.apache.geronimo.client.builder.AppClientModuleBuilder.buildCompon 
entContext(AppClientModuleBuilder.java:584)
   at  
org.apache.geronimo.client.builder.AppClientModuleBuilder.addGBeans 
(AppClientModuleBuilder.java:443)
   at org.apache.geronimo.client.builder.AppClientModuleBuilder 
$$FastClassByCGLIB$$93137659.invoke()

   at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
   at  
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke 
(FastMethodInvoker.java:38)
   at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke 
(GBeanOperation.java:122)
   at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke 
(GBeanInstance.java:813)
   at org.apache.geronimo.gbean.runtime.RawInvoker.invoke 
(RawInvoker.java:57)
   at  
org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke 
(RawOperationInvoker.java:35)
   at  
org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept 
(ProxyMethodInterceptor.java:96)
   at org.apache.geronimo.j2ee.deployment.ModuleBuilder$ 
$EnhancerByCGLIB$$ca001ccb.addGBeans()
   at  
org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfigurati 
on(EARConfigBuilder.java:434)
   at org.apache.geronimo.j2ee.deployment.EARConfigBuilder$ 
$FastClassByCGLIB$$38e56ec6.invoke()

   at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53)
   at  
org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke 
(FastMethodInvoker.java:38)
   at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke 
(GBeanOperation.java:122)
   at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke 
(GBeanInstance.java:813)
   at org.apache.ger

setPersistenceFactory() on BrokerService

2006-04-03 Thread ErinO


Hi,

We have our own implementation for PersistenceAdapterFactory interface, but
couldn't be able to use it through BrokerService, in BrokerService class the
setPersistenceFactory() method takes a DefaultPersistenceAdapterFactory as
in parameter rather than PersistenceAdapterFactory interface. Should it take
a interface as in parameter instead?

We could workaround the problem by deriving our class from
DefaultPersistenceAdapterFactory, but in DefaultPersistenceAdapterFactory,
all the member variables are private, we cannot reuse them, we have to
redeclare them again in our implementation in order to use them (say journal
stuff), which doesn't look pretty. 

Any suggestions?

Thanks

Erin
Thanks.

Erin
--
View this message in context: 
http://www.nabble.com/setPersistenceFactory%28%29-on-BrokerService-t1388212.html#a3729762
Sent from the ActiveMQ - Dev forum at Nabble.com.

Re: Restructuring the console src dirs

Paul,

The top level goals cascade down the different dir levels. So that
shouldn't be a worry.

When we hit the assemblies and configs migration, we'll look out for a
similar pattern and see if we can use the same approach. Thanks for
bringing this to our attention.

Cheers
Prasad

On 4/3/06, Paul McMahan <[EMAIL PROTECTED]> wrote:
> Sounds like a good idea. Thanks for the heads up. One item (you may
> have already thought of) is that some of the top level maven goals
> that recurse into the applications subdirectory may need to be updated
> if you add this additional directory level (clean, eclipse, idea,
> etc).  Or this might work for free with maven, I don't know.  Also,
> have you thought about also using a similar approach to partition the
> jetty/tomcat configs and assemblies?  Seems cleaner than using
> *-tomcat or *-jetty directory names.  Just a thought.
>
> Best wishes,
> Paul
>
>
> On 4/3/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote:
> > Last week Aaron, Joe, Paul and I discussed on IRC the intent to
> > restructure the src dirs of the console under the application
> > directory. (http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20060330)
> >
> > Geronimo-1660 (http://issues.apache.org/jira/browse/GERONIMO-1660)
> > will seek to achieve this. Just wanted to send this out to the larger
> > community before we commit the patch.
> >
> > Currently, the console is made up of 4 dirs under applications
> > - geronimo
> >   -  applications
> >  + console-core
> >  + console-ear
> >  + console-standard
> >  + console-framework
> >
> > The new structure will be as follows
> > - geronimo
> >   -  applications
> >  - console   <<---  new dir added here. existing console
> > sub-dirs moved under this.
> > + console-core
> > + console-ear
> > + console-standard
> > + console-framework
> >
> > This will keep all the console dirs in one place. As the console grows
> > to add more components/directories, it won't clutter up the
> > applications dir.
> >
> > Comments welcome.
> >
> > Cheers
> > Prasad
> >
>

[jira] Commented: (GERONIMO-1660) Application migration to Maven 2: Console

2006-04-03 Thread Prasad Kashyap (JIRA)

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

Prasad Kashyap commented on GERONIMO-1660:
--

Jacek, good idea. I now have the community support us on this initiative. 
http://www.mail-archive.com/dev@geronimo.apache.org/msg19959.html

Now let me look into the duplication of content problem in the patch.

> Application migration to Maven 2: Console
> -
>
>  Key: GERONIMO-1660
>  URL: http://issues.apache.org/jira/browse/GERONIMO-1660
>  Project: Geronimo
> Type: Sub-task
> Security: public(Regular issues) 
>   Components: buildsystem, console
> Versions: 1.2
> Reporter: Prasad Kashyap
> Assignee: Prasad Kashyap
>  Attachments: console.zip, geronimo-pom.patch
>
> The console-web module seems to be obsolete. It should be removed. The 
> console application is contained by the 3 components under the applications 
> dir.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira

Re: [continuum] BUILD FAILURE: Geronimo

2006-04-03 Thread Jacek Laskowski

On 4/3/06, continuum <[EMAIL PROTECTED]> wrote:
> Online report : 
> http://ci.gbuild.org/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/1/buildId/1880
> Build statistics:
>   State: Failed

How can I know what has caused it? The only way as I see is to log
into the server Continuum is running on and look at the log file. The
complete log file doesn't seem to show up in the browser. Does anyone
know why? And, who could let me in to the server? I could probably be
of help sometimes ;)

Jacek

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

Re: [VOTE] ActiveMQ 4.0 RC2

2006-04-03 Thread Dain Sundstrom


+1 Release the binary as ActiveMQ 4.0-RC2

-dain

On Apr 3, 2006, at 9:19 AM, Hiram Chirino wrote:


Hi Guys,

This RC1 failed to pass incubator approval.  There was a small issue
with some of the logging message produced on start up.  So I've done a
new RC2 release from trunk and has all the latest bug fixes.

I've posted it here:
http://people.apache.org/~chirino/incubator-activemq-4.0-RC2/
I've tagged the source for that build as:
https://svn.apache.org/repos/asf/incubator/activemq/tags/ 
activemq-4.0-RC2/activemq



[ ] +1 Release the binary as ActiveMQ 4.0-RC2
[ ] -1 Veto the release (provide specific comments)

If this vote passes, then we will then ask the Incubator PMC for their
blessing before the official release.

--
Regards,
Hiram

Re: Restructuring the console src dirs

2006-04-03 Thread Dain Sundstrom


+1

-dain

On Apr 3, 2006, at 7:48 AM, Aaron Mulder wrote:


That seems like a fine step for now.

Once we have better portal server integration (what is the status of
Jetspeed 2 or a newer Pluto anyway?) we'll probably want to really
split out the console features (and put all the portlets in modules
near the features they go with).  I think we can also find a way to
eliminate the console-core package.  So it may eventually collapse
back down into a single EAR+WAR or even a single WAR, but I think
that's longer term.

If you go ahead with this, please don't make the change in the 1.1
branch, just in head.

Thanks,
Aaron

On 4/3/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote:

Last week Aaron, Joe, Paul and I discussed on IRC the intent to
restructure the src dirs of the console under the application
directory. (http://servlet.uwyn.com/drone/log/bevinbot/geronimo/ 
20060330)


Geronimo-1660 (http://issues.apache.org/jira/browse/GERONIMO-1660)
will seek to achieve this. Just wanted to send this out to the larger
community before we commit the patch.

Currently, the console is made up of 4 dirs under applications
- geronimo
  -  applications
 + console-core
 + console-ear
 + console-standard
 + console-framework

The new structure will be as follows
- geronimo
  -  applications
 - console   <<---  new dir added here. existing console
sub-dirs moved under this.
+ console-core
+ console-ear
+ console-standard
+ console-framework

This will keep all the console dirs in one place. As the console  
grows

to add more components/directories, it won't clutter up the
applications dir.

Comments welcome.

Cheers
Prasad

Re: [VOTE] ActiveMQ 4.0 RC2

2006-04-03 Thread James Strachan

+1 Release the binary as ActiveMQ 4.0-RC2

On 4/3/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
>
> Hi Guys,
>
> This RC1 failed to pass incubator approval.  There was a small issue
> with some of the logging message produced on start up.  So I've done a
> new RC2 release from trunk and has all the latest bug fixes.
>
> I've posted it here:
> http://people.apache.org/~chirino/incubator-activemq-4.0-RC2/
> I've tagged the source for that build as:
>
> https://svn.apache.org/repos/asf/incubator/activemq/tags/activemq-4.0-RC2/activemq
>
>
> [ ] +1 Release the binary as ActiveMQ 4.0-RC2
> [ ] -1 Veto the release (provide specific comments)
>
> If this vote passes, then we will then ask the Incubator PMC for their
> blessing before the official release.
>
> --
> Regards,
> Hiram
>



--

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

Re: [VOTE] ActiveMQ 4.0 RC2

2006-04-03 Thread Hiram Chirino

+1

On 4/3/06, Hiram Chirino <[EMAIL PROTECTED]> wrote:
> Hi Guys,
>
> This RC1 failed to pass incubator approval.  There was a small issue
> with some of the logging message produced on start up.  So I've done a
> new RC2 release from trunk and has all the latest bug fixes.
>
> I've posted it here:
> http://people.apache.org/~chirino/incubator-activemq-4.0-RC2/
> I've tagged the source for that build as:
> https://svn.apache.org/repos/asf/incubator/activemq/tags/activemq-4.0-RC2/activemq
>
>
> [ ] +1 Release the binary as ActiveMQ 4.0-RC2
> [ ] -1 Veto the release (provide specific comments)
>
> If this vote passes, then we will then ask the Incubator PMC for their
> blessing before the official release.
>
> --
> Regards,
> Hiram
>


--
Regards,
Hiram

Re: [VOTE] ActiveMQ 4.0 RC2

2006-04-03 Thread Adrian Co


+1 Release the binary as ActiveMQ 4.0-RC2

Regards,
Eyds

Hiram Chirino wrote:


Hi Guys,

This RC1 failed to pass incubator approval.  There was a small issue
with some of the logging message produced on start up.  So I've done a
new RC2 release from trunk and has all the latest bug fixes.

I've posted it here:
http://people.apache.org/~chirino/incubator-activemq-4.0-RC2/
I've tagged the source for that build as:
https://svn.apache.org/repos/asf/incubator/activemq/tags/activemq-4.0-RC2/activemq


[ ] +1 Release the binary as ActiveMQ 4.0-RC2
[ ] -1 Veto the release (provide specific comments)

If this vote passes, then we will then ask the Incubator PMC for their
blessing before the official release.

--
Regards,
Hiram

Re: What about moving applications into its own source tree?

2006-04-03 Thread Paul McMahan

Hi Jacek,  since the console application is so intricately tied to the
kernel and deployment APIs and since it is also an important part of
the resulting assemblies I think it would be best to keep at least
that one application in the same repository as the application server.

Best wishes,
Paul

On 4/2/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote:
> Hi,
>
> While migrating the applications to M2 I came up with the idea to move
> that directory to its own repository, just like daytrader or devtools,
> off Geronimo the application server tree. What do you think?
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.laskowski.org.pl
>

Re: [VOTE] ActiveMQ 4.0 RC2

2006-04-03 Thread Rob Davies


+1

cheers,

Rob
On 3 Apr 2006, at 17:19, Hiram Chirino wrote:


Hi Guys,

This RC1 failed to pass incubator approval.  There was a small issue
with some of the logging message produced on start up.  So I've done a
new RC2 release from trunk and has all the latest bug fixes.

I've posted it here:
http://people.apache.org/~chirino/incubator-activemq-4.0-RC2/
I've tagged the source for that build as:
https://svn.apache.org/repos/asf/incubator/activemq/tags/ 
activemq-4.0-RC2/activemq



[ ] +1 Release the binary as ActiveMQ 4.0-RC2
[ ] -1 Veto the release (provide specific comments)

If this vote passes, then we will then ask the Incubator PMC for their
blessing before the official release.

--
Regards,
Hiram

[VOTE] ActiveMQ 4.0 RC2

2006-04-03 Thread Hiram Chirino

Hi Guys,

This RC1 failed to pass incubator approval.  There was a small issue
with some of the logging message produced on start up.  So I've done a
new RC2 release from trunk and has all the latest bug fixes.

I've posted it here:
http://people.apache.org/~chirino/incubator-activemq-4.0-RC2/
I've tagged the source for that build as:
https://svn.apache.org/repos/asf/incubator/activemq/tags/activemq-4.0-RC2/activemq


[ ] +1 Release the binary as ActiveMQ 4.0-RC2
[ ] -1 Veto the release (provide specific comments)

If this vote passes, then we will then ask the Incubator PMC for their
blessing before the official release.

--
Regards,
Hiram

Re: Restructuring the console src dirs

2006-04-03 Thread Joe Bohn


+1

Joe

Prasad Kashyap wrote:

Last week Aaron, Joe, Paul and I discussed on IRC the intent to
restructure the src dirs of the console under the application
directory. (http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20060330)

Geronimo-1660 (http://issues.apache.org/jira/browse/GERONIMO-1660)
will seek to achieve this. Just wanted to send this out to the larger
community before we commit the patch.

Currently, the console is made up of 4 dirs under applications
- geronimo
  -  applications
 + console-core
 + console-ear
 + console-standard
 + console-framework

The new structure will be as follows
- geronimo
  -  applications
 - console   <<---  new dir added here. existing console
sub-dirs moved under this.
+ console-core
+ console-ear
+ console-standard
+ console-framework

This will keep all the console dirs in one place. As the console grows
to add more components/directories, it won't clutter up the
applications dir.

Comments welcome.

Cheers
Prasad




--
Joe Bohn
joe.bohn at earthlink.net

"He is no fool who gives what he cannot keep, to gain what he cannot 
lose."   -- Jim Elliot

Re: Restructuring the console src dirs

2006-04-03 Thread Paul McMahan

Sounds like a good idea. Thanks for the heads up. One item (you may
have already thought of) is that some of the top level maven goals
that recurse into the applications subdirectory may need to be updated
if you add this additional directory level (clean, eclipse, idea,
etc).  Or this might work for free with maven, I don't know.  Also,
have you thought about also using a similar approach to partition the
jetty/tomcat configs and assemblies?  Seems cleaner than using
*-tomcat or *-jetty directory names.  Just a thought.

Best wishes,
Paul

On 4/3/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote:
> Last week Aaron, Joe, Paul and I discussed on IRC the intent to
> restructure the src dirs of the console under the application
> directory. (http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20060330)
>
> Geronimo-1660 (http://issues.apache.org/jira/browse/GERONIMO-1660)
> will seek to achieve this. Just wanted to send this out to the larger
> community before we commit the patch.
>
> Currently, the console is made up of 4 dirs under applications
> - geronimo
>   -  applications
>  + console-core
>  + console-ear
>  + console-standard
>  + console-framework
>
> The new structure will be as follows
> - geronimo
>   -  applications
>  - console   <<---  new dir added here. existing console
> sub-dirs moved under this.
> + console-core
> + console-ear
> + console-standard
> + console-framework
>
> This will keep all the console dirs in one place. As the console grows
> to add more components/directories, it won't clutter up the
> applications dir.
>
> Comments welcome.
>
> Cheers
> Prasad
>

Re: Restructuring the console src dirs

Yep this makes sense to me.  I always wondered why we never did this to
begin with ;-)

Prasad Kashyap wrote:
> Last week Aaron, Joe, Paul and I discussed on IRC the intent to
> restructure the src dirs of the console under the application
> directory. (http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20060330)
> 
> Geronimo-1660 (http://issues.apache.org/jira/browse/GERONIMO-1660)
> will seek to achieve this. Just wanted to send this out to the larger
> community before we commit the patch.
> 
> Currently, the console is made up of 4 dirs under applications
> - geronimo
>   -  applications
>  + console-core
>  + console-ear
>  + console-standard
>  + console-framework
> 
> The new structure will be as follows
> - geronimo
>   -  applications
>  - console   <<---  new dir added here. existing console
> sub-dirs moved under this.
> + console-core
> + console-ear
> + console-standard
> + console-framework
> 
> This will keep all the console dirs in one place. As the console grows
> to add more components/directories, it won't clutter up the
> applications dir.
> 
> Comments welcome.
> 
> Cheers
> Prasad

Re: Restructuring the console src dirs

2006-04-03 Thread Aaron Mulder

That seems like a fine step for now.

Once we have better portal server integration (what is the status of
Jetspeed 2 or a newer Pluto anyway?) we'll probably want to really
split out the console features (and put all the portlets in modules
near the features they go with).  I think we can also find a way to
eliminate the console-core package.  So it may eventually collapse
back down into a single EAR+WAR or even a single WAR, but I think
that's longer term.

If you go ahead with this, please don't make the change in the 1.1
branch, just in head.

Thanks,
Aaron

On 4/3/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote:
> Last week Aaron, Joe, Paul and I discussed on IRC the intent to
> restructure the src dirs of the console under the application
> directory. (http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20060330)
>
> Geronimo-1660 (http://issues.apache.org/jira/browse/GERONIMO-1660)
> will seek to achieve this. Just wanted to send this out to the larger
> community before we commit the patch.
>
> Currently, the console is made up of 4 dirs under applications
> - geronimo
>   -  applications
>  + console-core
>  + console-ear
>  + console-standard
>  + console-framework
>
> The new structure will be as follows
> - geronimo
>   -  applications
>  - console   <<---  new dir added here. existing console
> sub-dirs moved under this.
> + console-core
> + console-ear
> + console-standard
> + console-framework
>
> This will keep all the console dirs in one place. As the console grows
> to add more components/directories, it won't clutter up the
> applications dir.
>
> Comments welcome.
>
> Cheers
> Prasad
>

Restructuring the console src dirs

Last week Aaron, Joe, Paul and I discussed on IRC the intent to
restructure the src dirs of the console under the application
directory. (http://servlet.uwyn.com/drone/log/bevinbot/geronimo/20060330)

Geronimo-1660 (http://issues.apache.org/jira/browse/GERONIMO-1660)
will seek to achieve this. Just wanted to send this out to the larger
community before we commit the patch.

Currently, the console is made up of 4 dirs under applications
- geronimo
  -  applications
 + console-core
 + console-ear
 + console-standard
 + console-framework

The new structure will be as follows
- geronimo
  -  applications
 - console   <<---  new dir added here. existing console
sub-dirs moved under this.
+ console-core
+ console-ear
+ console-standard
+ console-framework

This will keep all the console dirs in one place. As the console grows
to add more components/directories, it won't clutter up the
applications dir.

Comments welcome.

Cheers
Prasad

Re: Session replication in Geronimo clustering

2006-04-03 Thread Filip Hanik - Dev Lists

the correct attr name is mcastBindAddress if I remember it correctly, 
but if it is working for you now, then that is great

Phani Madgula wrote:

Hi,

Sorry for deply in reply..I was out of the work...!

I did change the xx.yy.zz.aa to the  proper value. I am testing these 
scenarios on Linux machines. I got information from google search 
about this error.
http://mail-archives.apache.org/mod_mbox/tomcat-users/200503.mbox/[EMAIL PROTECTED] 

It said that, if the network is not multihomed, then we do not have to 
specify the attribute "mcastBindAddress".

So, I just commented out
mcastBindAddr="192.168.11.3 " in the 
geronimo-web.xml files and redeployed the applications on each node. 
Now, all the session replication and fail-over is happening.

I do not know what is multihomed network. I will try to know and 
update you on this.

To my surprise, when I tested on only windows machines, this problem 
is not there. It is experienced only on Linux machines.

Thanks

Phani

On 3/30/06, *Filip Hanik - Dev Lists* <[EMAIL PROTECTED] 
> wrote:

>tcpListenAddress=xx.yy.zz.aa

yup, this would cause a null pointer later on if not changed. it
would
have to be a valid value, or "auto", which will decide the IP on
its own.

Filip

Jeff Genender wrote:
> Yep...those should be set if the example was followed...
>
>  class="org.apache.geronimo.tomcat.cluster.ReceiverGBean">
>name="className">org.apache.catalina.cluster.tcp.ReplicationListener
> 
>
>   
> tcpListenAddress=xx.yy.zz.aa
> tcpListenPort=4001
> tcpSelectorTimeout=100
> tcpThreadCount=6
>   
> 
>
> Phani, did you change the tcpListenAddress initParams attribute to a
> real address?
>
> Jeff
>
>
> Filip Hanik - Dev Lists wrote:
>
>> it would be one of these, they should all be set to a value.
>>
>> tcpListenAddress="auto"
>> tcpListenPort="9015"
>> tcpSelectorTimeout="100"
>> tcpThreadCount="6"
>>
>> also, if tcpListenAddress says "auto" instead of an IP address,
the the
>> following code gets executed
>>
>> public java.net.InetAddress getBind() {
>>if (bind == null) {
>>try {
>>if ("auto".equals(tcpListenAddress))
>>tcpListenAddress =
>> java.net.InetAddress.getLocalHost ().getHostAddress();
>>bind =
java.net.InetAddress.getByName(tcpListenAddress);
>>} catch (IOException ioe) {
>>log.error("Failed bind replication listener on
address:"+
>> tcpListenAddress, ioe);
>>}
>>}
>>  return bind;
>> }
>>
>> so, if there is an error getting the correct address for the
localhost
>> machine, it will return null, and could cause your nullpointer
exception
>>
>> my guess is of course that the attribute is missing all together.
>>
>> Filip
>>
>>
>>
>>
>> Jeff Genender wrote:
>>
>>> Filip,
>>>
>>> Thanks for the input...any idea on the missing attribute?
>>>
>>> Jeff
>>>
>>> Filip Hanik - Dev Lists wrote:
>>>
>>>
 gentlemen,
 looks like there is an attribute missing from the
 "**" element.
 the ReplicationListener.listen() method just gets the listen
address (or
 tries to resolve the name, then gets the port)
 then it starts up a server socket using NIO.

 the other error, no active members in group, just means that
the tomcat
 instances didn't discover each other using multicast heart beats.

 Lets get the ReplicationListener error first, then we can
move on to
 membership, can you post your tomcat config file
 PS. the error is not related to mod_jk, its in the tomcat
java code.
 thanks
 Filip

 Phani Madgula wrote:

> Hi,
>
> I have been trying to use tomcat clustering with Geronimo for a
> customer application. Sometimes, I face the following problem.
>
>
> I downloaded apache2.0.54 and mod_jk_1.2.15 and tested
clustering. I
> have three machines on a same subnet one windows and other
are linux
> boxes. I have also enabled IPMulticast and no firewalls between
> systems.
>
> To my observation, session replication is not working. However,
> loadbalancer is able to fail-over successfully.
>
> When I shutdown the instance which is serving the
HttpRequests, it
> will throw an exception stating "not able to start cluster
list

Re: Questions about the packaging plugin

2006-04-03 Thread anita kulshreshtha

David,
   I am encountering a strange problem probably
because I am doing something wrong. When I add
commons-logging to the urls used for constructing the
classloader for PackageBuilder. I get error :

[ERROR] FATAL ERROR
[INFO]

[INFO] null
Invalid class loader hierarchy.  You have more than
one version of 'org.apache.commons.logging.Log'
visible, which is not allowed.

If I do not add it I get this error :

[INFO]

[ERROR] FATAL ERROR
[INFO]

[INFO] org/apache/commons/logging/LogFactory
[INFO]

[INFO] Trace
java.lang.NoClassDefFoundError:
org/apache/commons/logging/LogFactory
at
org.apache.geronimo.plugin.packaging.PackageBuilder.(PackageBuilder.java:49)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:
   What is this due to?

Thanks
Anita

--- anita kulshreshtha <[EMAIL PROTECTED]> wrote:

> David J,
>  Thanks. Comments inline...
> 
> --- David Jencks <[EMAIL PROTECTED]> wrote:
> 
> > 
> > 
> > anita kulshreshtha <[EMAIL PROTECTED]> wrote: Hi
> > David,
> >I have few questions related to
> > geronimo-packaging-plugin:
> > 1. The j2ee-server configuration has
> > geronimo-gbean-deployer.car declared as a
> dependency
> > whereas rmi-naming.car is an import. IIUC, the
> first
> > one is a parent configuration and each additional
> > parent is defined using import. Is this convention
> > followed throughout? Why is it necessary to
> > distinguish between the two? 
> > 
> > geronimo-gbean-deployer is a dependency because it
> > is needed to run the packaging plugin for this
> plan.
> >  it is definitely NOT a parent, it is not needed
> to
> > start a geronimo server that includes the
> > j2ee-server configuration.
>  I see.. a lot has changed from the days of
> o/a/g/Deployer etc. Now j2ee-server is the base
> configuration. What is j2ee-system-experimental
> configuration?
> 
> Thnaks
> Anita
> > 
> > 2. We add all the imports/dependencies to plan.xml
> > for
> > constructing the classpath. This classpath is used
> > to
> > package the car. Sometime the classpath is also
> put
> > in
> > MANIFEST.MF (for example j2ee-system). Why is this
> > not
> > done for j2ee-server?
> > 
> > The entries in the manifest classpath are only
> > needed for the "root" configurations that are used
> > to boot a  server.  At present these are the
> > j2ee-system and client-system (I might have
> > forgotten something used for a tool, perhaps
> > shutdown?)  Currently the Daemon (and subclasses
> > such as ClientCommandLine) clear the dependency
> list
> > on any configurations they boot (start first). 
> > We've wanted for a long time to eliminate the need
> > for the manifest classpath, and Dain has some
> ideas
> > how to do it: basically we need to start up a
> "boot
> > repository".  This will also let us remove a lot
> of
> > the jars from lib.  We are putting the
> dependencies
> > into the plan mostly so that all the plans include
> > their dependencies generated from project.xml,
> even
> > thought they aren't being used for the boot
> > configurations.
> > 
> > 3. How is the generated plan.xml used later on? If
> > we
> > put the classpath in the MANIFEST.MF, do we still
> > need
> > to add imports and dependencies to plan.xml?
> > 
> > 
> > No, but as noted above we are including them as
> > documentation and as an inspiration to get rid of
> > the need for manifest classpath.
> > 
> > 
> > Thanks
> > Anita
> > 
> 
> > thanks
> > david jencks
> > 
> > __
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> > protection around 
> > http://mail.yahoo.com 
> > 
> > 
> 
> 
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam
> protection around 
> http://mail.yahoo.com 
> 


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

Re: Session replication in Geronimo clustering