Re: CORBA
While we figure out the best way to compile idl in maven2, the best module structure etc etc could we commit the patches so we don't get into patch hell? svn is much more convenient to use for source control than jira. Are the patches entirely against sandbox/freeorb? Shall I apply them? thanks david jencks Hoping to have a minute to look at this very soon On Nov 7, 2005, at 4:52 AM, Kresten Krab Thorup wrote: I submitted a patch for GERONIMO- some time last week, and all I have heard back is that the JIRA entry now says "patch available". Apparently the changes have not been submitted to the trunk; is there anything else I should do to make that happen? It's rather challenging to work effectively here if we cannot share code through a source repository. I understand that you cannot guarantee any particular turn around, but if it is this slow then I might as well work out of a local source repository here and then submit a new tar ball every once in a while. FYI, we have spent some time last week on the build setup, M2 and figuring a good way to do tests and in general just figuring out how to "play by the rules here" in the geronimo build world. Kresten Krab Thorup [EMAIL PROTECTED] "We do not inherit the Earth from our parents, we borrow it from our children." Saint Exupery
[jira] Commented: (GERONIMO-1124) bouncycastle/jars/bcprov-jdk14-124.jar not found
[ http://issues.apache.org/jira/browse/GERONIMO-1124?page=comments#action_12357011 ] kenperl commented on GERONIMO-1124: --- I find this could be changed in the file project.properties. but my critical issus is impossible to pass the http proxy even I set CVS_PROXY or add them to $CVSROOT. cvs -d :pserver:[EMAIL PROTECTED]:/home/projects/openejb/scm co openejb cvs [checkout aborted]: connect to cvs.openejb.org(64.7.141.17):2401 failed: Connection timed out could I check out the open-ejb by svn? > bouncycastle/jars/bcprov-jdk14-124.jar not found > > > Key: GERONIMO-1124 > URL: http://issues.apache.org/jira/browse/GERONIMO-1124 > Project: Geronimo > Type: Bug > Components: buildsystem > Versions: 1.0-M5 > Environment: linux, maven1.02 > Reporter: kenperl > Priority: Blocker > > I don't use my own build.properties file. type maven in the directory where > the source codes checked out from HEAD. > I am using online building. > BUILD FAILED > File.. /root/.maven/cache/maven-multiproject-plugin-1.3.1/plugin.jelly > Element... maven:reactor > Line.. 217 > Column 9 > Unable to obtain goal [default] -- > /root/geronimo1.0/modules/assembly/maven.xml:358:15: > org.apache.geronimo.kernel.repository.MissingDependencyException: uri > bouncycastle/jars/bcprov-jdk14-124.jar not found in repository > Total time: 106 minutes 49 seconds -- 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: ClassLoader memory leaks
Hi Jeff, Yes, I had, but only for a few deploy/undeploy cycles. I just ran a more extended test, with much better results. I'm not seeing unbounded growth in memory. At least not at the rate I reported earlier. I'm seeing growth of about 500 bytes per deploy/undeploy cycle. I think there may be an initial ramp-up for the first several deploys. Afterwards, growth is very small -- practically in the noise range. I know there's a 30 minute timer task that will hold on to a few objects. I also see a number of WeakHashMap Entries which are pending a Map operation before they will be cleared out. It's possible that we aren't leaking memory at all. I'll run a more extended test. However, unless I get dramatically different results, I think there are bigger fish to fry... --kevanOn 11/7/05, Jeff Genender <[EMAIL PROTECTED]> wrote: Have you run a profiler to see where the leaks are occurring?Matt Hogstrom wrote:> Kevan,>> Big thanks for tracking down these issues. I know they aren't easy.>> Matt> > Kevan Miller wrote:>> I've been battling a variety of ClassLoader-based memory leaks that occur>> during the deploy/undeploy of DayTrader. With the patches for the>> following>> problems, I no longer see MultiParentClassLoaders being leaked: http://issues.apache.org/jira/browse/GERONIMO-1125 (patch just posted)>> http://issues.apache.org/jira/browse/GERONIMO-1118 (fix committed)>> http://issues.apache.org/jira/browse/AXIS-2232 (Old patch didn't fix the>> problem. I've attached a new patch that fixes the problem. Yet to be >> committed)>> http://issues.apache.org/jira/browse/AXIS-2278 (Fix committed, but not>> picked up by Geronimo build)>> >> Deployment of DayTrader is still leaking memory (but only 200 kbytes per>> deploy/undeploy cycle. "only" is a relative term... ;-). So, there's>> still>> work to be done. Finally, there is an intermittent problem which will cause a Thread to>> temporarily hold on to a ClassLoader. Since the problem is>> intermittent and>> temporary, I'm not actively pursuing. I'll document the problem in a >> jira,>> but here's the chain of references keeping the ClassLoader alive... The>> Thread is in the RMI Runtime ThreadGroup. java.lang.Thread.inheritedAccessControlContext -->>> java.security.AccessControlContext.context -->>> java.security.ProtectionDomain[4] -->>> java.security.ProtectionDomain.classLoader -->>> org.apache.geronimo.kernel.config.MultiParentClassLoader --kevan>>
Re: Netbeans integration and tooling
As a user I think it would make the most sense to distribute it as part of the serverplugins module just like its weblogic, jboss and websphere counterparts. Also once the plugin is included in the netbeans release its presence might generate additional interest in geronimo and inspire more converts... I mean users. What was the reason for the eclipse plugin being moved to g? I have begun some preliminary work. I have a pretty good handle on netbeans and openide apis as I have several yet unreleased plugins, however I am new to g. The bulk of the g logic seems to revolve around the DeploymentManager implementation. Almost everything else is netbeans specific, correct me if I'm wrong. On Mon, 2005-11-07 at 23:35 +0100, Jacek Laskowski wrote: > Dustin Little wrote: > > Has anyone begun work on integration and tooling for Netbeans IDE? > > I had once developed some Geronimo support and before it had been > submitted to the serverplugins module of NetBeans IDE, I unexpectedly > wiped out all of the sources. You can't even imagine what happened > afterwards. It was just before NetBeans IDE 4.2 went public. > > If you wanted to start it again, I could help you with the API. It is > not that hard as it seems. I even think it is much easier than as you > had to do it in Eclipse (sorry Sachin ;)). > > Please, please do it. Although it has a little chance to be included in > NB 5.0, it could be distributed as NBM. > > The question I could not answer myself was when the development should > take place - here in Geronimo or serverplugins project? If it's part of > serverplugins module, it would be distributed along with weblogic, jboss > and websphere modules. Otherwise, people had to download it separately. > What do you and others think? > > Jacek >
[jira] Created: (GERONIMO-1143) Need a capable security realm configuration portlet
Need a capable security realm configuration portlet --- Key: GERONIMO-1143 URL: http://issues.apache.org/jira/browse/GERONIMO-1143 Project: Geronimo Type: Improvement Components: management, security, console Versions: 1.0-M5 Reporter: Aaron Mulder Fix For: 1.0 There should be a portlet that lets you create and edit security realms, control which login modules go into the realms, etc. The edit feature may be a little tricky as changing the login modules IIUC requires a fair bit of adding and removing GBeans. -- 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-1109) Need class for server shutdown
[ http://issues.apache.org/jira/browse/GERONIMO-1109?page=all ] Sachin Patel updated GERONIMO-1109: --- Attachment: newpatch.txt Per David J.'s suggestions new patch created. -shutdown.jar introduced -port can be specified as argument > Need class for server shutdown > -- > > Key: GERONIMO-1109 > URL: http://issues.apache.org/jira/browse/GERONIMO-1109 > Project: Geronimo > Type: New Feature > Components: startup/shutdown > Versions: 1.0 > Reporter: Sachin Patel > Priority: Minor > Fix For: 1.0 > Attachments: StopServer.java, newpatch.txt, patch.txt > > Attached is a class that shut's down the server. Unlike the existing > StopRemoteServer it handles shutting down the correct server if multiple > server instances are running. This class could be called from a script or > even a windows service. > - I'm not exactly sure where this class should be loaded, wether it should be > embedded into server.jar or somewhere else. -- 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: ClassLoader memory leaks
Have you run a profiler to see where the leaks are occurring? Matt Hogstrom wrote: Kevan, Big thanks for tracking down these issues. I know they aren't easy. Matt Kevan Miller wrote: I've been battling a variety of ClassLoader-based memory leaks that occur during the deploy/undeploy of DayTrader. With the patches for the following problems, I no longer see MultiParentClassLoaders being leaked: http://issues.apache.org/jira/browse/GERONIMO-1125 (patch just posted) http://issues.apache.org/jira/browse/GERONIMO-1118 (fix committed) http://issues.apache.org/jira/browse/AXIS-2232 (Old patch didn't fix the problem. I've attached a new patch that fixes the problem. Yet to be committed) http://issues.apache.org/jira/browse/AXIS-2278 (Fix committed, but not picked up by Geronimo build) Deployment of DayTrader is still leaking memory (but only 200 kbytes per deploy/undeploy cycle. "only" is a relative term... ;-). So, there's still work to be done. Finally, there is an intermittent problem which will cause a Thread to temporarily hold on to a ClassLoader. Since the problem is intermittent and temporary, I'm not actively pursuing. I'll document the problem in a jira, but here's the chain of references keeping the ClassLoader alive... The Thread is in the RMI Runtime ThreadGroup. java.lang.Thread.inheritedAccessControlContext --> java.security.AccessControlContext.context --> java.security.ProtectionDomain[4] --> java.security.ProtectionDomain.classLoader --> org.apache.geronimo.kernel.config.MultiParentClassLoader --kevan
Re: Netbeans integration and tooling
Dustin Little wrote: Has anyone begun work on integration and tooling for Netbeans IDE? I had once developed some Geronimo support and before it had been submitted to the serverplugins module of NetBeans IDE, I unexpectedly wiped out all of the sources. You can't even imagine what happened afterwards. It was just before NetBeans IDE 4.2 went public. If you wanted to start it again, I could help you with the API. It is not that hard as it seems. I even think it is much easier than as you had to do it in Eclipse (sorry Sachin ;)). Please, please do it. Although it has a little chance to be included in NB 5.0, it could be distributed as NBM. The question I could not answer myself was when the development should take place - here in Geronimo or serverplugins project? If it's part of serverplugins module, it would be distributed along with weblogic, jboss and websphere modules. Otherwise, people had to download it separately. What do you and others think? Jacek
[jira] Assigned: (GERONIMO-1125) AbstractSinglePoolConnectionInterceptor$IdleReleaser keeps MultiParentClassLoaders alive
[ http://issues.apache.org/jira/browse/GERONIMO-1125?page=all ] David Jencks reassigned GERONIMO-1125: -- Assign To: David Jencks (was: Kevan Miller) > AbstractSinglePoolConnectionInterceptor$IdleReleaser keeps > MultiParentClassLoaders alive > > > Key: GERONIMO-1125 > URL: http://issues.apache.org/jira/browse/GERONIMO-1125 > Project: Geronimo > Type: Bug > Components: connector > Versions: 1.0-M5 > Environment: JDK 1.4/WinXP > Reporter: Kevan Miller > Assignee: David Jencks > Fix For: 1.0 > Attachments: InterceptorDestroy.patch > > After a deploy/undeploy of DayTrader, the following chain of references > (there are others which I'm investigating) is keeping a MultiClassLoader > instance from being marked as available for GC. > java.util.TaskQueue.queue --> java.util.TimerTask[128] > java.util.TimerTask[5] --> > org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor$IdleReleaser > IdleReleaser.this$0 --> > org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor > SinglePoolConnectionInterceptor.next --> > org.apache.geronimo.connector.outbound.XAResourceInsertionInterceptor > XAResourceInsertionInterceptor.next --> > org.apache.geronimo.connector.outbound.MCFConnectionInterceptor > MCFConnectionInterceptor.stack --> > org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor > ConnectionTrackingInterceptor.next --> > org.apache.geronimo.connector.outbound.TCCLInterceptor > TCCLInterceptor.classLoader --> > org.apache.geronimo.kernel.config.MultiParentClassLoader > The default interval for the IdleReleaser TimerTask is 30 minutes. Plenty of > time for us to run out of PermGen space. Currently the task is never > cancelled. I'm working on cancelling the task. However, that's not > sufficient. TimerTask.cancel() simply updates state. It doesn't remove the > Task from the TimerQueue. So, the task lives until it expires (looks like > this "feature" is fixed in 1.5). Easiest fix is to break the chain of > references at the IdleReleaser task when the task is cancelled. This should > be good enough. Alternative is to implement our own Timer -- which wouldn't > be too hard... Or have multiple Timers and cancel the whole timer... > I'm working on breaking the chain of references at IdleReleaser. Note that > this means the IdleReleaser classloader will be kept alive until the > TimerTask expires. However, the IdleReleaser classloader is a long-lived > Geronimo class loader. So, this shouldn't be a problem, but it's not ideal, > either... -- 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: ClassLoader memory leaks
Kevan, Big thanks for tracking down these issues. I know they aren't easy. Matt Kevan Miller wrote: I've been battling a variety of ClassLoader-based memory leaks that occur during the deploy/undeploy of DayTrader. With the patches for the following problems, I no longer see MultiParentClassLoaders being leaked: http://issues.apache.org/jira/browse/GERONIMO-1125 (patch just posted) http://issues.apache.org/jira/browse/GERONIMO-1118 (fix committed) http://issues.apache.org/jira/browse/AXIS-2232 (Old patch didn't fix the problem. I've attached a new patch that fixes the problem. Yet to be committed) http://issues.apache.org/jira/browse/AXIS-2278 (Fix committed, but not picked up by Geronimo build) Deployment of DayTrader is still leaking memory (but only 200 kbytes per deploy/undeploy cycle. "only" is a relative term... ;-). So, there's still work to be done. Finally, there is an intermittent problem which will cause a Thread to temporarily hold on to a ClassLoader. Since the problem is intermittent and temporary, I'm not actively pursuing. I'll document the problem in a jira, but here's the chain of references keeping the ClassLoader alive... The Thread is in the RMI Runtime ThreadGroup. java.lang.Thread.inheritedAccessControlContext --> java.security.AccessControlContext.context --> java.security.ProtectionDomain[4] --> java.security.ProtectionDomain.classLoader --> org.apache.geronimo.kernel.config.MultiParentClassLoader --kevan
Re: [consolidation] next steps?
On Nov 7, 2005, at 3:14 PM, Bruce Snyder wrote: On 11/7/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote: b) the copyright must be assigned to the ASF I was told there was no way for someone to assign copyrights to the ASF. Has this changed and if so where is the form? That's a question for Noel. Let's allow him (or someone else in the know) some time to respond. No, the copyright isn't assigned to the ASF. The original author retains copyright. However, they do provide a copyright license to us through the Software Grant or CCLA+SG. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED]
Re: [consolidation] next steps?
This is an area of much confusion. This may help (or it may not :)
http://mail-archives.apache.org/mod_mbox/www-legal-discuss/200508.mbox/[EMAIL
PROTECTED]
(tiny: http://tinyurl.com/8fcx6)
Basic gist, as I understand (IANAL): the copyright is not assigned to
the ASF, but licensed to the ASF. This is done through a software
grant form.
If anyone is interested in this, you should review the thread above
and join the legal-discuss list which is open to all committers to ask
questions.
HTH,
Brett
On 11/8/05, Bruce Snyder <[EMAIL PROTECTED]> wrote:
> On 11/7/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
>
> > > b) the copyright must be assigned to the ASF
> >
> > I was told there was no way for someone to assign copyrights to the
> > ASF. Has this changed and if so where is the form?
>
> That's a question for Noel. Let's allow him (or someone else in the
> know) some time to respond.
>
> Bruce
> --
> perl -e 'print unpack("u30","D0G)[EMAIL
> PROTECTED]&5R\"F)R=6-E+G-N>61E );'
>
> The Castor Project
> http://www.castor.org/
>
> Apache Geronimo
> http://geronimo.apache.org/
>
Re: [consolidation] next steps?
On 11/7/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> > b) the copyright must be assigned to the ASF
>
> I was told there was no way for someone to assign copyrights to the
> ASF. Has this changed and if so where is the form?
That's a question for Noel. Let's allow him (or someone else in the
know) some time to respond.
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
Re: [consolidation] next steps?
On Nov 7, 2005, at 10:42 AM, Bruce Snyder wrote: On 11/7/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote: Good point Ken. How about we consider this thread the invite? So formally: We would like to invite the projects that Geronimo works with to consider joining Geronimo as a Subproject. If your project would like to join, we will either need a proposal to incubate the project, or a proposal to donate the code. In the case of incubation, the current committers will have immediate access to their code in the incubator, and in the case of an donation, the current committers will have to earn commit on Geronimo. I'm not sure of the order in which all steps must occur, but we (the Geronimo PMC) must also vote to accept each project per the Incubator FAQ: Absolutely. I guess I wasn't clear. We need a proposal that Geronimo can vote on and send to the incubator. Beyond this, once a project has been voted in, the following additional requirements must be met: a) project license (must be AL 2.0) b) the copyright must be assigned to the ASF I was told there was no way for someone to assign copyrights to the ASF. Has this changed and if so where is the form? c) all committers must file a CLA with the ASF (if one is not already on file) Please note that it is possible for some (or most) of these projects to pass right on through the Incubator as long as the exit criteria are met: http://incubator.apache.org/incubation/ Incubation_Policy.html#Exitting+the+Incubator Also, here's the template that must be filled and submitted upon importing each project into the Geronimo SVN repo: http://svn.apache.org/viewcvs.cgi/incubator/public/trunk/site- author/projects/incubation-status-template.html?view=markup Excellent. Thanks for the links. -dain
[jira] Updated: (GERONIMO-1130) Implement WebServer Manager (statistics gathering/reporting) management interface
[ http://issues.apache.org/jira/browse/GERONIMO-1130?page=all ] Joe Bohn updated GERONIMO-1130: --- Summary: Implement WebServer Manager (statistics gathering/reporting) management interface (was: Implement WebServer Manager (statistics gathering/reporting) for tomcat) Description: Jetty has a statistics gathering and reporting capability that is support in the console via the Web Server Manager portlet. We should provide similar monitoring capabilities for tomcat. However, the Jetty implementation is tightly bound to Jetty. We need a more generic interface build upon the principles of JSR77 to address statistical information for the web server (both jetty and tomcat). was:Jetty has a statistics gathering and reporting capability that is support in the console via the Web Server Manager portlet. We should provide similar monitoring capabilities for tomcat. > Implement WebServer Manager (statistics gathering/reporting) management > interface > - > > Key: GERONIMO-1130 > URL: http://issues.apache.org/jira/browse/GERONIMO-1130 > Project: Geronimo > Type: New Feature > Components: management, console > Versions: 1.0-M5 > Environment: all > Reporter: Joe Bohn > Fix For: 1.0 > > Jetty has a statistics gathering and reporting capability that is support in > the console via the Web Server Manager portlet. We should provide similar > monitoring capabilities for tomcat. > However, the Jetty implementation is tightly bound to Jetty. We need a more > generic interface build upon the principles of JSR77 to address statistical > information for the web server (both jetty and tomcat). -- 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] Assigned: (GERONIMO-1130) Implement WebServer Manager (statistics gathering/reporting) management interface
[ http://issues.apache.org/jira/browse/GERONIMO-1130?page=all ] Joe Bohn reassigned GERONIMO-1130: -- Assign To: Joe Bohn > Implement WebServer Manager (statistics gathering/reporting) management > interface > - > > Key: GERONIMO-1130 > URL: http://issues.apache.org/jira/browse/GERONIMO-1130 > Project: Geronimo > Type: New Feature > Components: management, console > Versions: 1.0-M5 > Environment: all > Reporter: Joe Bohn > Assignee: Joe Bohn > Fix For: 1.0 > > Jetty has a statistics gathering and reporting capability that is support in > the console via the Web Server Manager portlet. We should provide similar > monitoring capabilities for tomcat. > However, the Jetty implementation is tightly bound to Jetty. We need a more > generic interface build upon the principles of JSR77 to address statistical > information for the web server (both jetty and tomcat). -- 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-1142) Thread in RMI Runtime ThreadGroup occasionally keeps stale MultiParentClassLoader alive
Thread in RMI Runtime ThreadGroup occasionally keeps stale MultiParentClassLoader alive --- Key: GERONIMO-1142 URL: http://issues.apache.org/jira/browse/GERONIMO-1142 Project: Geronimo Type: Bug Versions: 1.0-M5, 1.0 Environment: Win XP/Sun JDK 1.4.2 Reporter: Kevan Miller Priority: Minor Fix For: 1.1 Occasionally after a deploy/undeploy of DayTrader. A Thread will keep a stale instance of MultiParentClassLoader from being GC'ed. The chain of references is as follows: java.lang.Thread.inheritedAccessControlContext --> java.security.AccessControlContext.context --> java.security.ProtectionDomain[4] --> java.security.ProtectionDomain.classLoader --> org.apache.geronimo.kernel.config.MultiParentClassLoader The Thread is a member of the RMI Runtime ThreadGroup. -- 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
ClassLoader memory leaks
I've been battling a variety of ClassLoader-based memory leaks that occur during the deploy/undeploy of DayTrader. With the patches for the following problems, I no longer see MultiParentClassLoaders being leaked: http://issues.apache.org/jira/browse/GERONIMO-1125 (patch just posted) http://issues.apache.org/jira/browse/GERONIMO-1118 (fix committed) http://issues.apache.org/jira/browse/AXIS-2232 (Old patch didn't fix the problem. I've attached a new patch that fixes the problem. Yet to be committed) http://issues.apache.org/jira/browse/AXIS-2278 (Fix committed, but not picked up by Geronimo build) Deployment of DayTrader is still leaking memory (but only 200 kbytes per deploy/undeploy cycle. "only" is a relative term... ;-). So, there's still work to be done. Finally, there is an intermittent problem which will cause a Thread to temporarily hold on to a ClassLoader. Since the problem is intermittent and temporary, I'm not actively pursuing. I'll document the problem in a jira, but here's the chain of references keeping the ClassLoader alive... The Thread is in the RMI Runtime ThreadGroup. java.lang.Thread.inheritedAccessControlContext --> java.security.AccessControlContext.context --> java.security.ProtectionDomain[4] --> java.security.ProtectionDomain.classLoader --> org.apache.geronimo.kernel.config.MultiParentClassLoader --kevan
Re: [consolidation] next steps?
On 11/7/05, Dain Sundstrom <[EMAIL PROTECTED]> wrote:
> Good point Ken. How about we consider this thread the invite? So
> formally:
>
> We would like to invite the projects that Geronimo works with to
> consider joining Geronimo as a Subproject. If your project would
> like to join, we will either need a proposal to incubate the project,
> or a proposal to donate the code. In the case of incubation, the
> current committers will have immediate access to their code in the
> incubator, and in the case of an donation, the current committers
> will have to earn commit on Geronimo.
I'm not sure of the order in which all steps must occur, but we (the
Geronimo PMC) must also vote to accept each project per the Incubator
FAQ:
---
1.4. Someone has proposed that their code/project be donated to
project X within the ASF for continued development. What do we need to
do to accept the code?
The Incubator will only accept code for incubation if a PMC (project
management committee) or the Apache board has voted to accept it. So
when a proposal for the donation of code occurs, the project in
question should discuss the proposal internally, leading to a decision
by that project's PMC on whether or not to accept the code (and
potentially the project surrounding it) into the fold.
If the PMC agrees, then the incubator can be approached, and the code
accepted for incubation. The grant needs to be recorded by following
the procedure outlined at the Software Grants section of the ASF
Licenses page.
---
Beyond this, once a project has been voted in, the following
additional requirements must be met:
a) project license (must be AL 2.0)
b) the copyright must be assigned to the ASF
c) all committers must file a CLA with the ASF (if one is not already on file)
Please note that it is possible for some (or most) of these projects
to pass right on through the Incubator as long as the exit criteria
are met:
http://incubator.apache.org/incubation/Incubation_Policy.html#Exitting+the+Incubator
Also, here's the template that must be filled and submitted upon
importing each project into the Geronimo SVN repo:
http://svn.apache.org/viewcvs.cgi/incubator/public/trunk/site-author/projects/incubation-status-template.html?view=markup
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://www.castor.org/
Apache Geronimo
http://geronimo.apache.org/
[jira] Updated: (GERONIMO-1125) AbstractSinglePoolConnectionInterceptor$IdleReleaser keeps MultiParentClassLoaders alive
[ http://issues.apache.org/jira/browse/GERONIMO-1125?page=all ] Kevan Miller updated GERONIMO-1125: --- Geronimo Info: [Patch Available] Description: After a deploy/undeploy of DayTrader, the following chain of references (there are others which I'm investigating) is keeping a MultiClassLoader instance from being marked as available for GC. java.util.TaskQueue.queue --> java.util.TimerTask[128] java.util.TimerTask[5] --> org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor$IdleReleaser IdleReleaser.this$0 --> org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor SinglePoolConnectionInterceptor.next --> org.apache.geronimo.connector.outbound.XAResourceInsertionInterceptor XAResourceInsertionInterceptor.next --> org.apache.geronimo.connector.outbound.MCFConnectionInterceptor MCFConnectionInterceptor.stack --> org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor ConnectionTrackingInterceptor.next --> org.apache.geronimo.connector.outbound.TCCLInterceptor TCCLInterceptor.classLoader --> org.apache.geronimo.kernel.config.MultiParentClassLoader The default interval for the IdleReleaser TimerTask is 30 minutes. Plenty of time for us to run out of PermGen space. Currently the task is never cancelled. I'm working on cancelling the task. However, that's not sufficient. TimerTask.cancel() simply updates state. It doesn't remove the Task from the TimerQueue. So, the task lives until it expires (looks like this "feature" is fixed in 1.5). Easiest fix is to break the chain of references at the IdleReleaser task when the task is cancelled. This should be good enough. Alternative is to implement our own Timer -- which wouldn't be too hard... Or have multiple Timers and cancel the whole timer... I'm working on breaking the chain of references at IdleReleaser. Note that this means the IdleReleaser classloader will be kept alive until the TimerTask expires. However, the IdleReleaser classloader is a long-lived Geronimo class loader. So, this shouldn't be a problem, but it's not ideal, either... was: After a deploy/undeploy of DayTrader, the following chain of references (there are others which I'm investigating) is keeping a MultiClassLoader instance from being marked as available for GC. java.util.TaskQueue.queue --> java.util.TimerTask[128] java.util.TimerTask[5] --> org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor$IdleReleaser IdleReleaser.this$0 --> org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor SinglePoolConnectionInterceptor.next --> org.apache.geronimo.connector.outbound.XAResourceInsertionInterceptor XAResourceInsertionInterceptor.next --> org.apache.geronimo.connector.outbound.MCFConnectionInterceptor MCFConnectionInterceptor.stack --> org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor ConnectionTrackingInterceptor.next --> org.apache.geronimo.connector.outbound.TCCLInterceptor TCCLInterceptor.classLoader --> org.apache.geronimo.kernel.config.MultiParentClassLoader The default interval for the IdleReleaser TimerTask is 30 minutes. Plenty of time for us to run out of PermGen space. Currently the task is never cancelled. I'm working on cancelling the task. However, that's not sufficient. TimerTask.cancel() simply updates state. It doesn't remove the Task from the TimerQueue. So, the task lives until it expires (looks like this "feature" is fixed in 1.5). Easiest fix is to break the chain of references at the IdleReleaser task when the task is cancelled. This should be good enough. Alternative is to implement our own Timer -- which wouldn't be too hard... Or have multiple Timers and cancel the whole timer... I'm working on breaking the chain of references at IdleReleaser. Note that this means the IdleReleaser classloader will be kept alive until the TimerTask expires. However, the IdleReleaser classloader is a long-lived Geronimo class loader. So, this shouldn't be a problem, but it's not ideal, either... > AbstractSinglePoolConnectionInterceptor$IdleReleaser keeps > MultiParentClassLoaders alive > > > Key: GERONIMO-1125 > URL: http://issues.apache.org/jira/browse/GERONIMO-1125 > Project: Geronimo > Type: Bug > Components: connector > Versions: 1.0-M5 > Environment: JDK 1.4/WinXP > Reporter: Kevan Miller > Assignee: Kevan Miller > Fix For: 1.0 > Attachments: InterceptorDestroy.patch > > After a deploy/undeploy of DayTrader, the following chain of references > (there are others which I'm investigating) is keeping a MultiClassLoader > instance from being marked as available for GC. > java.util.TaskQueue.
[jira] Updated: (GERONIMO-1125) AbstractSinglePoolConnectionInterceptor$IdleReleaser keeps MultiParentClassLoaders alive
[ http://issues.apache.org/jira/browse/GERONIMO-1125?page=all ] Kevan Miller updated GERONIMO-1125: --- Attachment: InterceptorDestroy.patch The attached patch breaks the chain of strong references that will keep MultiParentClassLoaders alive. It also performs additional cleanup of ManagedConnections maintained by Pooling Interceptors. ConnectionInterceptor interface has a new destroy() method. AbstractConnectionManager now implements GBeanLifeCycle. doStop() or doFail() will cause destroy() to be called on the stack of ConnectionInterceptors. destroy() will cause the IdleReleaser TimerTask (if one exists) to be cancelled. Also, any Pooled ManagedConnections will be destroyed. If a ManagedConnection is returned after a PoolInterceptor has been destroyed, the ManagedConnection is destroyed during returnConnection() processing. Finally, if getConnection() is called on a destroyed Pooling Interceptor, a ResourceException will be thrown. > AbstractSinglePoolConnectionInterceptor$IdleReleaser keeps > MultiParentClassLoaders alive > > > Key: GERONIMO-1125 > URL: http://issues.apache.org/jira/browse/GERONIMO-1125 > Project: Geronimo > Type: Bug > Components: connector > Versions: 1.0-M5 > Environment: JDK 1.4/WinXP > Reporter: Kevan Miller > Assignee: Kevan Miller > Fix For: 1.0 > Attachments: InterceptorDestroy.patch > > After a deploy/undeploy of DayTrader, the following chain of references > (there are others which I'm investigating) is keeping a MultiClassLoader > instance from being marked as available for GC. > java.util.TaskQueue.queue --> java.util.TimerTask[128] > java.util.TimerTask[5] --> > org.apache.geronimo.connector.outbound.AbstractSinglePoolConnectionInterceptor$IdleReleaser > IdleReleaser.this$0 --> > org.apache.geronimo.connector.outbound.SinglePoolConnectionInterceptor > SinglePoolConnectionInterceptor.next --> > org.apache.geronimo.connector.outbound.XAResourceInsertionInterceptor > XAResourceInsertionInterceptor.next --> > org.apache.geronimo.connector.outbound.MCFConnectionInterceptor > MCFConnectionInterceptor.stack --> > org.apache.geronimo.connector.outbound.ConnectionTrackingInterceptor > ConnectionTrackingInterceptor.next --> > org.apache.geronimo.connector.outbound.TCCLInterceptor > TCCLInterceptor.classLoader --> > org.apache.geronimo.kernel.config.MultiParentClassLoader > The default interval for the IdleReleaser TimerTask is 30 minutes. Plenty of > time for us to run out of PermGen space. Currently the task is never > cancelled. I'm working on cancelling the task. However, that's not > sufficient. TimerTask.cancel() simply updates state. It doesn't remove the > Task from the TimerQueue. So, the task lives until it expires (looks like > this "feature" is fixed in 1.5). Easiest fix is to break the chain of > references at the IdleReleaser task when the task is cancelled. This should > be good enough. Alternative is to implement our own Timer -- which wouldn't > be too hard... Or have multiple Timers and cancel the whole timer... > I'm working on breaking the chain of references at IdleReleaser. Note that > this means the IdleReleaser classloader will be kept alive until the > TimerTask expires. However, the IdleReleaser classloader is a long-lived > Geronimo class loader. So, this shouldn't be a problem, but it's not ideal, > either... -- 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: [consolidation] next steps?
Do you have a link for proposal for incubation? Jeff Dain Sundstrom wrote: Good point Ken. How about we consider this thread the invite? So formally: We would like to invite the projects that Geronimo works with to consider joining Geronimo as a Subproject. If your project would like to join, we will either need a proposal to incubate the project, or a proposal to donate the code. In the case of incubation, the current committers will have immediate access to their code in the incubator, and in the case of an donation, the current committers will have to earn commit on Geronimo. -dain On Nov 4, 2005, at 1:43 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: I was thinking that it would be nice to send an invitation to the projects to join the Geronimo community as a subproject. The invitation letter would simply state our interest in having the project join Geronimo and if they accept, to prepare a proposal for the incubator. When the proposals are ready, we would vote to accept the project and forward it to incubator. I think that might be a little overpowering. How about having people in the projects approach their own community and float the idea? 'What do you think about joining Geronimo? I hear they'd be glad to have us if we wanted to do it..' As much as possible it should be driven by the projects wanting to join rather than by Geronimo wanting them. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ2vV55rNPMCpn3XdAQLb6wQAuxhFibQkK842F83f77h3UL+d6V4A+odf OQEaZDiE1z10eWMB+M4deLJY80h4b+bbtMCaV6l/F5KIrx/pFmr8JhI22q8WM3/J Rw2QAmawHXxRMGhrPCNZfwTmPO5B64XQjrfK8m/uPUVaDXxkl2MxUwV/q87zVU7t g0IIdGRQPUk= =D6cv -END PGP SIGNATURE-
Re: [consolidation] next steps?
Good point Ken. How about we consider this thread the invite? So formally: We would like to invite the projects that Geronimo works with to consider joining Geronimo as a Subproject. If your project would like to join, we will either need a proposal to incubate the project, or a proposal to donate the code. In the case of incubation, the current committers will have immediate access to their code in the incubator, and in the case of an donation, the current committers will have to earn commit on Geronimo. -dain On Nov 4, 2005, at 1:43 PM, Rodent of Unusual Size wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: I was thinking that it would be nice to send an invitation to the projects to join the Geronimo community as a subproject. The invitation letter would simply state our interest in having the project join Geronimo and if they accept, to prepare a proposal for the incubator. When the proposals are ready, we would vote to accept the project and forward it to incubator. I think that might be a little overpowering. How about having people in the projects approach their own community and float the idea? 'What do you think about joining Geronimo? I hear they'd be glad to have us if we wanted to do it..' As much as possible it should be driven by the projects wanting to join rather than by Geronimo wanting them. - -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Ken.Coar.Org/ Author, developer, opinionist http://Apache-Server.Com/ "Millennium hand and shrimp!" -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQCVAwUBQ2vV55rNPMCpn3XdAQLb6wQAuxhFibQkK842F83f77h3UL+d6V4A+odf OQEaZDiE1z10eWMB+M4deLJY80h4b+bbtMCaV6l/F5KIrx/pFmr8JhI22q8WM3/J Rw2QAmawHXxRMGhrPCNZfwTmPO5B64XQjrfK8m/uPUVaDXxkl2MxUwV/q87zVU7t g0IIdGRQPUk= =D6cv -END PGP SIGNATURE-
Re: 1.0 Feature List - Input Requested
Jeff Genender wrote: Aaron Mulder wrote: The things I'd like to see in 1.0 are: - More console work - Remote deployment - Hot deploy directory - Bundled JavaMail with SMTP support - Separate Jetty and Tomcat ZIP/TAR distributions - A working installer distribution - Bug fixes I'm not that keen on introducing clustering, WADI, or extra LDAP integration if they are going to impact the stability/testing for 1.0 -- that's the kind of stuff I'd prefer to put in a branch until after the release. No reason that clustering would impact stability at all. They are just GBeans in a normally off position since 95% of the users won't need them on. Agreed - so no downside. On the upside, Clustering is one of the major features that separates a small scale server from an enterprise-strength implementation. Having some form of clustering in the 1.0 will send out a powerful signal that we intend to be a serious contender. Jules LDAP is fully integrated and was part of the M5 release. Whats the issue here? Thanks, Aaron On 11/7/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I saw the Virtuas announcement last week based on their Geronimo support. Very nice. One thing that caught my eye on their web site was 36 days to ApacheCon. It made me realize that in order to make 1.0 we only have 30 something days to make it. With CTS and Thanksgiving in between there is not a lot of time to get all the things done we want. Here is a list of items that have been going around on the list and wanted to get people's feedback in terms of what has to be there for 1.0 and my initial SWAG as to the importance. Please feel free to comment / change the items below . Console patches and UI updates (example User & Group Mgt for console). Gbean for Tomcat for clustering (Jeff G) WADI integration (tech preview possibly, not required) Directory restructure (will be done after TCK is verified... we want to control the number of changes) JavaMail LDAP Apache Directory (using Tomcat) Debug Console Remote Deploy DayTrader Install - maven update needed Hot Deploy (file based) (Jacek) Packaging changes (Maven respository) wait for Dave J. Dain indicated that maven code won't make 1.0. In addition to that there are a number of JIRAs out there as well. I noticed a lot of activity in getting them closed so that is excellent. I'll finish adjusting the fix version today to 1.0, 1.1 and 1.x. Once that's complete and we agree on the JIRAs, features, etc. we can see where we'll land. My apologies for being behind on this. Cheers, Matt -- "Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it." /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training & Support. **/
Re: XADataSource Pools
On Sun, 6 Nov 2005, Bruce Snyder wrote: On 11/6/05, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: Could you point me to an example or more specific instructions? I'm just trying to figure out how to configure PostgreSQL XADataSource with Geronimo. Oddly enough, I began looking into the same thing this morning, but I don't see an XADataSource as part of the PostgreSQL JDBC driver distirbution (postgresql-8.0-312.jdbc3.jar). However, I did stumble upon a message from you on the pgsql-jdbc list: http://archives.postgresql.org/pgsql-jdbc/2005-09/msg00131.php What's the status of this XADataSource? It was checked in CVS last week. It's included in the "8.1 build 404" version: http://jdbc.postgresql.org/download.html Note that it requires server version 8.1 since two-phase commit is a new feature in that release. - Heikki
Re: Netbeans integration and tooling
Not that I know of. What to start something? :) Dustin Little wrote: Has anyone begun work on integration and tooling for Netbeans IDE?
Re: 1.0 Feature List - Input Requested
Matt, I like this list. Time to get cracking! Jeff Matt Hogstrom wrote: I saw the Virtuas announcement last week based on their Geronimo support. Very nice. One thing that caught my eye on their web site was 36 days to ApacheCon. It made me realize that in order to make 1.0 we only have 30 something days to make it. With CTS and Thanksgiving in between there is not a lot of time to get all the things done we want. Here is a list of items that have been going around on the list and wanted to get people's feedback in terms of what has to be there for 1.0 and my initial SWAG as to the importance. Please feel free to comment / change the items below . Console patches and UI updates (example User & Group Mgt for console). Gbean for Tomcat for clustering (Jeff G) WADI integration (tech preview possibly, not required) Directory restructure (will be done after TCK is verified... we want to control the number of changes) JavaMail LDAP Apache Directory (using Tomcat) Debug Console Remote Deploy DayTrader Install - maven update needed Hot Deploy (file based) (Jacek) Packaging changes (Maven respository) wait for Dave J. Dain indicated that maven code won't make 1.0. In addition to that there are a number of JIRAs out there as well. I noticed a lot of activity in getting them closed so that is excellent. I'll finish adjusting the fix version today to 1.0, 1.1 and 1.x. Once that's complete and we agree on the JIRAs, features, etc. we can see where we'll land. My apologies for being behind on this. Cheers, Matt
Netbeans integration and tooling
Has anyone begun work on integration and tooling for Netbeans IDE?
Re: deploy:startRemoteServer verbosity parameter
Great idea ! Thanks! I've wanted this! david jencks On Nov 7, 2005, at 12:52 AM, Jacek Laskowski wrote: Hi, Currently, deploy:startRemoteServer has the -quiet parameter hardcoded. I'm going to extend the plugin to accept *verbosity* attribute. It won't have any impact on the existing scripts unless the parameter is specified. Otherwise, the plugin will assume -quiet. So, if one wants to start a Geronimo instance with -vv parameter, it would boild down to the following snippet: Comments? Jacek
Re: 1.0 Feature List - Input Requested
Aaron Mulder wrote: The things I'd like to see in 1.0 are: - More console work - Remote deployment - Hot deploy directory - Bundled JavaMail with SMTP support - Separate Jetty and Tomcat ZIP/TAR distributions - A working installer distribution - Bug fixes I'm not that keen on introducing clustering, WADI, or extra LDAP integration if they are going to impact the stability/testing for 1.0 -- that's the kind of stuff I'd prefer to put in a branch until after the release. No reason that clustering would impact stability at all. They are just GBeans in a normally off position since 95% of the users won't need them on. LDAP is fully integrated and was part of the M5 release. Whats the issue here? Thanks, Aaron On 11/7/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I saw the Virtuas announcement last week based on their Geronimo support. Very nice. One thing that caught my eye on their web site was 36 days to ApacheCon. It made me realize that in order to make 1.0 we only have 30 something days to make it. With CTS and Thanksgiving in between there is not a lot of time to get all the things done we want. Here is a list of items that have been going around on the list and wanted to get people's feedback in terms of what has to be there for 1.0 and my initial SWAG as to the importance. Please feel free to comment / change the items below . Console patches and UI updates (example User & Group Mgt for console). Gbean for Tomcat for clustering (Jeff G) WADI integration (tech preview possibly, not required) Directory restructure (will be done after TCK is verified... we want to control the number of changes) JavaMail LDAP Apache Directory (using Tomcat) Debug Console Remote Deploy DayTrader Install - maven update needed Hot Deploy (file based) (Jacek) Packaging changes (Maven respository) wait for Dave J. Dain indicated that maven code won't make 1.0. In addition to that there are a number of JIRAs out there as well. I noticed a lot of activity in getting them closed so that is excellent. I'll finish adjusting the fix version today to 1.0, 1.1 and 1.x. Once that's complete and we agree on the JIRAs, features, etc. we can see where we'll land. My apologies for being behind on this. Cheers, Matt
Re: 1.0 Feature List - Input Requested
The things I'd like to see in 1.0 are: - More console work - Remote deployment - Hot deploy directory - Bundled JavaMail with SMTP support - Separate Jetty and Tomcat ZIP/TAR distributions - A working installer distribution - Bug fixes I'm not that keen on introducing clustering, WADI, or extra LDAP integration if they are going to impact the stability/testing for 1.0 -- that's the kind of stuff I'd prefer to put in a branch until after the release. Thanks, Aaron On 11/7/05, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > I saw the Virtuas announcement last week based on their Geronimo support. > Very > nice. One thing that caught my eye on their web site was 36 days to > ApacheCon. > It made me realize that in order to make 1.0 we only have 30 something days > to > make it. With CTS and Thanksgiving in between there is not a lot of time to > get > all the things done we want. > > Here is a list of items that have been going around on the list and wanted to > get people's feedback in terms of what has to be there for 1.0 and my initial > SWAG as to the importance. Please feel free to comment / change the items > below . > > Console patches and UI updates (example User & Group Mgt for console). > Gbean for Tomcat for clustering (Jeff G) > WADI integration (tech preview possibly, not required) > Directory restructure (will be done after TCK is verified... we want to > control > the number of changes) > JavaMail > LDAP Apache Directory (using Tomcat) > Debug Console > Remote Deploy > DayTrader > Install - maven update needed > Hot Deploy (file based) (Jacek) > Packaging changes (Maven respository) wait for Dave J. Dain indicated that > maven code won't make 1.0. > > In addition to that there are a number of JIRAs out there as well. I noticed > a > lot of activity in getting them closed so that is excellent. I'll finish > adjusting the fix version today to 1.0, 1.1 and 1.x. Once that's complete and > we agree on the JIRAs, features, etc. we can see where we'll land. > > My apologies for being behind on this. > > Cheers, > > Matt > >
Copyright dates
All, I've recently noticed a number of files being modified and even added with incorrect years in the Copyright/License prologue. It's an easy mistake to make. I'm probably guilty of submitting patches that did not appropriately update the copyright year. Is there an official policy for Copyright year? How rigorous are we expected to be? ASF must have a policy and I'm confident that we're not complying... Do we need a plan to (attempt to) rectify these oversights prior to V1? --kevan
Thoughts on branching for 1.0
Its probably time to start thinking about branching to stabilize a 1.0 branch given the short time frame. What is the general consensus on when this makes sense?
1.0 Feature List - Input Requested
I saw the Virtuas announcement last week based on their Geronimo support. Very nice. One thing that caught my eye on their web site was 36 days to ApacheCon. It made me realize that in order to make 1.0 we only have 30 something days to make it. With CTS and Thanksgiving in between there is not a lot of time to get all the things done we want. Here is a list of items that have been going around on the list and wanted to get people's feedback in terms of what has to be there for 1.0 and my initial SWAG as to the importance. Please feel free to comment / change the items below . Console patches and UI updates (example User & Group Mgt for console). Gbean for Tomcat for clustering (Jeff G) WADI integration (tech preview possibly, not required) Directory restructure (will be done after TCK is verified... we want to control the number of changes) JavaMail LDAP Apache Directory (using Tomcat) Debug Console Remote Deploy DayTrader Install - maven update needed Hot Deploy (file based) (Jacek) Packaging changes (Maven respository) wait for Dave J. Dain indicated that maven code won't make 1.0. In addition to that there are a number of JIRAs out there as well. I noticed a lot of activity in getting them closed so that is excellent. I'll finish adjusting the fix version today to 1.0, 1.1 and 1.x. Once that's complete and we agree on the JIRAs, features, etc. we can see where we'll land. My apologies for being behind on this. Cheers, Matt
CORBA
I submitted a patch for GERONIMO- some time last week, and all I have heard back is that the JIRA entry now says "patch available". Apparently the changes have not been submitted to the trunk; is there anything else I should do to make that happen? It's rather challenging to work effectively here if we cannot share code through a source repository. I understand that you cannot guarantee any particular turn around, but if it is this slow then I might as well work out of a local source repository here and then submit a new tar ball every once in a while. FYI, we have spent some time last week on the build setup, M2 and figuring a good way to do tests and in general just figuring out how to "play by the rules here" in the geronimo build world. Kresten Krab Thorup [EMAIL PROTECTED] "We do not inherit the Earth from our parents, we borrow it from our children." Saint Exupery
[jira] Assigned: (GERONIMO-1099) Error Uninstalling an application - cannot re-install application or restart server
[ http://issues.apache.org/jira/browse/GERONIMO-1099?page=all ] Joe Bohn reassigned GERONIMO-1099: -- Assign To: Joe Bohn > Error Uninstalling an application - cannot re-install application or restart > server > --- > > Key: GERONIMO-1099 > URL: http://issues.apache.org/jira/browse/GERONIMO-1099 > Project: Geronimo > Type: Bug > Components: console > Versions: 1.0-M5 > Reporter: Dave Colasurdo > Assignee: Joe Bohn > Fix For: 1.0 > > Using the admin console: > 1)Install an application (e.g. servlets-example) > 2)Uninstall the application (without first stopping the application) > This results in the following error: > 13:53:16,772 ERROR [GBeanInstance] GBeanInstance should already be stopped > before die() is called: > objectName=geronimo.server:J2EEApplication=null,J2EEServer=geronimo,Servlet=invoker,WebFilter=Servlet > Mapped Filter,WebModule=servlets-examples,j2eeType=WebFilterMapping > state=starting > 13:53:16,772 ERROR [GBeanInstance] GBeanInstance should already be stopped > before die() is called: > objectName=geronimo.server:J2EEApplication=null,J2EEServer=geronimo,URLPattern="/servlet/\*",WebFilter=Path > Mapped Filter,WebModule=servlets- > examples,j2eeType=WebFilterMapping state=starting > However, the application is removed from both the directory structure and > index.properties is updated. > I cannot re-install the application from the console.. The error is ""Module > servlets-examples already exists in the server. Try to undeploy it first or > use the redeploy command." There is nothing to undeploy in the list!!! > Also, after stopping the server, cannot restart it .. get the following error: > Booting Geronimo Kernel (in Java 1.4.2_08)... > Starting Geronimo Application Server > [***- ] 89% 23s Startup failed > org.apache.geronimo.kernel.config.NoSuchConfigException: No configuration > with id: servlets-examples > at > org.apache.geronimo.kernel.config.ConfigurationManagerImpl.load(ConfigurationManagerImpl.java:111) > at > org.apache.geronimo.kernel.config.ConfigurationManagerImpl.loadRecursive(ConfigurationManagerImpl.java:178) > at > org.apache.geronimo.kernel.config.ConfigurationManagerImpl.loadRecursive(ConfigurationManagerImpl.java:167) > at > org.apache.geronimo.kernel.config.ConfigurationManagerImpl$$FastClassByCGLIB$$fbed85d2.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:118) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:760) > at > org.apache.geronimo.gbean.runtime.RawInvoker.invoke(RawInvoker.java:57) > at > org.apache.geronimo.kernel.basic.RawOperationInvoker.invoke(RawOperationInvoker.java:36) > at > org.apache.geronimo.kernel.basic.ProxyMethodInterceptor.intercept(ProxyMethodInterceptor.java:96) > at > org.apache.geronimo.kernel.config.ConfigurationManager$$EnhancerByCGLIB$$5ded6b6b.loadRecursive() > at org.apache.geronimo.system.main.Daemon.doStartup(Daemon.java:232) > at org.apache.geronimo.system.main.Daemon.(Daemon.java:78) > at org.apache.geronimo.system.main.Daemon.main(Daemon.java:320) > Server shutdown begun p failed > Server shutdown completed > If the application is stopped before being uninstalled (between steps 1 and 2 > above) , everything works fine... -- 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] Closed: (GERONIMO-1063) Viewing server logs results in warning message in command prompt
[ http://issues.apache.org/jira/browse/GERONIMO-1063?page=all ] Joe Bohn closed GERONIMO-1063: -- > Viewing server logs results in warning message in command prompt > > > Key: GERONIMO-1063 > URL: http://issues.apache.org/jira/browse/GERONIMO-1063 > Project: Geronimo > Type: Bug > Components: console > Versions: 1.0-M5 > Environment: all > Reporter: Joe Bohn > Assignee: Aaron Mulder > Priority: Minor > Fix For: 1.0 > Attachments: debug.patch, debug.patch > > A warning message that should only appear in the log is presented in the > command prompt when the web server log portlet is displayed. > 09:16:32,952 WARN [KernelManagementHelper] Checking access log for > geronimo.ser > ver:J2EEApplication=null,J2EEModule=org/apache/geronimo/Tomcat,J2EEServer=geroni > mo,j2eeType=GBean,name=TomcatWebManager / > geronimo.server:J2EEApplication=null,J > 2EEModule=org/apache/geronimo/Tomcat,J2EEServer=geronimo,j2eeType=GBean,name=Tom > catWebContainer -- 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
deploy:startRemoteServer verbosity parameter
Hi, Currently, deploy:startRemoteServer has the -quiet parameter hardcoded. I'm going to extend the plugin to accept *verbosity* attribute. It won't have any impact on the existing scripts unless the parameter is specified. Otherwise, the plugin will assume -quiet. So, if one wants to start a Geronimo instance with -vv parameter, it would boild down to the following snippet: Comments? Jacek
[jira] Commented: (GERONIMO-1124) bouncycastle/jars/bcprov-jdk14-124.jar not found
[
http://issues.apache.org/jira/browse/GERONIMO-1124?page=comments#action_12356936
]
kenperl commented on GERONIMO-1124:
---
the 240th line is commented out, I know you are refer the ejb line,
where could I change the value of ${geronimo.openejb.cvs.access}?
> bouncycastle/jars/bcprov-jdk14-124.jar not found
>
>
> Key: GERONIMO-1124
> URL: http://issues.apache.org/jira/browse/GERONIMO-1124
> Project: Geronimo
> Type: Bug
> Components: buildsystem
> Versions: 1.0-M5
> Environment: linux, maven1.02
> Reporter: kenperl
> Priority: Blocker
>
> I don't use my own build.properties file. type maven in the directory where
> the source codes checked out from HEAD.
> I am using online building.
> BUILD FAILED
> File.. /root/.maven/cache/maven-multiproject-plugin-1.3.1/plugin.jelly
> Element... maven:reactor
> Line.. 217
> Column 9
> Unable to obtain goal [default] --
> /root/geronimo1.0/modules/assembly/maven.xml:358:15:
> org.apache.geronimo.kernel.repository.MissingDependencyException: uri
> bouncycastle/jars/bcprov-jdk14-124.jar not found in repository
> Total time: 106 minutes 49 seconds
--
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
New DB Pool Deployer Portlet
I just put in a start of a new portlet for managing database pools. Right now it has a nice interface for creating pools, but a pretty basic pool list and no editing or monitoring features. But it was a pretty big update, so it would be great if someone could give it a spin and let me know how it goes (go to the console, select "Database Pools" then "Add new database pool" and just don't pick "Other" for the database type). You need to have your driver JAR installed in the repository (somewhere under geronimo/repository). Thanks, Aaron
[jira] Commented: (GERONIMO-1137) Proper DConfigBeans for Connectors
[ http://issues.apache.org/jira/browse/GERONIMO-1137?page=comments#action_12356934 ] Aaron Mulder commented on GERONIMO-1137: As of revision 331239, used by the console to create database deployment plans. > Proper DConfigBeans for Connectors > -- > > Key: GERONIMO-1137 > URL: http://issues.apache.org/jira/browse/GERONIMO-1137 > Project: Geronimo > Type: Improvement > Components: connector, deployment > Versions: 1.0-M5 > Reporter: Aaron Mulder > Assignee: Aaron Mulder > Fix For: 1.0 > > The best way for the console to properly deploy DB pools and JMS resources is > to use JSR-88, so... if we only had DConfigBeans, the console wouldn't be > maintaining templates for deployment plans. :) -- 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] Resolved: (GERONIMO-1138) Revise database pool creation portlet to use JSR-88
[ http://issues.apache.org/jira/browse/GERONIMO-1138?page=all ] Aaron Mulder resolved GERONIMO-1138: Resolution: Fixed Revision 331239 > Revise database pool creation portlet to use JSR-88 > --- > > Key: GERONIMO-1138 > URL: http://issues.apache.org/jira/browse/GERONIMO-1138 > Project: Geronimo > Type: Bug > Components: deployment, databases, console, connector > Versions: 1.0-M5 > Reporter: Aaron Mulder > Assignee: Aaron Mulder > Fix For: 1.0 > > Update the database pool portlet so that instead of manually assembling a > deployment plan and deploying it, it uses JSR-88 DConfigBeans and the JSR-88 > DeploymentManager to do all that. -- 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
