[jira] Created: (GERONIMODEVTOOLS-186) Duplicate License Headers in source
Duplicate License Headers in source --- Key: GERONIMODEVTOOLS-186 URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-186 Project: Geronimo-Devtools Issue Type: Bug Components: eclipse-plugin Affects Versions: 2.0 Reporter: Shiva Kumar H R Priority: Minor Fix For: 2.0 While reviewing the commits of GERONIMODEVTOOLS-184 observed that \modules\eclipse-support\pom.xml has duplicate license header. A look at it's svn log showed that this was a mistake from GERONIMODEVTOOLS-114. Friend 'Anil Kainikara' very quickly wrote an useful script "ListFilesWithDuplicateLicenseHeaders.ksh". Upon executing this on devtools-trunk, found that following files have such duplicate license headers: ./modules/eclipse-support/src/main/schema/xmlconfig.xml ./modules/eclipse-support/src/main/schema/eclipse-deployable-1.0.xsd ./modules/eclipse-support/pom.xml ./plugins/org.apache.geronimo.st.core/src/org/apache/geronimo/st/core/commands/IDeploymentCommand.java ./plugins/org.apache.geronimo.st.core/src/org/apache/geronimo/st/core/commands/StartCommand.java ./plugins/org.apache.geronimo.st.core/src/org/apache/geronimo/st/core/commands/SynchronizedDeploymentOp.java Patch attached removes these duplicate license headers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (XBEAN-91) o.a.x.p.DateEditor.toObjectImpl throws exception when date format is in different locale than the default one
[ https://issues.apache.org/jira/browse/XBEAN-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Laskowski closed XBEAN-91. Resolution: Fixed Fix Version/s: 3.2 $ svn ci . ... Sendingxbean-reflect/pom.xml Sending xbean-reflect/src/main/java/org/apache/xbean/propertyeditor/DateEditor.java Adding xbean-reflect/src/test/java/org/apache/xbean/propertyeditor Adding xbean-reflect/src/test/java/org/apache/xbean/propertyeditor/DateEditorTest.java Transmitting file data ... Committed revision 568491. > o.a.x.p.DateEditor.toObjectImpl throws exception when date format is in > different locale than the default one > - > > Key: XBEAN-91 > URL: https://issues.apache.org/jira/browse/XBEAN-91 > Project: XBean > Issue Type: Bug > Components: reflect >Affects Versions: 3.1 >Reporter: Jacek Laskowski >Assignee: Jacek Laskowski > Fix For: 3.2 > > Attachments: XBEAN-91.patch > > > There's the expanded-env-entries sample that uses a date in Locale.US format > with DateFormat.MEDIUM style. It didn't run well on Polish locale (pl) and > XBean's org.apache.xbean.propertyeditor.DateEditorTest.testToObjectImpl kept > throwing "java.text.ParseException: Unparseable date: "Mar 1, 1954"" > exception. > Attached is a patch for it. I'm not happy with it (I think it might've been > written better), so I haven't applied it to the repo, but rather attach it > here for others to look at it and correct where applicable. > p.s. The "Unreleased Versions" contains 3.1 which should be 3.2, I guess. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-186) Duplicate License Headers in source
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R updated GERONIMODEVTOOLS-186: - Attachment: GERONIMODEVTOOLS-186.patch ListFilesWithDuplicateLicenseHeaders.ksh > Duplicate License Headers in source > --- > > Key: GERONIMODEVTOOLS-186 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-186 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0 >Reporter: Shiva Kumar H R >Priority: Minor > Fix For: 2.0 > > Attachments: GERONIMODEVTOOLS-186.patch, > ListFilesWithDuplicateLicenseHeaders.ksh > > > While reviewing the commits of GERONIMODEVTOOLS-184 observed that > \modules\eclipse-support\pom.xml has duplicate license header. A look at it's > svn log showed that this was a mistake from GERONIMODEVTOOLS-114. > Friend 'Anil Kainikara' very quickly wrote an useful script > "ListFilesWithDuplicateLicenseHeaders.ksh". Upon executing this on > devtools-trunk, found that following files have such duplicate license > headers: > ./modules/eclipse-support/src/main/schema/xmlconfig.xml > ./modules/eclipse-support/src/main/schema/eclipse-deployable-1.0.xsd > ./modules/eclipse-support/pom.xml > ./plugins/org.apache.geronimo.st.core/src/org/apache/geronimo/st/core/commands/IDeploymentCommand.java > ./plugins/org.apache.geronimo.st.core/src/org/apache/geronimo/st/core/commands/StartCommand.java > ./plugins/org.apache.geronimo.st.core/src/org/apache/geronimo/st/core/commands/SynchronizedDeploymentOp.java > Patch attached removes these duplicate license headers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMODEVTOOLS-186) Duplicate License Headers in source
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shiva Kumar H R reassigned GERONIMODEVTOOLS-186: Assignee: Tim McConnell > Duplicate License Headers in source > --- > > Key: GERONIMODEVTOOLS-186 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-186 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0 >Reporter: Shiva Kumar H R >Assignee: Tim McConnell >Priority: Minor > Fix For: 2.0 > > Attachments: GERONIMODEVTOOLS-186.patch, > ListFilesWithDuplicateLicenseHeaders.ksh > > > While reviewing the commits of GERONIMODEVTOOLS-184 observed that > \modules\eclipse-support\pom.xml has duplicate license header. A look at it's > svn log showed that this was a mistake from GERONIMODEVTOOLS-114. > Friend 'Anil Kainikara' very quickly wrote an useful script > "ListFilesWithDuplicateLicenseHeaders.ksh". Upon executing this on > devtools-trunk, found that following files have such duplicate license > headers: > ./modules/eclipse-support/src/main/schema/xmlconfig.xml > ./modules/eclipse-support/src/main/schema/eclipse-deployable-1.0.xsd > ./modules/eclipse-support/pom.xml > ./plugins/org.apache.geronimo.st.core/src/org/apache/geronimo/st/core/commands/IDeploymentCommand.java > ./plugins/org.apache.geronimo.st.core/src/org/apache/geronimo/st/core/commands/StartCommand.java > ./plugins/org.apache.geronimo.st.core/src/org/apache/geronimo/st/core/commands/SynchronizedDeploymentOp.java > Patch attached removes these duplicate license headers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMODEVTOOLS-186) Duplicate License Headers in source
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Laskowski reassigned GERONIMODEVTOOLS-186: Assignee: Jacek Laskowski (was: Tim McConnell) > Duplicate License Headers in source > --- > > Key: GERONIMODEVTOOLS-186 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-186 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0 >Reporter: Shiva Kumar H R >Assignee: Jacek Laskowski >Priority: Minor > Fix For: 2.0 > > Attachments: GERONIMODEVTOOLS-186.patch, > ListFilesWithDuplicateLicenseHeaders.ksh > > > While reviewing the commits of GERONIMODEVTOOLS-184 observed that > \modules\eclipse-support\pom.xml has duplicate license header. A look at it's > svn log showed that this was a mistake from GERONIMODEVTOOLS-114. > Friend 'Anil Kainikara' very quickly wrote an useful script > "ListFilesWithDuplicateLicenseHeaders.ksh". Upon executing this on > devtools-trunk, found that following files have such duplicate license > headers: > ./modules/eclipse-support/src/main/schema/xmlconfig.xml > ./modules/eclipse-support/src/main/schema/eclipse-deployable-1.0.xsd > ./modules/eclipse-support/pom.xml > ./plugins/org.apache.geronimo.st.core/src/org/apache/geronimo/st/core/commands/IDeploymentCommand.java > ./plugins/org.apache.geronimo.st.core/src/org/apache/geronimo/st/core/commands/StartCommand.java > ./plugins/org.apache.geronimo.st.core/src/org/apache/geronimo/st/core/commands/SynchronizedDeploymentOp.java > Patch attached removes these duplicate license headers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMODEVTOOLS-186) Duplicate License Headers in source
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacek Laskowski closed GERONIMODEVTOOLS-186. Resolution: Fixed Assignee: Shiva Kumar H R (was: Jacek Laskowski) Committed revision 568527. Thanks Shiva Kumar H R! > Duplicate License Headers in source > --- > > Key: GERONIMODEVTOOLS-186 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-186 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 2.0 >Reporter: Shiva Kumar H R >Assignee: Shiva Kumar H R >Priority: Minor > Fix For: 2.0 > > Attachments: GERONIMODEVTOOLS-186.patch, > ListFilesWithDuplicateLicenseHeaders.ksh > > > While reviewing the commits of GERONIMODEVTOOLS-184 observed that > \modules\eclipse-support\pom.xml has duplicate license header. A look at it's > svn log showed that this was a mistake from GERONIMODEVTOOLS-114. > Friend 'Anil Kainikara' very quickly wrote an useful script > "ListFilesWithDuplicateLicenseHeaders.ksh". Upon executing this on > devtools-trunk, found that following files have such duplicate license > headers: > ./modules/eclipse-support/src/main/schema/xmlconfig.xml > ./modules/eclipse-support/src/main/schema/eclipse-deployable-1.0.xsd > ./modules/eclipse-support/pom.xml > ./plugins/org.apache.geronimo.st.core/src/org/apache/geronimo/st/core/commands/IDeploymentCommand.java > ./plugins/org.apache.geronimo.st.core/src/org/apache/geronimo/st/core/commands/StartCommand.java > ./plugins/org.apache.geronimo.st.core/src/org/apache/geronimo/st/core/commands/SynchronizedDeploymentOp.java > Patch attached removes these duplicate license headers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Geronimo RTC Workflow Scheme v2 in JIRA still in use
Hi, Just spot it while working with issues in XBean and Geronimo Devtools JIRAs that Geronimo RTC Workflow Scheme v2 is still in use. I meant to change it to Default (None?), but the note - "Note: It is recommended to backup JIRA data before proceeding with the workflow association." in the Associate Workflow Scheme to Project wizard scared me. How should the JIRA scheme in XBean and Geronimo Devtools be changed? Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Downloading G v2.0.1 requires confluence account ?
Hi Poking around on the geronimo site I just noticed that downloading of release v2.0.1 requires a Confluence account. As I am able to get to the download links for all other versions i suspect this may be a mistake or could it be a new behavior you want? regards Peter Petersson
Re: Downloading G v2.0.1 requires confluence account ?
On 8/22/07, Peter Petersson <[EMAIL PROTECTED]> wrote: > Hi > > Poking around on the geronimo site I just noticed that downloading of > release v2.0.1 requires a Confluence account. > As I am able to get to the download links for all other versions i > suspect this may be a mistake or could it be a new behavior you want? Good catch! I don't know why it's set like this, but the page is really in restricted mode atm. Probably we're awaiting press announcement before opening it up to the public. I don't really know. But then, the bits are in public already - http://www.apache.org/dist/geronimo/2.0.1/. Thanks for reporting. http://cwiki.apache.org/confluence/pages/pageinfo.action?pageId=63737 Page Permissions Page restrictions: Only users in group geronimo-committers can view this page. (set by Hernan Cunico at Aug 13, 2007 12:39) [Remove] Only users in group geronimo-committers can edit this page. (set by Hernan Cunico at Aug 13, 2007 12:39) [Remove] Hernan, why is that? Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Commented: (GERONIMO-2567) Remote admin of server using deployer.jar fails to connect
[ https://issues.apache.org/jira/browse/GERONIMO-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521747 ] Jacek Laskowski commented on GERONIMO-2567: --- http://cwiki.apache.org/confluence/display/GMOxKB/Remote+admin+using+deployer.jar+fails+to+connect+when+IPv6+is+used Couldn't we wrap the IPv4 and IPv6 addresses with [] by default? > Remote admin of server using deployer.jar fails to connect > -- > > Key: GERONIMO-2567 > URL: https://issues.apache.org/jira/browse/GERONIMO-2567 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 1.2, 2.0, 2.0.x > Environment: Linux > Java 1.5 >Reporter: Jay D. McHugh >Assignee: Kevan Miller > Fix For: 2.0.x, 2.1 > > > Trying to remote deploy a WAR file resulted in a failed connection. > This happened regardless of whether the port was specified. > $ java -jar deployer.jar --user system --password manager --host 172.16.1.41 > redeploy ~/PaLM.war > Error: Unable to connect to server at > deployer:geronimo:jmx://172.16.1.41 -- Connection refused to host: > 127.0.0.1; nested exception is: > java.net.ConnectException: Connection refused -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Downloading G v2.0.1 requires confluence account ?
Well peps are probably starting to sign up just to get to the download. Hopefully Herman sees this when he wakes up ;). regards Peter Petersson Jacek Laskowski wrote: On 8/22/07, Peter Petersson <[EMAIL PROTECTED]> wrote: Hi Poking around on the geronimo site I just noticed that downloading of release v2.0.1 requires a Confluence account. As I am able to get to the download links for all other versions i suspect this may be a mistake or could it be a new behavior you want? Good catch! I don't know why it's set like this, but the page is really in restricted mode atm. Probably we're awaiting press announcement before opening it up to the public. I don't really know. But then, the bits are in public already - http://www.apache.org/dist/geronimo/2.0.1/. Thanks for reporting. http://cwiki.apache.org/confluence/pages/pageinfo.action?pageId=63737 Page Permissions Page restrictions: Only users in group geronimo-committers can view this page. (set by Hernan Cunico at Aug 13, 2007 12:39) [Remove] Only users in group geronimo-committers can edit this page. (set by Hernan Cunico at Aug 13, 2007 12:39) [Remove] Hernan, why is that? Jacek
Re: Removing 1.0 and 1.1 from the download site...any objections?
I had never noticed http://www.apache.org/dist/geronimo/ and http://archive.apache.org/dist/geronimo/ ! The download links from "Available releases" section of http://geronimo.apache.org/downloads.html were directly taking me to some mirror site. It was only today that I noticed that http://geronimo.apache.org/downloads.html does have a link (with name main distribution directory) to that page but under "Verifying the integrity of the files" section. Does http://www.apache.org/dist/geronimo/ deserve a better mention, may be directly under "Available releases" section? Equal surprises by looking at http://www.apache.org/dist/geronimo/eclipse/ & http://archive.apache.org/dist/geronimo/eclipse/ for the first time! I will be happy to see some highlighted links from http://geronimo.apache.org/development-tools.html to those pages. Thanks, Shiva On 8/22/07, Hernan Cunico <[EMAIL PROTECTED]> wrote: > > right, actually the Archive section on the web site should be just a link > this server. I don't think we mention anywhere else about this server. > > As for removing those pages, for now I would suggest to change the parent > page to "no show" instead of removing them permanently. > > Cheers! > Hernan > > Matt Hogstrom wrote: > > The distributions are all automatically archived at > > http://archive.apache.org/dist/geronimo/ > > > > > > On Aug 21, 2007, at 1:58 PM, Hernan Cunico wrote: > > > >> how about an archive section instead of permanently removing? > >> We would have 2.0.1 and 1.1.1 as the latest stable and official > >> releases, we should add the release date too. Then an Archive section > >> for 1.0, 1.1 and 1.2. Thoughts? > >> Cheers! > >> Hernan > >> > >> Matt Hogstrom wrote: > >>> All, > >>> Since 1.1.1 is the stable version of Geronimo I'd like to propose > >>> that we remove the older versions from the download site. If there > >>> are no objections I'll do this tomorrow when we announce the 2.0.1 > >>> release. > >> > > > > >
Re: Using XDoclet to generate openejb-jar.xml
Hi Jon, Please see comments inline. On 8/21/07, Jonathan Gallimore <[EMAIL PROTECTED]> wrote: > > Hi Shiva, > > Thanks for pointing me in the direction of those discussions, I hadn't > seen them on previous searches. The work I've currently done is an XDoclet > plugin, and therefore is using XDoclet style annotations at the moment. > More is always better ;) . We probably can have both XDoclet & JSR175 annotations and allow users to choose whatever suits their needs best. I haven't personally done much with EJB3, and hence haven't really had much > need to use the new JSR-175 annotations, but I certainly think its right to > consider providing a solution using those as well. I'm quite happy to work > on something to use JSR-175 annotations too - > Thanks. That's very much needed. I'm not sure how much overlap it'll have with what I've already done, but I > think it might have some overlap with the work you've already done with the > plan generation wizard. > Please feel free to ask for help. Currently I only have one Geronimo specific annotation in my XDoclet plugin, > and I'll need a few more, but largely I've used the standard EJB > annotations. Presumably the same would apply using JSR-175 annotations, but > providing Geronimo specific annotations might mean that apps might break on > other app servers (or could developers get away with including a small jar > file with the Geronimo annotations in their ear files)? > I too have the same concerns. Don't know much about implementation of annotations. May be others (Tim et al) can comment on this. One other thing - I've logged this as a JIRA issue - is this necessary / > should it be assigned to me, or anything like that? > Would be good to have a JIRA to track progress. Please assign it to yourself until you feel you have some code that can go into svn at which time you ask a committer to assign to themselves and commit the code. Regards > > Jon > > Shiva Kumar H R wrote: > > Welcome Jon :-) > This is very much needed. > > Following discussions will tell you about some of the similar work > happening around: > * http://www.mail-archive.com/dev@geronimo.apache.org/msg39672.html > * http://www.mail-archive.com/dev@geronimo.apache.org/msg46831.html > * http://www.mail-archive.com/dev@geronimo.apache.org/msg49216.html > > One concern as mentioned in > http://www.mail-archive.com/dev@geronimo.apache.org/msg37264.html > is whether such annotations should be based on XDoclet or JSR-175? With > EJB 3.0 having JSR-175 annotations, it might be more intuitive for > developers to have OpenEJB/Geronimo specific annotations also to be based on > JSR-175. Request you to give a thought on these. > > Comments welcome. > > - Shiva > > On 8/15/07, Jonathan Gallimore <[EMAIL PROTECTED]> wrote: > > > > Jason, Bill, Mark, > > > > Many thanks for your responses. I'm currently doing a build of the > > latest code, and will have a look the deployment generator interface today. > > At first glance I don't really think its quite what I'm after, I'm really > > hoping for something that can generate these files for me during my build > > process without any intervention. If possible I'd also quite like to be able > > the same app on both JBoss and Geronimo and generate all the deployment > > descriptors for both at build time. > > > > It sounds from your reply, Mark, that what I've done on my XDoclet > > plugin might be quite helpful. I'm quite happy to develop it further if > > people find it useful. Presumably its ok if add this to JIRA and assign it > > to myself and continue working on it? > > > > Regards, > > > > Jon > > > > Mark Aufdencamp wrote: > > > > Jonathan, > > > > I have run into this issue as well. Please see my posts from the > > Spring. My research revealed that the OpenEJB XDoclet implementation > > was indeed for version 1.0 of OpenEJB. I did not find a release for > > > > version 2.0 of OpenEJB. > > > > Not having the openejb-jar.xml mappings generated from the source did > > make managing my Entity Beans a little harrier. I was able to generate > > the ejb-jar.xml from the XDoclet annotations, but had to hand develop > > > > the openejb-jar.xml from scratch. It worked, but I'd love to be able to > > plug-in an XDoclet module and have the base openejb-jar.xml generated. > > It whould serve as an initial source for a deployment tool utilized by a > > > > Server Administrator. That enables clear seperation of developer and > > administrator duties, while offering codebase stability and deployment > > flexibility. > > > > Mark Aufdencamp > > > > [EMAIL PROTECTED] > > > > Original Message > > Subject: Using XDoclet to generate openejb-jar.xml > > From: Jonathan Gallimore > > <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > > Date: Tue, August 14, 2007 7:28 am > > To: [EMAIL PROTECTED] > > > > Hi All, > > > > Apologies if this has been asked before, but I was wondering whether > > anyone uses XDoclet to generate their openejb-jar.xml d
Re: Problems performing remote EJB client call
david... thanks for the hint... i dug into the geronimo.bat files and including the endorsed directories much like it does. started up without a problem (although running into some others at the moment). anyway, just wanted to make a suggestion... might be a good idea to include a launcher script for the client as well and/or document the need to include the endorsed directories when launching an ejb client. On 8/21/07, David Jencks <[EMAIL PROTECTED]> wrote: > > just a guess... but are you sure the java.endorsed.dirs property is > set properly when you start the app client? this looks a bit like > the corba specs classes are coming from the jdk rather than yoko/ > geronimo. > > thanks > david jencks > On Aug 21, 2007, at 4:28 PM, Christopher Blythe wrote: > > > All... > > > > I'm working with DayTrader and one of the dev builds of GMO 2.0. > > I'm trying to convert the Streamer client over to access an EJB3 > > based remote session bean. From the server traces, it looks like > > the method is being executed (see below). > > > > 19:21:33,125 INFO [OpenEJB] invoking method create on dt-ejb.jar/ > > TradeSLSBBean > > 19:21:33,671 INFO [Transaction] TX Required: Started transaction > > [EMAIL PROTECTED] > > 19:21:33,687 INFO [Transaction] TX Required: Committing > > transaction > > [EMAIL PROTECTED] > > 19:21:33,687 INFO [remote] EJB RESPONSE: > > EJB_OK:[EMAIL PROTECTED] > > > > However, on the client, I get the following. Anyone have any > > guesses? Am I missing something in the module dependencies? > > > > 19:21:34,484 ERROR [GBeanInstance] Problem in doStop of > > org.apache.geronimo.conf > > igs/client-corba-yoko/2.0-SNAPSHOT/car?ServiceModule= > > org.apache.geronimo.configs > > /client-corba-yoko/2.0-SNAPSHOT/car,j2eeType=CORBABean,name=Server > > java.lang.NoSuchMethodError: > > org.omg.PortableInterceptor.IORInterceptor_3_0.adapter_manager_state_c > > hanged(Ljava/lang/String;S)V > > at > > org.apache.yoko.orb.OB.PIManager.adapterManagerStateChange > > (PIManager.java:532) > > at > > org.apache.yoko.orb.OBPortableServer.POAManager_impl.deactivate > > (POAManager_impl.java:360) > > at > > org.apache.yoko.orb.OBPortableServer.POAManagerFactory_impl._OB_deacti > > vate (POAManagerFactory_impl.java:342) > > at org.apache.yoko.orb.OB.ORBControl.completeServerShutdown > > (ORBControl.java:100) > > at org.apache.yoko.orb.OB.ORBControl.shutdownServer > > (ORBControl.java:427) > > at org.apache.yoko.orb.OB.ORBControl.shutdownServerClient > > (ORBControl.java:455) > > at org.apache.yoko.orb.OBCORBA.ORB_impl.destroy > > (ORB_impl.java:1390) > > at org.apache.geronimo.corba.CORBABean.doStop > > (CORBABean.java :260) > > at > > org.apache.geronimo.gbean.runtime.GBeanInstance.destroyInstance > > (GBeanInstance.java:1159) > > at > > org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStop > > (GBeanInstanceState.java:339) > > at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop > > (GBeanInstanceState.java:188) > > at org.apache.geronimo.gbean.runtime.GBeanInstance.stop > > (GBeanInstance.java:561) > > at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean > > (BasicKernel.java:423) > > at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop > > (GBeanInstanceState.java:180) > > at org.apache.geronimo.gbean.runtime.GBeanInstance.stop > > (GBeanInstance.java:561) > > at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean > > (BasicKernel.java:423) > > at org.apache.geronimo.gbean.runtime.GBeanInstanceState.stop > > (GBeanInstanceState.java:180) > > at org.apache.geronimo.gbean.runtime.GBeanInstance.stop > > (GBeanInstance.java:561) > > at org.apache.geronimo.kernel.basic.BasicKernel.stopGBean > > (BasicKernel.java:423) > > at > > org.apache.geronimo.kernel.config.KernelConfigurationManager > > $ShutdownHook.run(KernelConfigurationManager.java :316) > > at > > org.apache.geronimo.kernel.basic.BasicKernel.notifyShutdownHooks > > (BasicKernel.java:668) > > at org.apache.geronimo.kernel.basic.BasicKernel.shutdown > > (BasicKernel.java:645) > > at > > org.apache.geronimo.kernel.util.MainConfigurationBootstrapper$1.run > > (MainConfigurationBootstrapper.java:76) > > Exception in thread "Yoko:Server:StarterThread" > > java.lang.NoClassDefFoundError: org/apache/yoko/orb/OB/MessageQueue > > at org.apache.yoko.orb.OB.GIOPConnection. > > ( GIOPConnection.java:129) > > at org.apache.yoko.orb.OB.GIOPConnectionThreaded. > > (GIOPConnectionThreaded.java:312) > > at > > org.apache.yoko.orb.OB.GIOPServerStarterThreaded.starterRun > > (GIOPServerStarterThreaded.java :243) > > at org.apache.yoko.orb.OB.GIOPServerStarterThreaded > > $StarterThread.run(GIOPServerStarterThreaded.java:34) > > > > Thanks... > > > > Chris > > > > -- > > "I say never be complete, I say stop being perfect,
Re: Press Release for Geronimo 2.0.1
I should be sending a revised copy later today. I still need to know the contact person for this PR; this is the name, title and phone number of who should be contacted should anyone reading the PR have any questions. Since we submit the PR in MS Word format, that is how I will be sending it to the G team for review. I will send it, however, to the G pmc.
Geronimo box on Download page still says 1.1
Does anyone know how to get an updated box for Geronimo that says 2.0.1? Since its the first thing people see on that page seems like it would make more sense for the release number to be the most recent. I'm happy to do it but not sure what software was used.
Re: Press Release for Geronimo 2.0.1
I'll volunteer as the contact person. Matt Hogstrom Vice President, Apache Geronimo [EMAIL PROTECTED] (or [EMAIL PROTECTED] if more appropriate) 919-656-0564 On Aug 22, 2007, at 8:32 AM, Jim Jagielski wrote: o
Re: Removing 1.0 and 1.1 from the download site...any objections?
On Aug 22, 2007, at 7:19 AM, Shiva Kumar H R wrote: Does http://www.apache.org/dist/geronimo/ deserve a better mention, may be directly under "Available releases" section? no, this is a last resort for downloads. We rely on the mirror system to spread the load. If we specifically pointed to that URL we'd likely stress the Apache infrastructure.
Re: Downloading G v2.0.1 requires confluence account ?
Yikes, that is not good. Hernan? On Aug 22, 2007, at 5:29 AM, Peter Petersson wrote: Hi Poking around on the geronimo site I just noticed that downloading of release v2.0.1 requires a Confluence account. As I am able to get to the download links for all other versions i suspect this may be a mistake or could it be a new behavior you want? regards Peter Petersson
Re: Downloading G v2.0.1 requires confluence account ?
I think its fixed .. if someone else can verify that would be great. On Aug 22, 2007, at 10:10 AM, Matt Hogstrom wrote: Yikes, that is not good. Hernan? On Aug 22, 2007, at 5:29 AM, Peter Petersson wrote: Hi Poking around on the geronimo site I just noticed that downloading of release v2.0.1 requires a Confluence account. As I am able to get to the download links for all other versions i suspect this may be a mistake or could it be a new behavior you want? regards Peter Petersson
DayTrader streamer and web services clients terminate unexpectedly
All...
I'm still working with the DayTrader streamer client and have run into
another issue I cannot explain. Both the streamer and ws app client create
Swing-based GUIs. I am in no way a Swing expert; however, all of the docs
that I have read indicate that the GUI thread should remain up and running
(along with the JVM) after main completes. Here is an example...
public class JFrameExample {
public static void main(String[] args) {
JFrame f = new JFrame("This is a test");
...
f.addWindowListener(new ExitListener());
f.setVisible(true);
}
}
>From what I have seen all Swing apps use some variation of this, as do the
DayTrader streamer and ws app clients.
Unfortunately, when I try to run these clients in under Geronimo 2.0.1, the
apps terminate when the main thread completes. I have added a Thread.sleep()
to the main just to verify that the GUI remains up while the main thread is
still active.
Does anyone have any thoughts as to why the JVM is terminating with main
while the GUI threads are still active and have not been closed? I've tried
a SUN and IBM JVM and both result in early termination. The only thing I can
think of is that something in the Geronimo client or the manner in which
Geronimo packages the client that is changing the behavior.
Thanks...
Chris
--
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden
Re: Downloading G v2.0.1 requires confluence account ?
looks like it's fixed to me too. Joe Matt Hogstrom wrote: I think its fixed .. if someone else can verify that would be great. On Aug 22, 2007, at 10:10 AM, Matt Hogstrom wrote: Yikes, that is not good. Hernan? On Aug 22, 2007, at 5:29 AM, Peter Petersson wrote: Hi Poking around on the geronimo site I just noticed that downloading of release v2.0.1 requires a Confluence account. As I am able to get to the download links for all other versions i suspect this may be a mistake or could it be a new behavior you want? regards Peter Petersson
Re: Downloading G v2.0.1 requires confluence account ?
I never saw the problem myself - but it seems to be working from here too. Jay Matt Hogstrom wrote: I think its fixed .. if someone else can verify that would be great. On Aug 22, 2007, at 10:10 AM, Matt Hogstrom wrote: Yikes, that is not good. Hernan? On Aug 22, 2007, at 5:29 AM, Peter Petersson wrote: Hi Poking around on the geronimo site I just noticed that downloading of release v2.0.1 requires a Confluence account. As I am able to get to the download links for all other versions i suspect this may be a mistake or could it be a new behavior you want? regards Peter Petersson .
Re: Downloading G v2.0.1 requires confluence account ?
On 8/22/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > I think its fixed .. if someone else can verify that would be great. Just log out and see if you can access the web page ;-) It works for me. What did you do to fix it? I see that the edit priv is given to geronimo-committers group. Was it the only change you made? (I'm asking and scratching my head wondering why I did not do that before ;-)). Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Downloading G v2.0.1 requires confluence account ?
Works fine Matt Hogstrom wrote: I think its fixed .. if someone else can verify that would be great. On Aug 22, 2007, at 10:10 AM, Matt Hogstrom wrote: Yikes, that is not good. Hernan? On Aug 22, 2007, at 5:29 AM, Peter Petersson wrote: Hi Poking around on the geronimo site I just noticed that downloading of release v2.0.1 requires a Confluence account. As I am able to get to the download links for all other versions i suspect this may be a mistake or could it be a new behavior you want? regards Peter Petersson
Re: svn commit: r568632 - /geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
Hey Donald (and others) ... Is anybody actually using this framework
"ie. containerless" assembly? I was just thinking of removing this
assembly prior to seeing this change.
At one point in time this was going to be our most minimal assembly
(without even a web container) for building up a pluggable server.
However, it seems like the tide is changing to always expect a web
container in the smallest framework assembly (ie. the minimal assemblies
we already have). There's been a lot of cool work on the pluggable
console and it seems like are heading in a direction to make this the
primary interface for building and managing the server ... but of course
it requires a web container as a minimal starting point.
So, the question is: Should we remove the framework assembly and work
on the assumption that our most minimal assemblies should always include
a web container?
Joe
[EMAIL PROTECTED] wrote:
Author: dwoods
Date: Wed Aug 22 07:47:42 2007
New Revision: 568632
URL: http://svn.apache.org/viewvc?rev=568632&view=rev
Log:
adding missing depend on geronimo-boilerplate-minimal
Modified:
geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
Modified: geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/geronimo-framework/pom.xml?rev=568632&r1=568631&r2=568632&view=diff
==
--- geronimo/server/trunk/assemblies/geronimo-framework/pom.xml (original)
+++ geronimo/server/trunk/assemblies/geronimo-framework/pom.xml Wed Aug 22
07:47:42 2007
@@ -40,6 +40,12 @@
+org.apache.geronimo.assemblies
+geronimo-boilerplate-minimal
+${version}
+
+
+
org.apache.geronimo.configs
j2ee-system
${version}
[jira] Resolved: (SM-1038) http provider endpoint sends wrong Host header
[ https://issues.apache.org/activemq/browse/SM-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Termin resolved SM-1038. --- Resolution: Fixed Fix Version/s: 3.2 Fixed Many thanks to Torsten Mielke for the patch!!! Author: tterm Date: Wed Aug 22 08:09:59 2007 New Revision: 568645 URL: http://svn.apache.org/viewvc?rev=568645&view=rev Log: SM-1038 http provider endpoint sends wrong Host header Modified: incubator/servicemix/trunk/deployables/bindingcomponents/servicemix-http/src/main/java/org/apache/servicemix/http/endpoints/DefaultHttpProviderMarshaler.java > http provider endpoint sends wrong Host header > -- > > Key: SM-1038 > URL: https://issues.apache.org/activemq/browse/SM-1038 > Project: ServiceMix > Issue Type: Bug > Components: servicemix-http >Affects Versions: 3.1.1 > Environment: JDK 5.0 >Reporter: Torsten Mielke > Fix For: 3.2 > > Attachments: http-marshaler.patch > > > The current ServiceMix http:provider endpoint uses jetty-client-6.1.5 > library, which contains a bug fixed in their trunk. More infomation on > http://fisheye.codehaus.org/browse/jetty-contrib/jetty/trunk/contrib/client/src/main/java/org/mortbay/jetty/client/HttpConnection.java?r1=374&r2=378. > This causes wrong Host header in HTTP request. > Actual Host header looks like this: > Host: [EMAIL PROTECTED]//host.com:8080(1,0,0) > Of course such header causes HTTP 400 response and endpoint cannot be used at > all. > To work around this bug > deployables/bindingcomponents/servicemix-http/src/main/java/org/apache/servicemix/http/endpoints/DefaultHttpProviderMarshaler.java > needs to get the attached patch applied. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SM-1038) http provider endpoint sends wrong Host header
[ https://issues.apache.org/activemq/browse/SM-1038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_39996 ] Thomas Termin commented on SM-1038: --- Patch should be undone if a new jetty release is available > http provider endpoint sends wrong Host header > -- > > Key: SM-1038 > URL: https://issues.apache.org/activemq/browse/SM-1038 > Project: ServiceMix > Issue Type: Bug > Components: servicemix-http >Affects Versions: 3.1.1 > Environment: JDK 5.0 >Reporter: Torsten Mielke > Fix For: 3.2 > > Attachments: http-marshaler.patch > > > The current ServiceMix http:provider endpoint uses jetty-client-6.1.5 > library, which contains a bug fixed in their trunk. More infomation on > http://fisheye.codehaus.org/browse/jetty-contrib/jetty/trunk/contrib/client/src/main/java/org/mortbay/jetty/client/HttpConnection.java?r1=374&r2=378. > This causes wrong Host header in HTTP request. > Actual Host header looks like this: > Host: [EMAIL PROTECTED]//host.com:8080(1,0,0) > Of course such header causes HTTP 400 response and endpoint cannot be used at > all. > To work around this bug > deployables/bindingcomponents/servicemix-http/src/main/java/org/apache/servicemix/http/endpoints/DefaultHttpProviderMarshaler.java > needs to get the attached patch applied. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r568632 - /geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
Before removing it I'm wondering, in what scenario(s) would we use
the framework assembly?One scenario that comes to mind is an
installer that lays down the framework and then installs plugins on
top of it for a truly customized server. The minimal assembly
already seems to fit that scenario pretty well though, assuming the
installer could just remove the web container in the uncommon(?)
cases where its not needed. So the minimal assembly could be the
base line for an installer plus double as a preconfigured assembly
that serves as the low-end for our users (i.e. no installer
required). Plus, since the minimal assembly has a web container we
could use a web UI for the installer instead of some native app like
we used to have -- actually the "installer" is more like a plugin
configurer from that point of view.
What other scenarios can we think of where a framework assembly could
be useful? And do the recent advancements in GShell (very cool
btw!!) play into this discussion?
Best wishes,
Paul
On Aug 22, 2007, at 11:12 AM, Joe Bohn wrote:
Hey Donald (and others) ... Is anybody actually using this
framework "ie. containerless" assembly? I was just thinking of
removing this assembly prior to seeing this change.
At one point in time this was going to be our most minimal assembly
(without even a web container) for building up a pluggable server.
However, it seems like the tide is changing to always expect a web
container in the smallest framework assembly (ie. the minimal
assemblies we already have). There's been a lot of cool work on
the pluggable console and it seems like are heading in a direction
to make this the primary interface for building and managing the
server ... but of course it requires a web container as a minimal
starting point.
So, the question is: Should we remove the framework assembly and
work on the assumption that our most minimal assemblies should
always include a web container?
Joe
[EMAIL PROTECTED] wrote:
Author: dwoods
Date: Wed Aug 22 07:47:42 2007
New Revision: 568632
URL: http://svn.apache.org/viewvc?rev=568632&view=rev
Log:
adding missing depend on geronimo-boilerplate-minimal
Modified:
geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
Modified: geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/
geronimo-framework/pom.xml?rev=568632&r1=568631&r2=568632&view=diff
=
=
--- geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
(original)
+++ geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
Wed Aug 22 07:47:42 2007
@@ -40,6 +40,12 @@
+org.apache.geronimo.assemblies
+geronimo-boilerplate-minimal
+${version}
+
+
+
org.apache.geronimo.configs
j2ee-system
${version}
Re: Downloading G v2.0.1 requires confluence account ?
When you edit the page there is a set of restrictions at the bottom. I simply set read to none. On Aug 22, 2007, at 10:35 AM, Jacek Laskowski wrote: On 8/22/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I think its fixed .. if someone else can verify that would be great. Just log out and see if you can access the web page ;-) It works for me. What did you do to fix it? I see that the edit priv is given to geronimo-committers group. Was it the only change you made? (I'm asking and scratching my head wondering why I did not do that before ;-)). Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
Re: Downloading G v2.0.1 requires confluence account ?
yeah, I already got another nudge on this one. Not sure what happened but I had to recreate the page today.
The link to the 2.0.1 is automatically generated by Confluence using macro
{children}, but the link to this page in particular instead of pointing to the
HTML version just like with any other releases it was pointing to the
Confluence page ID.
I've been testing the page now making sure I don't have any cookies still alive
and I've been able to see the page.
I tested the page on the dev site
http://cwiki.apache.org/GMOxSITE/apache-geronimo-v201-release.html , it will
take some time till it get replicated to the live site. Pls let me know if you
guys still see this problem.
Sorry for the trouble.
Cheers!
Hernan
Peter Petersson wrote:
Hi
Poking around on the geronimo site I just noticed that downloading of
release v2.0.1 requires a Confluence account.
As I am able to get to the download links for all other versions i
suspect this may be a mistake or could it be a new behavior you want?
regards
Peter Petersson
Re: svn commit: r568632 - /geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
On Aug 22, 2007, at 11:12 AM, Joe Bohn wrote: Hey Donald (and others) ... Is anybody actually using this framework "ie. containerless" assembly? I was just thinking of removing this assembly prior to seeing this change. Can't say that I'm using it, but I wouldn't be in a rush to delete it, either. At one point in time this was going to be our most minimal assembly (without even a web container) for building up a pluggable server. However, it seems like the tide is changing to always expect a web container in the smallest framework assembly (ie. the minimal assemblies we already have). There's been a lot of cool work on the pluggable console and it seems like are heading in a direction to make this the primary interface for building and managing the server ... but of course it requires a web container as a minimal starting point. So, the question is: Should we remove the framework assembly and work on the assumption that our most minimal assemblies should always include a web container? IMO, no. The console is being extended with the same type of flexibility that the server runtime currently enjoys. This doesn't mean that console capability is a prerequisite for your server runtime... I'd like to maintain the ability to run a server without a web container... --kevan
Re: svn commit: r568632 - /geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
I would like to see all the assemblies except the framework assembly
be constructed by adding plugins to the framework assembly. Just
because there has been no progress on this goal in the last year...
I think we are pretty close to having enough pieces lined up so we
can actually do this, so I'm very definitely against removing this
assembly. We could remove all the others to spur on this process :-)
thanks
david jencks
On Aug 22, 2007, at 8:34 AM, Paul McMahan wrote:
Before removing it I'm wondering, in what scenario(s) would we use
the framework assembly?One scenario that comes to mind is an
installer that lays down the framework and then installs plugins on
top of it for a truly customized server. The minimal assembly
already seems to fit that scenario pretty well though, assuming the
installer could just remove the web container in the uncommon(?)
cases where its not needed. So the minimal assembly could be the
base line for an installer plus double as a preconfigured assembly
that serves as the low-end for our users (i.e. no installer
required). Plus, since the minimal assembly has a web container we
could use a web UI for the installer instead of some native app
like we used to have -- actually the "installer" is more like a
plugin configurer from that point of view.
What other scenarios can we think of where a framework assembly
could be useful? And do the recent advancements in GShell (very
cool btw!!) play into this discussion?
Best wishes,
Paul
On Aug 22, 2007, at 11:12 AM, Joe Bohn wrote:
Hey Donald (and others) ... Is anybody actually using this
framework "ie. containerless" assembly? I was just thinking of
removing this assembly prior to seeing this change.
At one point in time this was going to be our most minimal
assembly (without even a web container) for building up a
pluggable server. However, it seems like the tide is changing to
always expect a web container in the smallest framework assembly
(ie. the minimal assemblies we already have). There's been a lot
of cool work on the pluggable console and it seems like are
heading in a direction to make this the primary interface for
building and managing the server ... but of course it requires a
web container as a minimal starting point.
So, the question is: Should we remove the framework assembly and
work on the assumption that our most minimal assemblies should
always include a web container?
Joe
[EMAIL PROTECTED] wrote:
Author: dwoods
Date: Wed Aug 22 07:47:42 2007
New Revision: 568632
URL: http://svn.apache.org/viewvc?rev=568632&view=rev
Log:
adding missing depend on geronimo-boilerplate-minimal
Modified:
geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
Modified: geronimo/server/trunk/assemblies/geronimo-framework/
pom.xml
URL: http://svn.apache.org/viewvc/geronimo/server/trunk/
assemblies/geronimo-framework/pom.xml?
rev=568632&r1=568631&r2=568632&view=diff
==
--- geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
(original)
+++ geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
Wed Aug 22 07:47:42 2007
@@ -40,6 +40,12 @@
+org.apache.geronimo.assemblies
+geronimo-boilerplate-minimal
+${version}
+
+
+
org.apache.geronimo.configs
j2ee-system
${version}
Re: Downloading G v2.0.1 requires confluence account ?
...and the clever autoexport plugin still did not realized of that change, it still required a manual export to take this changes Cheers! Hernan Matt Hogstrom wrote: When you edit the page there is a set of restrictions at the bottom. I simply set read to none. On Aug 22, 2007, at 10:35 AM, Jacek Laskowski wrote: On 8/22/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote: I think its fixed .. if someone else can verify that would be great. Just log out and see if you can access the web page ;-) It works for me. What did you do to fix it? I see that the edit priv is given to geronimo-committers group. Was it the only change you made? (I'm asking and scratching my head wondering why I did not do that before ;-)). Jacek -- Jacek Laskowski http://www.JacekLaskowski.pl
[jira] Resolved: (GERONIMO-3435) Axis2: unable to create a service-ref without wsdl using a generic Service class
[ https://issues.apache.org/jira/browse/GERONIMO-3435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jarek Gawor resolved GERONIMO-3435. --- Resolution: Fixed Fix Version/s: 2.1 2.0.x Fix committed to trunk (revision 568674) and branches/2.0 (revision 568683). > Axis2: unable to create a service-ref without wsdl using a generic Service > class > > > Key: GERONIMO-3435 > URL: https://issues.apache.org/jira/browse/GERONIMO-3435 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: webservices >Affects Versions: 2.0 >Reporter: Jarek Gawor >Assignee: Jarek Gawor > Fix For: 2.0.x, 2.1 > > > When Axis2 JAX-WS engine is used a service-ref without wsdl using a generic > Service class cannot be created. An error is raised because service qname is > expected. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r568632 - /geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
+1 Thanks Anita --- David Jencks <[EMAIL PROTECTED]> wrote: > I would like to see all the assemblies except the framework assembly > > be constructed by adding plugins to the framework assembly. Just > because there has been no progress on this goal in the last year... > > I think we are pretty close to having enough pieces lined up so we > can actually do this, so I'm very definitely against removing this > assembly. Luggage? GPS? Comic books? Check out fitting gifts for grads at Yahoo! Search http://search.yahoo.com/search?fr=oni_on_mail&p=graduation+gifts&cs=bz
Re: Geronimo box on Download page still says 1.1
I've been trying for ages to get these updated. I asked folks from other projects using similar boxes but couldn't figure out what software they were using. All I have is the Photoshop suit but I'm sure those were created with something else. Cheers! Hernan Matt Hogstrom wrote: Does anyone know how to get an updated box for Geronimo that says 2.0.1? Since its the first thing people see on that page seems like it would make more sense for the release number to be the most recent. I'm happy to do it but not sure what software was used.
Re: Geronimo box on Download page still says 1.1
IIRC Hiram Chirino made the boxes for us in rev 522634. I thought there was some discussion of how but can't find it at the moment. thanks david jencks On Aug 22, 2007, at 9:32 AM, Hernan Cunico wrote: I've been trying for ages to get these updated. I asked folks from other projects using similar boxes but couldn't figure out what software they were using. All I have is the Photoshop suit but I'm sure those were created with something else. Cheers! Hernan Matt Hogstrom wrote: Does anyone know how to get an updated box for Geronimo that says 2.0.1? Since its the first thing people see on that page seems like it would make more sense for the release number to be the most recent. I'm happy to do it but not sure what software was used.
Re: DayTrader streamer and web services clients terminate unexpectedly
On Aug 22, 2007, at 7:27 AM, Christopher Blythe wrote:
All...
I'm still working with the DayTrader streamer client and have run
into another issue I cannot explain. Both the streamer and ws app
client create Swing-based GUIs. I am in no way a Swing expert;
however, all of the docs that I have read indicate that the GUI
thread should remain up and running (along with the JVM) after main
completes. Here is an example...
public class JFrameExample {
public static void main(String[] args) {
JFrame f = new JFrame("This is a test");
...
f.addWindowListener(new ExitListener());
f.setVisible(true);
}
}
From what I have seen all Swing apps use some variation of this, as
do the DayTrader streamer and ws app clients.
Unfortunately, when I try to run these clients in under Geronimo
2.0.1, the apps terminate when the main thread completes. I have
added a Thread.sleep() to the main just to verify that the GUI
remains up while the main thread is still active.
Does anyone have any thoughts as to why the JVM is terminating with
main while the GUI threads are still active and have not been
closed? I've tried a SUN and IBM JVM and both result in early
termination. The only thing I can think of is that something in the
Geronimo client or the manner in which Geronimo packages the client
that is changing the behavior.
I remember fixing this once
My guess is that it got broken again when gianny added the bootstrap
repository. A JIRA would be good I think. I suspect if you look
around at the various command line classes you can see the code that
shuts down the client from a shutdown hook and see why it isn't
getting used.
I'll try to find some time to take a look at this if you don't beat
me to it.
thanks
david jencks
Thanks...
Chris
--
"I say never be complete, I say stop being perfect, I say let...
lets evolve, let the chips fall where they may." - Tyler Durden
[jira] Created: (GERONIMO-3436) DayTrader streamer and web services (Swing) clients terminate unexpectedly
DayTrader streamer and web services (Swing) clients terminate unexpectedly
--
Key: GERONIMO-3436
URL: https://issues.apache.org/jira/browse/GERONIMO-3436
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: application client
Affects Versions: 2.0.x
Reporter: Christopher James Blythe
Description from devlist...
All...
I'm still working with the DayTrader streamer client and have run into another
issue I cannot explain. Both the streamer and ws app client create Swing-based
GUIs. I am in no way a Swing expert; however, all of the docs that I have read
indicate that the GUI thread should remain up and running (along with the JVM)
after main completes. Here is an example...
public class JFrameExample {
public static void main(String[] args) {
JFrame f = new JFrame("This is a test");
...
f.addWindowListener(new ExitListener());
f.setVisible(true);
}
}
>From what I have seen all Swing apps use some variation of this, as do the
>DayTrader streamer and ws app clients.
Unfortunately, when I try to run these clients in under Geronimo 2.0.1, the
apps terminate when the main thread completes. I have added a Thread.sleep() to
the main just to verify that the GUI remains up while the main thread is still
active.
Does anyone have any thoughts as to why the JVM is terminating with main while
the GUI threads are still active and have not been closed? I've tried a SUN and
IBM JVM and both result in early termination. The only thing I can think of is
that something in the Geronimo client or the manner in which Geronimo packages
the client that is changing the behavior.
Response from David Jencks...
I remember fixing this once
My guess is that it got broken again when gianny added the bootstrap
repository. A JIRA would be good I think. I suspect if you look
around at the various command line classes you can see the code that
shuts down the client from a shutdown hook and see why it isn't
getting used.
I'll try to find some time to take a look at this if you don't beat
me to it.
thanks
david jencks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r568632 - /geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
On Aug 22, 2007, at 11:52 AM, David Jencks wrote: I would like to see all the assemblies except the framework assembly be constructed by adding plugins to the framework assembly. Just because there has been no progress on this goal in the last year... I definitely agree with your vision here. My main reservation with taking on that line of thought was, like you said, the lack of progress on the framework += customizations approach since the j2ee-installer (sorry, bad joke). To be fair though I should acknowledge that we have been just a little distracted on that JEE5 thing. :-) There are some issues like how OSGI, xbean, and spring can/should/ will affect our framework and plugin strategy, and that hurts me poor brain. Good thing we have lots of clever people contributing to this project. Now is a good time to start those discussions and set our sites on a new goal. This is one I think we can all rally around and contribute to in various ways. I think we are pretty close to having enough pieces lined up so we can actually do this, so I'm very definitely against removing this assembly. We could remove all the others to spur on this process :-) That just might do the trick! Best wishes, Paul
Re: DayTrader streamer and web services clients terminate unexpectedly
GERONIMO-3436 opened...
In the mean time... I could easily gate the exit of Main using a while loop
conditional based on JFrame.isVisible(). I'm tempted to add this to the
client code in order to get it working. However, we wouldn't be able to
catch this issue in the future, if I do...
Any strong opinions here?
On 8/22/07, David Jencks <[EMAIL PROTECTED]> wrote:
>
>
> On Aug 22, 2007, at 7:27 AM, Christopher Blythe wrote:
>
> > All...
> >
> > I'm still working with the DayTrader streamer client and have run
> > into another issue I cannot explain. Both the streamer and ws app
> > client create Swing-based GUIs. I am in no way a Swing expert;
> > however, all of the docs that I have read indicate that the GUI
> > thread should remain up and running (along with the JVM) after main
> > completes. Here is an example...
> >
> > public class JFrameExample {
> > public static void main(String[] args) {
> > JFrame f = new JFrame("This is a test");
> > ...
> > f.addWindowListener(new ExitListener());
> > f.setVisible(true);
> > }
> > }
> >
> > From what I have seen all Swing apps use some variation of this, as
> > do the DayTrader streamer and ws app clients.
> >
> > Unfortunately, when I try to run these clients in under Geronimo
> > 2.0.1, the apps terminate when the main thread completes. I have
> > added a Thread.sleep() to the main just to verify that the GUI
> > remains up while the main thread is still active.
> >
> > Does anyone have any thoughts as to why the JVM is terminating with
> > main while the GUI threads are still active and have not been
> > closed? I've tried a SUN and IBM JVM and both result in early
> > termination. The only thing I can think of is that something in the
> > Geronimo client or the manner in which Geronimo packages the client
> > that is changing the behavior.
>
> I remember fixing this once
>
> My guess is that it got broken again when gianny added the bootstrap
> repository. A JIRA would be good I think. I suspect if you look
> around at the various command line classes you can see the code that
> shuts down the client from a shutdown hook and see why it isn't
> getting used.
>
> I'll try to find some time to take a look at this if you don't beat
> me to it.
>
> thanks
> david jencks
>
>
> >
> > Thanks...
> >
> > Chris
> >
> >
> > --
> > "I say never be complete, I say stop being perfect, I say let...
> > lets evolve, let the chips fall where they may." - Tyler Durden
>
>
--
"I say never be complete, I say stop being perfect, I say let... lets
evolve, let the chips fall where they may." - Tyler Durden
Re: Geronimo box on Download page still says 1.1
we don't have an out-of-the-box Geronimo box for the download page? On 8/22/07, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > > Does anyone know how to get an updated box for Geronimo that says > 2.0.1? Since its the first thing people see on that page seems like > it would make more sense for the release number to be the most > recent. I'm happy to do it but not sure what software was used. >
[jira] Closed: (GERONIMODEVTOOLS-180) Upgrade supported eclipse level from 3.3RC2 to 3.3, and related packages.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tim McConnell closed GERONIMODEVTOOLS-180. -- Resolution: Fixed Fix Version/s: 2.0 This has been fixed with the r568711 changes. It still uses a personal apache maven repo but this will ultimately be fixed with a subsequent change. Also, I have not yet investigated the implications of using the Eclipse IDE for Java EE Developers artifact rather than the current eclipse SDK. I would prefer though to have another JIRA opened for that improvement. > Upgrade supported eclipse level from 3.3RC2 to 3.3, and related packages. > - > > Key: GERONIMODEVTOOLS-180 > URL: > https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-180 > Project: Geronimo-Devtools > Issue Type: Improvement > Components: eclipse-plugin >Affects Versions: 2.0 >Reporter: Ted Kirby >Assignee: Tim McConnell > Fix For: 2.0 > > > The eclipse plugin now prereqs these eclipse levels: > eclipse-sdk3.3RC2 > Web Tools Platform (WTP) 2.0RC2 > Eclipse Modeling Framework (EMF) 2.3.0RC2 > Graphical Editing Framework (GEF) 3.3RC2 > Data Tools Platform (DTP) 1.5RC2 > Europa (eclipse 3.3) went GA on June 27, so I think we need to upgrade the > plugin to support the released levels, not the RC2 levels. > Eurpoa now offers 5 eclipse bundles. 3.2 had one. 3.3 offers one comparable > to the 3.2, called eclipse classic, at 140 MB, which the build is currently > using. I think we should consider using Eclipse IDE for Java EE Developers, > at 125 MB. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r568632 - /geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
I'm not using it. Was just fixing a Maven depends problem...
-Donald
Joe Bohn wrote:
Hey Donald (and others) ... Is anybody actually using this framework
"ie. containerless" assembly? I was just thinking of removing this
assembly prior to seeing this change.
At one point in time this was going to be our most minimal assembly
(without even a web container) for building up a pluggable server.
However, it seems like the tide is changing to always expect a web
container in the smallest framework assembly (ie. the minimal assemblies
we already have). There's been a lot of cool work on the pluggable
console and it seems like are heading in a direction to make this the
primary interface for building and managing the server ... but of course
it requires a web container as a minimal starting point.
So, the question is: Should we remove the framework assembly and work
on the assumption that our most minimal assemblies should always include
a web container?
Joe
[EMAIL PROTECTED] wrote:
Author: dwoods
Date: Wed Aug 22 07:47:42 2007
New Revision: 568632
URL: http://svn.apache.org/viewvc?rev=568632&view=rev
Log:
adding missing depend on geronimo-boilerplate-minimal
Modified:
geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
Modified: geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/assemblies/geronimo-framework/pom.xml?rev=568632&r1=568631&r2=568632&view=diff
==
--- geronimo/server/trunk/assemblies/geronimo-framework/pom.xml
(original)
+++ geronimo/server/trunk/assemblies/geronimo-framework/pom.xml Wed
Aug 22 07:47:42 2007
@@ -40,6 +40,12 @@
+org.apache.geronimo.assemblies
+geronimo-boilerplate-minimal
+${version}
+
+
+
org.apache.geronimo.configs
j2ee-system
${version}
smime.p7s
Description: S/MIME Cryptographic Signature
[jira] Created: (GERONIMO-3437) Axis2: serviceimplClass being null caused NPE at invoke in JavaBeanDispatcher
Axis2: serviceimplClass being null caused NPE at invoke in JavaBeanDispatcher --- Key: GERONIMO-3437 URL: https://issues.apache.org/jira/browse/GERONIMO-3437 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: webservices Affects Versions: 2.1 Reporter: Lin Sun Assignee: Lin Sun Fix For: 2.1 I am seeing a NPE from Axis2, and it turned out that we passed serviceimplClass null to Axis2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Is there a procedure to be followed to put new code in geronimo\plugins
Followup question: Once a plugin has been moved from /sandbox to /plugins, is it OK to go ahead and deploy snapshots of the plugin to the ASF snapshot repo? The specific reason I'm asking is because the extensible console work that has been going on in GERONIMO-3345 and GERONIMO-3413 is at the point where it would be great to get some feedback and collaboration without having to build the plugins from source.According to http://www.apache.org/dev/repository-faq.html the PMC needs to be "happy" with the binaries before they are "released" to the snapshot repo -- although "release" doesn't seem like the right term for them to use for stuff in the snapshot repo. So, is a heads-up on the dev list adequate for this type of activity, or is something more formal required? Best wishes, Paul On Aug 21, 2007, at 2:24 PM, Vamsavardhana Reddy wrote: I was wondering if there is a procedure to be followed to put new code in geronimo\plugins? I intend to move the geronimo-tuscany integration thing Manu and myself are working on out of sandbox and put under geronimo\plugins. Also, is there a release cycle for geronimo plugins? Thanks and regards, Vamsi
Servicemix ILog JRules
I am Using ILog Jrules( Rules Engine) and Servicemix ESB. I want to integrate ILOG JRules with servicemix. I am planning to create Component in Servicemix similar to Servicemix-Drools that can integrate with Jrules. Can anyone please suggest how to approach this problem?. Your help is appreciated.
Re: Is there a procedure to be followed to put new code in geronimo\plugins
I'm not sure if/when we've faced this in the past but I'd be comfortable with: - moving code to plugins - announcing it on the dev list - in 3-7 days pushing a snapshot if there are no major objections thanks david jencks On Aug 22, 2007, at 12:38 PM, Paul McMahan wrote: Followup question: Once a plugin has been moved from /sandbox to /plugins, is it OK to go ahead and deploy snapshots of the plugin to the ASF snapshot repo? The specific reason I'm asking is because the extensible console work that has been going on in GERONIMO-3345 and GERONIMO-3413 is at the point where it would be great to get some feedback and collaboration without having to build the plugins from source.According to http://www.apache.org/dev/repository- faq.html the PMC needs to be "happy" with the binaries before they are "released" to the snapshot repo -- although "release" doesn't seem like the right term for them to use for stuff in the snapshot repo. So, is a heads-up on the dev list adequate for this type of activity, or is something more formal required? Best wishes, Paul On Aug 21, 2007, at 2:24 PM, Vamsavardhana Reddy wrote: I was wondering if there is a procedure to be followed to put new code in geronimo\plugins? I intend to move the geronimo-tuscany integration thing Manu and myself are working on out of sandbox and put under geronimo\plugins. Also, is there a release cycle for geronimo plugins? Thanks and regards, Vamsi
Re: Is there a procedure to be followed to put new code in geronimo\plugins
+1 On Aug 22, 2007, at 3:45 PM, David Jencks wrote: I'm not sure if/when we've faced this in the past but I'd be comfortable with: - moving code to plugins - announcing it on the dev list - in 3-7 days pushing a snapshot if there are no major objections thanks david jencks On Aug 22, 2007, at 12:38 PM, Paul McMahan wrote: Followup question: Once a plugin has been moved from /sandbox to /plugins, is it OK to go ahead and deploy snapshots of the plugin to the ASF snapshot repo? The specific reason I'm asking is because the extensible console work that has been going on in GERONIMO-3345 and GERONIMO-3413 is at the point where it would be great to get some feedback and collaboration without having to build the plugins from source.According to http://www.apache.org/dev/repository- faq.html the PMC needs to be "happy" with the binaries before they are "released" to the snapshot repo -- although "release" doesn't seem like the right term for them to use for stuff in the snapshot repo. So, is a heads-up on the dev list adequate for this type of activity, or is something more formal required? Best wishes, Paul On Aug 21, 2007, at 2:24 PM, Vamsavardhana Reddy wrote: I was wondering if there is a procedure to be followed to put new code in geronimo\plugins? I intend to move the geronimo-tuscany integration thing Manu and myself are working on out of sandbox and put under geronimo\plugins. Also, is there a release cycle for geronimo plugins? Thanks and regards, Vamsi
Re: DayTrader streamer and web services clients terminate unexpectedly
On Aug 22, 2007, at 10:31 AM, Christopher Blythe wrote:
GERONIMO-3436 opened...
In the mean time... I could easily gate the exit of Main using a
while loop conditional based on JFrame.isVisible(). I'm tempted to
add this to the client code in order to get it working. However, we
wouldn't be able to catch this issue in the future, if I do...
Any strong opinions here?
Could you check what happens if you remove the override of
initializeKernel from EmbeddedClientCommandLine? I have only a fuzzy
recollection of my even more fuzzy understanding of how this works
but think that installing the shutdown hook was what kept the client
running until it was actually stopped.
thanks
david jencks
On 8/22/07, David Jencks <[EMAIL PROTECTED]> wrote:
On Aug 22, 2007, at 7:27 AM, Christopher Blythe wrote:
> All...
>
> I'm still working with the DayTrader streamer client and have run
> into another issue I cannot explain. Both the streamer and ws app
> client create Swing-based GUIs. I am in no way a Swing expert;
> however, all of the docs that I have read indicate that the GUI
> thread should remain up and running (along with the JVM) after main
> completes. Here is an example...
>
> public class JFrameExample {
> public static void main(String[] args) {
> JFrame f = new JFrame("This is a test");
> ...
> f.addWindowListener(new ExitListener());
> f.setVisible(true);
> }
> }
>
> From what I have seen all Swing apps use some variation of this, as
> do the DayTrader streamer and ws app clients.
>
> Unfortunately, when I try to run these clients in under Geronimo
> 2.0.1, the apps terminate when the main thread completes. I have
> added a Thread.sleep() to the main just to verify that the GUI
> remains up while the main thread is still active.
>
> Does anyone have any thoughts as to why the JVM is terminating with
> main while the GUI threads are still active and have not been
> closed? I've tried a SUN and IBM JVM and both result in early
> termination. The only thing I can think of is that something in the
> Geronimo client or the manner in which Geronimo packages the client
> that is changing the behavior.
I remember fixing this once
My guess is that it got broken again when gianny added the bootstrap
repository. A JIRA would be good I think. I suspect if you look
around at the various command line classes you can see the code that
shuts down the client from a shutdown hook and see why it isn't
getting used.
I'll try to find some time to take a look at this if you don't beat
me to it.
thanks
david jencks
>
> Thanks...
>
> Chris
>
>
> --
> "I say never be complete, I say stop being perfect, I say let...
> lets evolve, let the chips fall where they may." - Tyler Durden
--
"I say never be complete, I say stop being perfect, I say let...
lets evolve, let the chips fall where they may." - Tyler Durden
[jira] Closed: (DAYTRADER-52) Replace low-level EJB3 primitives with primitives that can be compared to existing EJB 2.1 primitives
[ https://issues.apache.org/jira/browse/DAYTRADER-52?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher James Blythe closed DAYTRADER-52. - Resolution: Fixed Fix Version/s: 2.0 > Replace low-level EJB3 primitives with primitives that can be compared to > existing EJB 2.1 primitives > - > > Key: DAYTRADER-52 > URL: https://issues.apache.org/jira/browse/DAYTRADER-52 > Project: DayTrader > Issue Type: Improvement > Components: EJB Tier, Web Tier >Affects Versions: 2.0 >Reporter: Christopher James Blythe >Assignee: Christopher James Blythe > Fix For: 2.0 > > > The EJB 3 primitives that were initially added to DayTrader 2.0 are extremely > low-level and cannot be compared to the existing EJB 2.1 primitives. > Therefore, removing the current EJB3 primitives and replacing them with > primitives that are equivalent to the EJB 2.1 primitives. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Roadmap
On 8/22/07, Nodet Guillaume <[EMAIL PROTECTED]> wrote:
> I'd like to start a discussion on ServiceMix roadmap.
Yay!
> On the short term, hopefully the Apache Board will approve ServiceMix
> gradation as a TLP at the end of the month (the board meeting is on
> 28th of August). Once done, we should start moving the resources to
> their new locations (servicemix.apache.org). At the same time, we
> may want to release a 3.1.2 (removing the incubator disclaimers) and
> a 3.2. I think we can plan on 17/09 for 3.1.2 and 01/10 for 3.2.
I agree that released 3.1.2 as the first release as a TLP is a good
plan. Looks like we've got some work to do to get 3.2 out the door by
October (http://tinyurl.com/2cbduz) and I've got some additional
issues that I need to file and work to do for the archetypes. There
seem to be a handful of smallish bugs there.
> On the middle term, I'd like to start working on ServiceMix 4.0. We
> already discussed that a bit and the key points is OSGi. I have been
> experimenting a bit in some branches on svn and I really think OSGi
> will provide the needed platform to base ServiceMix 4.0 on. At the
> same time, I have been working on a new API for ServiceMix 4.0 which
> is available at https://svn.apache.org/repos/asf/incubator/
> servicemix/branches/servicemix-4.0/api. This is work in progress and
> I'd like feedback on it as much as possible. I will start a separate
> thread about ServiceMix 4.0.
I haven't had the time to look at your OSGi work since back in May
when we were at JavaOne so I'll take a look at this. I'd also like to
make sure that we document the new APIs much better than the existing
stuff. One of the biggest shortcomings currently is Javadoc and
comments to provide others an understanding of the code.
> On the long term, I'd like ServiceMix to support JBI 2.0 and SCA.
> It will obviously depend on when JBI 2.0 spec is released...
In addition, I'd like to create more formal thread pooling support
package for SMX and I think that the 4.0 branch is the best place to
do this work. But I won't be starting work on this until we have a
good handle on the 3.1.2 and 3.2 releases.
I have also begun work on providing better Javadocs and comments in
the new servicemix-jms consumer and provider endpoints. Once this is
complete I will begin to doc the new servicemix-http consumer and
provider endpoints. This is all a work in progress that I will just
continually check in as I go. I suppose I should file an issue to
track this work as it is committed.
I was also digging around today in the activemq-web-console wondering
about getting it running in SMX for monitoring destinations. On a
related note, when are we planning on upgrading ActiveMQ? Are we
waiting for SMX 4.0?
Bruce
--
perl -e 'print unpack("u30","D0G)[EMAIL
PROTECTED]&5R\"F)R=6-E+G-N>61Ehttp://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
Are geronimo 2.0.1 artifacts availble in maven2 repo?
Hi, Congratulations on the Geronimo 2.0.1 release. Are the released artifacts availble in maven2 repo now? Thanks, Raymond
[jira] Created: (DAYTRADER-53) Remove EJB 2.1 components from Daytrader 2.0
Remove EJB 2.1 components from Daytrader 2.0 Key: DAYTRADER-53 URL: https://issues.apache.org/jira/browse/DAYTRADER-53 Project: DayTrader Issue Type: Task Components: EJB Tier, J2EE Application Clients, Web Tier Affects Versions: 2.0 Reporter: Christopher James Blythe A while back I started some discussion around whether or not the old EJB 2.1 components should continue to be maintained in DayTrader 2.0. Their are arguments for and against; however, I still feel removing the legacy components is the best option. The only argument for leaving the EJB 2.1 components in is that you can easily switch between 2.1 and 3.0 without restarting the server or installing another app. In my opinion, this is far out-weighed by the cons which include the following factors... - complexity - maintainability - portability Removing the EJB 2.1 components simplifies the application considerably since two versions of the components no longer have to be maintained in the same application. Furthermore, it highlights the "usability" factor that was a major focus for EJB 3. For instance, if I remove the 2.1 components, I no longer need to place anything in the ejb-jar.xml DD. That's a far cry from the EJB 2.1 days... The EJB 2.1 components should be maintained for comparison purposes; however, they should reside in DayTrader 1.2. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Is there a procedure to be followed to put new code in geronimo\plugins
+1 David Jencks wrote: I'm not sure if/when we've faced this in the past but I'd be comfortable with: - moving code to plugins - announcing it on the dev list - in 3-7 days pushing a snapshot if there are no major objections thanks david jencks On Aug 22, 2007, at 12:38 PM, Paul McMahan wrote: Followup question: Once a plugin has been moved from /sandbox to /plugins, is it OK to go ahead and deploy snapshots of the plugin to the ASF snapshot repo? The specific reason I'm asking is because the extensible console work that has been going on in GERONIMO-3345 and GERONIMO-3413 is at the point where it would be great to get some feedback and collaboration without having to build the plugins from source.According to http://www.apache.org/dev/repository-faq.html the PMC needs to be "happy" with the binaries before they are "released" to the snapshot repo -- although "release" doesn't seem like the right term for them to use for stuff in the snapshot repo. So, is a heads-up on the dev list adequate for this type of activity, or is something more formal required? Best wishes, Paul On Aug 21, 2007, at 2:24 PM, Vamsavardhana Reddy wrote: I was wondering if there is a procedure to be followed to put new code in geronimo\plugins? I intend to move the geronimo-tuscany integration thing Manu and myself are working on out of sandbox and put under geronimo\plugins. Also, is there a release cycle for geronimo plugins? Thanks and regards, Vamsi .
[jira] Created: (GERONIMO-3438) context-root error
context-root error -- Key: GERONIMO-3438 URL: https://issues.apache.org/jira/browse/GERONIMO-3438 Project: Geronimo Issue Type: Sub-task Security Level: public (Regular issues) Reporter: lucols -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-3438) context-root error
[
https://issues.apache.org/jira/browse/GERONIMO-3438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
lucols updated GERONIMO-3438:
-
Component/s: Tomcat
Description:
In geronimo-web.xml , I configure context-root to nothing , like this :
thr problem is : i got then contextPath is "/" ,not expected " ", so error
occur: the web container cannot right lookup the file.
you can test like this:
index.jsp:
test.jsp:
<%
out.println("request context:"+request.getContextPath());
%>
geronimo-web.xml:
http://geronimo.apache.org/xml/ns/j2ee/web-1.1";>
...
after deploy, test this in IE broswer:
http://hostname:8080/index.jsp
Environment:
debian 3.1/4.0
sun jdk 1.5.0_11-b03
apache 2.0.59/2.2.4
Affects Version/s: 2.1
> context-root error
> --
>
> Key: GERONIMO-3438
> URL: https://issues.apache.org/jira/browse/GERONIMO-3438
> Project: Geronimo
> Issue Type: Sub-task
> Security Level: public(Regular issues)
> Components: Tomcat
>Affects Versions: 2.1
> Environment: debian 3.1/4.0
> sun jdk 1.5.0_11-b03
> apache 2.0.59/2.2.4
>Reporter: lucols
>
> In geronimo-web.xml , I configure context-root to nothing , like this :
>
> thr problem is : i got then contextPath is "/" ,not expected " ", so error
> occur: the web container cannot right lookup the file.
> you can test like this:
> index.jsp:
>
> test.jsp:
> <%
> out.println("request context:"+request.getContextPath());
> %>
> geronimo-web.xml:
>
>xmlns="http://geronimo.apache.org/xml/ns/j2ee/web-1.1";>
> ...
>
>
> after deploy, test this in IE broswer:
> http://hostname:8080/index.jsp
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Is there a procedure to be followed to put new code in geronimo\plugins
On Aug 22, 2007, at 3:45 PM, David Jencks wrote: I'm not sure if/when we've faced this in the past but I'd be comfortable with: - moving code to plugins - announcing it on the dev list - in 3-7 days pushing a snapshot if there are no major objections Sounds ok. I would expect that we'd have had some advanced warning before the code had been moved into plugins... With such advance notice, I'd say 3 day lazy consensus period is quite adequate. This is somewhat akin to adding a new module to Geronimo server and "deploying" the new jar file to a snapshot repository. Major difference is people tend to watch server development a bit more closely... --kevan
[jira] Assigned: (GERONIMO-3421) ClassFinder classloader problems cause deployer to hang
[ https://issues.apache.org/jira/browse/GERONIMO-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Donald Woods reassigned GERONIMO-3421: -- Assignee: Donald Woods > ClassFinder classloader problems cause deployer to hang > --- > > Key: GERONIMO-3421 > URL: https://issues.apache.org/jira/browse/GERONIMO-3421 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment >Affects Versions: 2.0.x > Environment: Java(TM) 2 Runtime Environment, Standard Edition (build > 1.5.0_12-b04) > CentOS release 5 (Final) >Reporter: toby cabot >Assignee: Donald Woods >Priority: Minor > Fix For: 2.0.x > > Attachments: deployer-message-patch.txt > > > I build an ear file (containing a rar and a war) with a bug and tried to > deploy it. The deployer printed this stack trace to the console and then > hung: > Exception in thread "Thread-6" java.lang.NoClassDefFoundError: > org/jdom/JDOMException > at java.lang.Class.getDeclaredMethods0(Native Method) > at java.lang.Class.privateGetDeclaredMethods(Class.java:2395) > at java.lang.Class.getDeclaredMethods(Class.java:1763) > at org.apache.xbean.finder.ClassFinder.(ClassFinder.java:162) > at > org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.createWebAppClassFinder(AbstractWebModuleBuilder.java:796) > at > org.apache.geronimo.web25.deployment.AbstractWebModuleBuilder.configureBasicWebModuleAttributes(AbstractWebModuleBuilder.java:813) > at > org.apache.geronimo.jetty6.deployment.JettyModuleBuilder.addGBeans(JettyModuleBuilder.java:337) > at > org.apache.geronimo.jetty6.deployment.JettyModuleBuilder$$FastClassByCGLIB$$1a00be84.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:124) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) > 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$$35300f85.addGBeans() > at > org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder.addGBeans(SwitchingModuleBuilder.java:165) > at > org.apache.geronimo.j2ee.deployment.SwitchingModuleBuilder$$FastClassByCGLIB$$d0c31844.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:124) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) > 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$$35300f85.addGBeans() > at > org.apache.geronimo.j2ee.deployment.EARConfigBuilder.buildConfiguration(EARConfigBuilder.java:628) > 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:124) > at > org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:830) > 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.CorbaGBeanNameSource$$EnhancerByCGLIB$$6c5d899a.buildConfiguration() > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:304) > at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:126) > at > org.apache.geronimo.deployment.Deployer$$FastClassByCGLIB$$734a235d.invoke() > at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) > at > org.apache.geronimo.gbean.runtime.FastMethodInvoker.invok
