[jira] Created: (GERONIMO-2323) Plugins Installer should use proxy configuration for download/install plugins
Plugins Installer should use proxy configuration for download/install plugins - Key: GERONIMO-2323 URL: http://issues.apache.org/jira/browse/GERONIMO-2323 Project: Geronimo Issue Type: Wish Security Level: public (Regular issues) Components: Plugins Affects Versions: Wish List Reporter: Sergey Elin Priority: Minor Then Geronimo works behind the proxy it is unable to download and install plugins using Plugin Installer because of connection timeout. Proxy configuration (e.g. Proxy Host, Proxy Port, Proxy Type, Proxy User, Proxy Password) should be added to Plugin Installer. -- 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: [XBEAN] Mailing lists
The mailing lists have been created, now.So everyone should be able to join: mailto:[EMAIL PROTECTED] mailto: [EMAIL PROTECTED]On 8/12/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: Done, see http://issues.apache.org/jira/browse/INFRA-910 On 8/11/06, Guillaume Nodet < [EMAIL PROTECTED]> wrote:It seems that there is a consensus to create these mailing lists. I will raise a JIRA for that on infra.On 8/1/06, Guillaume Nodet < [EMAIL PROTECTED]> wrote: While looking at http://issues.apache.org/jira/browse/XBEAN-28,I was wondering if we should ask for xbean specific mailing lists. [EMAIL PROTECTED] [EMAIL PROTECTED]Any opinion ? -- Cheers,Guillaume Nodet -- Cheers,Guillaume Nodet -- Cheers,Guillaume Nodet -- Cheers,Guillaume Nodet
[jira] Created: (GERONIMO-2322) remove and specifications from project.xml
remove and specifications from project.xml -- Key: GERONIMO-2322 URL: http://issues.apache.org/jira/browse/GERONIMO-2322 Project: Geronimo Issue Type: Improvement Security Level: public (Regular issues) Components: buildsystem Affects Versions: 1.1.2 Reporter: Kevan Miller Fix For: 1.1.2 Some module project.xml files contain and specifications. As these override the settings in etc/project.xml, there can be unexpected results. Updates to etc/project.xml may not be reflected in these modules. Better to fold all behavior into etc/project.xml, if possible. -- 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-2308) All Geronimo JARs should include a NOTICE.txt file in addition to the LICENSE.txt file
[ http://issues.apache.org/jira/browse/GERONIMO-2308?page=all ] Kevan Miller updated GERONIMO-2308: --- Description: Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording "Redistribution and use of this software" in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(/)|(/)|applications\console-core| Notice needs IBM attribution?| |(x)|(/)|(/)|applications\console-ear|Notice needs IBM attribution?| |(x)|(/)|(/)|applications\console-framework|Notice needs IBM attribution?| |(x)|(/)|(/)|applications\console-standard|Notice needs IBM attribution?| |(x)|(/)|(/)|applications\daytrader| | |(x)|(/)|(/)|applications\demo| | |(x)|(/)|(/)|applications\ldap-realm-demo| | |(x)|(/)|(/)|applications\magicGball| | |(x)|(/)|(/)|applications\project.properties| | |(x)|(/)|(/)|applications\remote-deploy| | |(x)|(/)|(/)|applications\remote-deploy-lib| | |(x)|(/)|(/)|applications\uddi-db| | |(x)|(/)|(/)|applications\uddi-server| | |(x)|(/)|(/)|applications\welcome| | |(?)|(/)|(/)|modules\activation| | |(x)|(/)|(/)|modules\activemq-embedded-rar| | |(?)|(/)|(/)|modules\axis| | |(?)|(/)|(/)|modules\axis-builder| | |(?)|(/)|(/)|modules\client| | |(?)|(/)|(/)|modules\client-builder| | |(?)|(/)|(/)|modules\common| | |(?)|(/)|(/)|modules\connector| | |(?)|(/)|(/)|modules\connector-builder| | |(/)|(/)|(/)|modules\console-web| (Won't fix in trunk) | |(?)|(/)|(/)|modules\converter| | |(?)|(/)|(/)|modules\core| | |(?)|(/)|(/)|modules\deploy-config| | |(?)|(/)|(/)|modules\deploy-jsr88| | |(?)|(/)|(/)|modules\deploy-tool| | |(?)|(/)|(/)|modules\deployment| | |(?)|(/)|(/)|modules\derby| | |(?)|(/)|(/)|modules\directory| | |(?)|(/)|(/)|modules\hot-deploy| | |(?)|(/)|(/)|modules\installer-processing| | |(?)|(/)|(/)|modules\installer-support| | |(?)|(/)|(/)|modules\j2ee| | |(?)|(/)|(/)|modules\j2ee-builder| | |(?)|(/)|(/)|modules\j2ee-schema| | |(/)|(/)|(/)|modules\javamail-transport| (No longer in trunk) | |(?)|(/)|(/)|modules\jetty| | |(?)|(/)|(/)|modules\jetty-builder| | |(?)|(/)|(/)|modules\jmx-remoting| | |(?)|(/)|(/)|modules\kernel| | |(?)|(/)|(/)|modules\mail| | |(?)|(/)|(/)|modules\management| | |(?)|(/)|(/)|modules\naming| | |(?)|(/)|(/)|modules\naming-builder| | |(/)|(/)|(/)|modules\scripts| (Not distributed) | |(?)|(/)|(/)|modules\security| | |(?)|(/)|(/)|modules\security-builder| | |(?)|(/)|(/)|modules\service-builder| | |(?)|(/)|(/)|modules\system| | |(?)|(/)|(/)|modules\test-ddbean| | |(?)|(/)|(/)|modules\timer| | |(?)|(/)|(/)|modules\tomcat| | |(?)|(/)|(/)|modules\tomcat-builder| | |(?)|(/)|(/)|modules\transaction| | |(?)|(/)|(/)|modules\upgrade| | |(?)|(/)|(/)|modules\util| | |(?)|(/)|(/)|modules\web-builder| | |(?)|(/)|(/)|modules\webservices| | was: Currently Geronimo jars (e.g. the JARs for each application/module) do not contain a NOTICE.txt file under the META-INF directory. The NOTICE.txt files in modules needs to contain attributions that are relevant for that module (not Geronimo as a whole). For example, if the module has a dependency on a library that has a license requiring attributions upon use of the library (e.g. it has wording "Redistribution and use of this software" in the library license) then the module using the library should contain the attribution in the NOTICE.txt file. Whilst reviewing attributions, the LICENSE.txt files for the modules and applications should also be updated to include the relevant licenses. The following is a checklist to help track what has been done, in case someone wants to help out :-) (x) = not done (?) = partially done (/) = done ||trunk||1.1||1.1.1||Notes|| |(x)|(/)|(/)|applications\console-core| Notice needs IBM attribution?| |(x)|(/)|(/)|applications\console-ear|Notice needs IBM attribution?| |(x)|(/)|(/)|applications\console-framework|Notice needs IBM attribution?| |(x)|(/)|(/)|applications\console-standard|Notice needs IBM attribution?| |(x)|(/)|(/)|applications\daytrader| | |(x)|(/)|(/)|applications\demo| | |(x)|(/)|(/)|applications\ldap-realm-demo| | |(x)|(/)|(/)|applications\magicGball| | |(x)|(/)|(/)|applications\project.properties| | |(x)|(/)|(/)|applications\remote-deploy| | |(x)|(/)|(/)|applications\remote-deploy-lib| | |(x)|(/)|(/)|applications\uddi-db| | |(x)|(/)|(/)|applicati
[jira] Commented: (GERONIMO-2308) All Geronimo JARs should include a NOTICE.txt file in addition to the LICENSE.txt file
[ http://issues.apache.org/jira/browse/GERONIMO-2308?page=comments#action_12428034 ] Kevan Miller commented on GERONIMO-2308: Removed the NOTICES.txt specification from most module project.xml files. Added a NOTICE.txt specification to etc/project.xml. Some /project.xml files still contain a resource specification for NOTICES.txt. These project.xml files already contained a specification. The additional NOTICE.txt was needed to include the file in these jar files. I think most of these can be removed (etc/project.xml will do the right thing). However, I didn't want to take too many chances. I'll raise a jira for these... > All Geronimo JARs should include a NOTICE.txt file in addition to the > LICENSE.txt file > -- > > Key: GERONIMO-2308 > URL: http://issues.apache.org/jira/browse/GERONIMO-2308 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.0, 1.1 >Reporter: John Sisson > Assigned To: John Sisson >Priority: Blocker > Fix For: 1.1.1 > > Attachments: activation-converter.patch, core-installersupport.patch, > j2ee-management.patch, naming-tomcat.patch, tomcatbuilder-webservices.patch > > > Currently Geronimo jars (e.g. the JARs for each application/module) do not > contain a NOTICE.txt file under the META-INF directory. > The NOTICE.txt files in modules needs to contain attributions that are > relevant for that module (not Geronimo as a whole). For example, if the > module has a dependency on a library that has a license requiring > attributions upon use of the library (e.g. it has wording "Redistribution and > use of this software" in the library license) then the module using the > library should contain the attribution in the NOTICE.txt file. > Whilst reviewing attributions, the LICENSE.txt files for the modules and > applications should also be updated to include the relevant licenses. > The following is a checklist to help track what has been done, in case > someone wants to help out :-) > (x) = not done (?) = partially done (/) = done > ||trunk||1.1||1.1.1||Notes|| > |(x)|(/)|(/)|applications\console-core| Notice needs IBM attribution?| > |(x)|(/)|(/)|applications\console-ear|Notice needs IBM attribution?| > |(x)|(/)|(/)|applications\console-framework|Notice needs IBM attribution?| > |(x)|(/)|(/)|applications\console-standard|Notice needs IBM attribution?| > |(x)|(/)|(/)|applications\daytrader| | > |(x)|(/)|(/)|applications\demo| | > |(x)|(/)|(/)|applications\ldap-realm-demo| | > |(x)|(/)|(/)|applications\magicGball| | > |(x)|(/)|(/)|applications\project.properties| | > |(x)|(/)|(/)|applications\remote-deploy| | > |(x)|(/)|(/)|applications\remote-deploy-lib| | > |(x)|(/)|(/)|applications\uddi-db| | > |(x)|(/)|(/)|applications\uddi-server| | > |(x)|(/)|(/)|applications\welcome| | > |(?)|(x)|(x)|modules\activation| | > |(x)|(x)|(x)|modules\activemq-embedded-rar| | > |(?)|(x)|(x)|modules\axis| | > |(?)|(x)|(x)|modules\axis-builder| | > |(?)|(x)|(x)|modules\client| | > |(?)|(x)|(x)|modules\client-builder| | > |(?)|(x)|(x)|modules\common| | > |(?)|(x)|(x)|modules\connector| | > |(?)|(x)|(x)|modules\connector-builder| | > |(/)|(x)|(x)|modules\console-web| (Won't fix in trunk) | > |(?)|(x)|(x)|modules\converter| | > |(?)|(x)|(x)|modules\core| | > |(?)|(x)|(x)|modules\deploy-config| | > |(?)|(x)|(x)|modules\deploy-jsr88| | > |(?)|(x)|(x)|modules\deploy-tool| | > |(?)|(x)|(x)|modules\deployment| | > |(?)|(x)|(x)|modules\derby| | > |(?)|(x)|(x)|modules\directory| | > |(?)|(x)|(x)|modules\hot-deploy| | > |(?)|(x)|(x)|modules\installer-processing| | > |(?)|(x)|(x)|modules\installer-support| | > |(?)|(x)|(x)|modules\j2ee| | > |(?)|(x)|(x)|modules\j2ee-builder| | > |(?)|(x)|(x)|modules\j2ee-schema| | > |(/)|(x)|(x)|modules\javamail-transport| (No longer in trunk) | > |(?)|(x)|(x)|modules\jetty| | > |(?)|(x)|(x)|modules\jetty-builder| | > |(?)|(x)|(x)|modules\jmx-remoting| | > |(?)|(x)|(x)|modules\kernel| | > |(?)|(x)|(x)|modules\mail| | > |(?)|(x)|(x)|modules\management| | > |(?)|(x)|(x)|modules\naming| | > |(?)|(x)|(x)|modules\naming-builder| | > |(/)|(x)|(x)|modules\scripts| (Not distributed) | > |(?)|(x)|(x)|modules\security| | > |(?)|(x)|(x)|modules\security-builder| | > |(?)|(x)|(x)|modules\service-builder| | > |(?)|(x)|(x)|modules\system| | > |(?)|(x)|(x)|modules\test-ddbean| | > |(?)|(x)|(x)|modules\timer| | > |(?)|(x)|(x)|modules\tomcat| | > |(?)|(x)|(x)|modules\tomcat-builder| | > |(?)|(x)|(x)|modules\transaction| | > |(?)|(x)|(x)|modules\upgrade| | > |(?)|(x)|(x)|modules\util| | > |(?)|(x)|(x)|modules\web-builder| | > |(?)|(x)|(x)|modules\webservices| | -- This message is automatically generated by JIRA. - If you think it was sent incorrect
[jira] Commented: (AMQ-855) Add support for prefetchSize = 0
[ https://issues.apache.org/activemq/browse/AMQ-855?page=comments#action_36782 ] Vadim Pesochinskiy commented on AMQ-855: James, I added implementation of pulling consumer whereby pullMessage() returns a response. Could you please browse through it and give me a feedback? Patches are for file versions PrefetechSubscription.java 1.15 and 1.22 ActiveMQMessageConsumer.java Current implementation does not work for me, because when recieve(long) call times out the prefetch window is increasing and we are back to where we started. Thanks a lot. > Add support for prefetchSize = 0 > > > Key: AMQ-855 > URL: https://issues.apache.org/activemq/browse/AMQ-855 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 4.0.2, 4.0.1, 4.0 > Environment: any >Reporter: Vadim Pesochinskiy >Priority: Critical > Fix For: 4.1 > > Attachments: ActiveMQMessageConsumer.patch, PrefetchSubscription.patch > > > This feature would enable to support following test case: > 2 servers are processing 3 submitted jobs with following processing times 10 > min, 1 min, 1 min. This sequence should finish in 10 minutes as one service > will pick up the 10 minutes job, meanwhile the other one should manage the > two 1 minute jobs. Since I cannot set prefetchSize=0, one of the 1 minute > jobs is sitting in prefetch buffer and the jobs are processed in 11 minutes > instead of 10. > This is simplification of the real scenario where I have about 30 consumers > submitting jobs to 20 consumers through AMQ 4.0.1. I have following problems: > Messages are sitting in prefetch buffer are not available to processors, > which results in a lot of idle time. > Order of processing is random. For some reason Job # 20 is processed after > Job # 1500. Since senders are synchronously blocked this can result in > time-outs. > Some requests are real-time, i.e. there is a user waiting, so the system > cannot wait, so AMQ-850 does not fix this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-855) Add support for prefetchSize = 0
[ https://issues.apache.org/activemq/browse/AMQ-855?page=all ] Vadim Pesochinskiy updated AMQ-855: --- Attachment: ActiveMQMessageConsumer.patch > Add support for prefetchSize = 0 > > > Key: AMQ-855 > URL: https://issues.apache.org/activemq/browse/AMQ-855 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 4.0.2, 4.0.1, 4.0 > Environment: any >Reporter: Vadim Pesochinskiy >Priority: Critical > Fix For: 4.1 > > Attachments: ActiveMQMessageConsumer.patch, PrefetchSubscription.patch > > > This feature would enable to support following test case: > 2 servers are processing 3 submitted jobs with following processing times 10 > min, 1 min, 1 min. This sequence should finish in 10 minutes as one service > will pick up the 10 minutes job, meanwhile the other one should manage the > two 1 minute jobs. Since I cannot set prefetchSize=0, one of the 1 minute > jobs is sitting in prefetch buffer and the jobs are processed in 11 minutes > instead of 10. > This is simplification of the real scenario where I have about 30 consumers > submitting jobs to 20 consumers through AMQ 4.0.1. I have following problems: > Messages are sitting in prefetch buffer are not available to processors, > which results in a lot of idle time. > Order of processing is random. For some reason Job # 20 is processed after > Job # 1500. Since senders are synchronously blocked this can result in > time-outs. > Some requests are real-time, i.e. there is a user waiting, so the system > cannot wait, so AMQ-850 does not fix this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-855) Add support for prefetchSize = 0
[ https://issues.apache.org/activemq/browse/AMQ-855?page=all ] Vadim Pesochinskiy updated AMQ-855: --- Attachment: PrefetchSubscription.patch > Add support for prefetchSize = 0 > > > Key: AMQ-855 > URL: https://issues.apache.org/activemq/browse/AMQ-855 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Affects Versions: 4.0.2, 4.0.1, 4.0 > Environment: any >Reporter: Vadim Pesochinskiy >Priority: Critical > Fix For: 4.1 > > Attachments: ActiveMQMessageConsumer.patch, PrefetchSubscription.patch > > > This feature would enable to support following test case: > 2 servers are processing 3 submitted jobs with following processing times 10 > min, 1 min, 1 min. This sequence should finish in 10 minutes as one service > will pick up the 10 minutes job, meanwhile the other one should manage the > two 1 minute jobs. Since I cannot set prefetchSize=0, one of the 1 minute > jobs is sitting in prefetch buffer and the jobs are processed in 11 minutes > instead of 10. > This is simplification of the real scenario where I have about 30 consumers > submitting jobs to 20 consumers through AMQ 4.0.1. I have following problems: > Messages are sitting in prefetch buffer are not available to processors, > which results in a lot of idle time. > Order of processing is random. For some reason Job # 20 is processed after > Job # 1500. Since senders are synchronously blocked this can result in > time-outs. > Some requests are real-time, i.e. there is a user waiting, so the system > cannot wait, so AMQ-850 does not fix this issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: XBean and QDox
Note that if you are not using any Java 1.5 features, there's really no difference between the tiger and retrotranslated code (other than it works on 1.4). The only strangeness is that the java.lang.* and java.util.* stuff thats new in 1.5 gets swizzled to something in retrotranslator or backport-util-concurrent but you can still debug just fine. On 8/15/06, Dan Diephouse <[EMAIL PROTECTED]> wrote: Alan D. Cabrera wrote: > James Strachan wrote: >> On 8/13/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >>> It seems that nobody work on QDox since several months. >>> (see >>> http://www.nabble.com/Anyone-developing-QDox--tf705135r1.html) >>> Does anyone know of any replacement we could use to allow java 5 >>> parsing ? >>> >>> I was thinking of introducing real annotations, but this would make >>> xbean-spring >>> JDK 5 specific. >>> >>> Any thoughts ? >> >> We could compile the source with Java 5, use source-only annotations >> maybe - then generate Java 1.4 compliant code via retrotranslator. >> > Can I debug retrotranslated code in JDK14? > > > Regards, > Alan > > Yes. Dain did a whole bunch of experiments on this if you want to know more details. From what I understand they went quite well. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog -- James --- http://radio.weblogs.com/0112098/
Re: AJAX and Geronimo
Hi Jay, from what I understand cross domain javascript security only comes into play when the javascript and the html that references it come from different domains (i.e. different hostnames and/or subnets). Unless I'm mistaken I don't think what's been proposed in this thread would be affected by cross domain security since the webapps and the Dojo files would be hosted on the same server, albeit under different contexts. Thanks for offering to help test this out. I'll send you a WAR file containing the Dojo files in a separate email. You should be able to deploy the WAR into Geronimo, remove Dojo from your webapp, and then point your webapp's html at "/dojo/dojo.js". Best wishes, Paul On 8/14/06, Jay D. McHugh <[EMAIL PROTECTED]> wrote: Hello all, The application that I am currently developing under Geronimo is using Dojo (mostly for it's asynchronous HTTP support). Because it is a javascript library, there are limitations that come up if you ever try to cross domains in your URLs. Those limitations are basically that you cannot use javascript to access a different domain that the one the javascript was called from (at least that is how I currently understand it). They did that to prevent cross-site scripting abuse. But, I do have everything that I need working right now. So I would be more that happy to do testing for pulling the Dojo library out of my war files and referencing a single shared library (as long as you use version 0.3.1 or higher - the current version). Jay
Re: XBean and QDox
Alan D. Cabrera wrote: James Strachan wrote: On 8/13/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: It seems that nobody work on QDox since several months. (see http://www.nabble.com/Anyone-developing-QDox--tf705135r1.html) Does anyone know of any replacement we could use to allow java 5 parsing ? I was thinking of introducing real annotations, but this would make xbean-spring JDK 5 specific. Any thoughts ? We could compile the source with Java 5, use source-only annotations maybe - then generate Java 1.4 compliant code via retrotranslator. Can I debug retrotranslated code in JDK14? Regards, Alan Yes. Dain did a whole bunch of experiments on this if you want to know more details. From what I understand they went quite well. - Dan -- Dan Diephouse Envoi Solutions http://envoisolutions.com http://netzooid.com/blog
Re: Build failure on branches/1.1.1
On Aug 13, 2006, at 5:24 PM, Aaron Mulder wrote: OK, I think I'm going to leave this for now, but... It looks like the problem below is definitely that as of a few days ago, configs/openejb-deployer/target/plan/plan.xml had a dependency on axis, and now it doesn't. I still don't know what could have changed (other than the project.xml in openejb-builder or openejb-deployer or something with the dependency or packaging plugin) to change this. I guess the brute-force fix is to work through all the failing configs and mark the JARs in question as geronimo.dependency=true, but it would be nice to understand what changed. The problem is caused by the /project.xml changes which were added to include the NOTICE files in each jar file. These changes added ... config to include NOTICE.txt in the jar files produced during a build. Problem is that etc/project.xml contains project wide specification for resources to be included in jar files. The module specific resource specification is overriding the etc/project.xml settings. Thus the project-wide directives for resources are being ignored... In the current failure (java.lang.NoClassDefFoundError: org/apache/ axis/Handler), geronimo-axis-1.1.1-SNAPSHOT.jar does not contain META- INF/geronimo-dependency.xml... I'm working on the fix... --kevan On 8/13/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: OK, the project.xml fixes helped, but we're still getting the failures in configs, e.g.: + | configurations openejb Configuration for performing J2EE deployments | Memory: 14M/25M + ... 16:16:39,866 ERROR [Deployer] Deployment failed due to java.lang.NoClassDefFoundError: org/apache/axis/Handler It doesn't look like much has changed in the modules in question for quite some time... Looking at branches/1.1: openejb/modules/openejb-builder: 12 days configs/openejb-deployer: 7 weeks plugins/geronimo-packaging-plugin: 11 days, except NOTICE change I did discover that the OpenEJB 2.1.2 branch was still using the Geronimo 1.1.1 M1 plugins instead of the Geronimo 1.1.2 M1 plugins, but wiping out all my Geronimo M1 plugins and fixing that didn't solve the problem. Any other ideas what might have changed to cause this? Something that would make dependencies suddenly fail during CAR packaging? Thanks, Aaron On 8/13/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: > Doesn't look like Alan's changes caused the problem -- they were > pretty small and localized. > > The openejb-builder failures appear to be caused by a typo in > axis-builder project.xml introduced as part of the NOTICE changes. > Kevan is looking and has found at least one more bad project.xml too. > > Thanks, > Aaron > > On 8/13/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: > > I swa the same on Friday and was going to checkout a new set of branches to make sure I hadn't > > cobbled anything up. Looks like its chronic :( I think it started after the security fix but need > > to verify if that is the culprit. > > > > Aaron Mulder wrote: > > > I just tried to build this branche from scratch and I get a dependency > > > failure in the OpenEJB deployer on Axis. I confirmed that my OpenEJB > > > is http://svn.codehaus.org/openejb/branches/v2_1_1/openejb2. > > > > > > Thanks, > > > Aaron > > > > > > + > > > | configurations openejb Configuration for performing J2EE deployments > > > | Memory: 14M/25M > > > + > > > DEPRECATED: the default goal should be specified in the > > > section of project.xml instead of maven.xml > > > DEPRECATED: the default goal should be specified in the > > > section of project.xml instead of maven.xml > > > > > > build:end: > > > > > > You are working offline so the build will continue, but > > > geronimo-axis-builder-1.1.1-SNAPSHOT.jar may be out of date! > > > You are working offline so the build will continue, but > > > openejb-builder-2.1.1-SNAPSHOT.jar may be out of date! > > > build:start: > > > > > > multiproject:install-callback: > > >[echo] Running car:install for openejb Configuration for > > > performing J2EE deployments > > > car:prepare-plan: > > > > > > car:package: > > >[delete] Deleting directory > > > /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/ repository > > >[mkdir] Created dir: > > > /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/ repository > > > > > >Packaging configuration > > > /data/cvs/geronimo-1.1.1/configs/openejb-deployer/target/ plan/plan.xml > > > > > > 15:14:17,919 ERROR [Deployer] Deployment failed due to > > > java.lang.NoClassDefFoundError: org/apache/axis/Handler > > >at java.lang.Class.forName0(Native Method) > > >at java.lang.Class.forName(Class.java:141) > > >at > > > org.openejb.server.axis.WSContainerGBean.class$ (WSContainerGBean.java:61) > > >
Re: POM Update for Specs...need a few eyeballs
Which spec was updated by Alan's fix? Shouldn't it be at a SNAPSHOT version, also? I'd expect geronimoSpecsVersion and at least one spec version to be SNAPSHOT... Are there any other spec changes which will be released? --kevan On Aug 14, 2006, at 4:05 PM, Matt Hogstrom wrote: The old pom for the specifications had some old links in it. I have updated the POM with what I think is correct so we can use Maven 2 to release the specs rather than rely on manually doing this. This is the updated POM for the specifications. This will update the branches/1.1 pom.xml Can you take a few minutes to take a look at the proposed pom? You can find it here http://svn.apache.org/repos/asf/geronimo/specs/branches/1_1/ pom.xml.proposed I'd like to confirm the scm and dist sections are correct. Any other errors / comments welcome. Thanks!
[jira] Created: (GERONIMODEVTOOLS-101) remote debugging
remote debugging Key: GERONIMODEVTOOLS-101 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-101 Project: Geronimo-Devtools Issue Type: New Feature Components: eclipse-plugin Affects Versions: 1.1.0 Environment: IBM JVM 1.5, Eclipse 3.2.0, WTP 1.5, w2k/w3k, remote either w?k or linux Reporter: Oleg Gusakov The "publish by copy" seems to open a very interesting possibility of publishing to a remote server and attaching to it fro remote debugging. As this is possible to do manually, I think plugin should be able to support such deployment - maybe setup a "file receiver" on the other end. Such functionality will definitely open the door into real life [semi-]production debugging. Even QA problems may be solved much faster. -- 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: (GERONIMODEVTOOLS-100) publishing hundreds of web projects / dependencies - GUI usability
publishing hundreds of web projects / dependencies - GUI usability -- Key: GERONIMODEVTOOLS-100 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-100 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.1.0 Environment: IBM Java 1.5, Eclipse 3.2.0, WTP 1.5, w2k/w3k Reporter: Oleg Priority: Critical When there are several hundred projects, publishing/removing them from Geronimo becomes a tedious task. We need a clearer GUI to address that, probably some kind of hierarchical markup in the project metadata. Or combine that with Maven POM metadata ... -- 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: (GERONIMODEVTOOLS-99) need to publish web project dependencies outside of WAR
need to publish web project dependencies outside of WAR Key: GERONIMODEVTOOLS-99 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-99 Project: Geronimo-Devtools Issue Type: Improvement Components: eclipse-plugin Affects Versions: 1.1.0 Environment: IBM Java 1.5, Eclipse 3.2.0, WTP 1.5, w2k/w3k, 32/64 bit Reporter: Oleg Priority: Blocker In our use case for geronimo plugin we need to be able to deploy WAR project dependencies outside of WAR. The best place seems to SharedLib deployer. Dependencies to deploy include: - Eclipse WAR project references to other Eclipse projects - external JAR files, attached to the project and/ot it's dependencies - external dependencies supplied by Maven plugin from project's POM file. This is almost identical to the previous one. All dependencies need to be deployed "in place" for efficiency reasons. Binary dependencies do not change often and can reside in one classloader. Eclipse projects, on the other hand, change a lot and could be subjected to hot redeployment, so they probably should reside in their own set of classloaders. Please consider for implementation. -- 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: (SM-536) The defaultMep is a mandatory attribute on consumer endpoints and should be checked
[ https://issues.apache.org/activemq/browse/SM-536?page=all ] Guillaume Nodet updated SM-536: --- Fix Version/s: 3.0 (was: 3.0-M3) > The defaultMep is a mandatory attribute on consumer endpoints and should be > checked > --- > > Key: SM-536 > URL: https://issues.apache.org/activemq/browse/SM-536 > Project: ServiceMix > Issue Type: Bug > Components: servicemix-http, servicemix-jms >Reporter: Guillaume Nodet > Fix For: 3.0 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC
Congratulations Alan! Anita --- Matt Hogstrom <[EMAIL PROTECTED]> wrote: > The Apache Geronimo PMC would like to let everyone know that Alan > Cabrera has accepted the > invitation to join the Geronimo PMC. We are excited to have Alan > assisting with project oversight > in addition to his technical contributions to Geronimo. > > Alan has been active in Geronimo for many years and has helped not > only to help in Geronimo directly > but in related efforts like Ode, Yoko and others. > > Give it up for Alan :) > > The Apache Geronimo PMC > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: AJAX and Geronimo
Hello all, The application that I am currently developing under Geronimo is using Dojo (mostly for it's asynchronous HTTP support). Because it is a javascript library, there are limitations that come up if you ever try to cross domains in your URLs. Those limitations are basically that you cannot use javascript to access a different domain that the one the javascript was called from (at least that is how I currently understand it). They did that to prevent cross-site scripting abuse. But, I do have everything that I need working right now. So I would be more that happy to do testing for pulling the Dojo library out of my war files and referencing a single shared library (as long as you use version 0.3.1 or higher - the current version). Jay
Re: [WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC
Congrats Alan! Gianny On 15/08/2006, at 4:14 AM, Matt Hogstrom wrote: The Apache Geronimo PMC would like to let everyone know that Alan Cabrera has accepted the invitation to join the Geronimo PMC. We are excited to have Alan assisting with project oversight in addition to his technical contributions to Geronimo. Alan has been active in Geronimo for many years and has helped not only to help in Geronimo directly but in related efforts like Ode, Yoko and others. Give it up for Alan :) The Apache Geronimo PMC
Re: build local binary distribution
ahhh... maven 2 is not fully supported on that branch. It's only fully implemented in the trunk, a.k.a. activemq 4.1. Use maven 1 on the 4.0 branch. On 8/14/06, bmadigan <[EMAIL PROTECTED]> wrote: I had done that, but the archives created don't appear to be complete: ACTIVEMQ_HOME: /home/bmadigan/Applications/activemq-4.0/assembly/target/incubator-activemq-4.0.2-SNAPSHOT Loading message broker from: xbean:activemq.xml Failed to execute main task. Reason: java.lang.NoClassDefFoundError: org/apache/activemq/broker/BrokerFactory Maybe this is an error in the shell script, it does not seem to build a classpath. Hiram Chirino wrote: > > just run mvn install > > that should produce binaries in the target directory and even install > them into your local maven repo. > > On 8/14/06, bmadigan <[EMAIL PROTECTED]> wrote: >> >> I need to build a local binary from a source snapshot so we can >> distribute it >> to our staging and production enviroments. Are there any maven commands >> that >> will build a local distrubtion? >> thanks, >> B. >> -- >> View this message in context: >> http://www.nabble.com/build-local-binary-distribution-tf2104394.html#a5799896 >> Sent from the ActiveMQ - Dev forum at Nabble.com. >> >> > > > -- > Regards, > Hiram > > Blog: http://hiramchirino.com > > -- View this message in context: http://www.nabble.com/build-local-binary-distribution-tf2104394.html#a5800530 Sent from the ActiveMQ - Dev forum at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com
Re: POM Update for Specs...need a few eyeballs
Thanks Guillaume, I'll incorporate these. Guillaume Nodet wrote: Usually, Apache maven root poms should inherit the default apache pom at org.apache apache 3 which leads to the following pom: http://www.ibiblio.org/maven2/org/apache/apache/3/apache-3.pom Doing that will avoid to repeat the locations of Apache repositories (for releases and snapshots). And the site directory should be something like scp://people.apache.org/www/geronimo.apache.org/specs/maven/1.1 or any other thing from scp://people.apache.org/www/geronimo.apache.org/ It will contain the maven site with the javadocs. The wagon ssh-external plugin also has a more recent release which is 1.0-beta-1, though i'm not sure it is needed as the deployment uses ssh and not sshext Last, is the snapshot plugin repository needed ? I don't think so, but ... On 8/14/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: The old pom for the specifications had some old links in it. I have updated the POM with what I think is correct so we can use Maven 2 to release the specs rather than rely on manually doing this. This is the updated POM for the specifications. This will update the branches/1.1 pom.xml Can you take a few minutes to take a look at the proposed pom? You can find it here http://svn.apache.org/repos/asf/geronimo/specs/branches/1_1/pom.xml.proposed I'd like to confirm the scm and dist sections are correct. Any other errors / comments welcome. Thanks!
[jira] Resolved: (SM-513) Support for HTTP basic authentication
[ https://issues.apache.org/activemq/browse/SM-513?page=all ] Guillaume Nodet resolved SM-513. Fix Version/s: 3.0-M3 Resolution: Fixed Assignee: Guillaume Nodet Would you mind updating the documentation please ? See http://goopen.org/confluence/pages/editpage.action?pageId=1928 Author: gnodet Date: Mon Aug 14 14:19:12 2006 New Revision: 431436 URL: http://svn.apache.org/viewvc?rev=431436&view=rev Log: SM-513: support for HTTP basic authentication Added: incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/BasicAuthCredentials.java Modified: incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/HttpEndpoint.java incubator/servicemix/trunk/servicemix-http/src/main/java/org/apache/servicemix/http/processors/ProviderProcessor.java > Support for HTTP basic authentication > - > > Key: SM-513 > URL: https://issues.apache.org/activemq/browse/SM-513 > Project: ServiceMix > Issue Type: New Feature > Components: servicemix-http >Affects Versions: 3.0-M2 >Reporter: Roehl Sioson > Assigned To: Guillaume Nodet > Fix For: 3.0-M3 > > Attachments: patch.txt > > > Need an easy way to configure basic authentication on servicemix-http. The > attached patch is one suggestion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Binary Data in ME over NMR?
I have a SE that encodes inbound data and places the encoded information in the out message of an in/out MessageExchange. The result of encoding the in message is binary data. Is it possible to put this into the out message and traverse the NMR? If so, how? -- View this message in context: http://www.nabble.com/Binary-Data-in-ME-over-NMR--tf2105839.html#a5804318 Sent from the ServiceMix - Dev forum at Nabble.com.
[jira] Assigned: (AMQ-870) Broker fails to deliver messages after restart
[ https://issues.apache.org/activemq/browse/AMQ-870?page=all ]
Rob Davies reassigned AMQ-870:
--
Assignee: Rob Davies
> Broker fails to deliver messages after restart
> --
>
> Key: AMQ-870
> URL: https://issues.apache.org/activemq/browse/AMQ-870
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
>Affects Versions: 4.0.1
> Environment: java version "1.5.0_07", Ubuntu Linux 6.06
>Reporter: Anders Bengtsson
> Assigned To: Rob Davies
> Attachments: debug-output.txt, TestFailingReconnectScenario.java
>
>
> We're running two networked brokers, B1 and B2, with a producer connected to
> B1 and a consumer to B2. Forwarding messages through this initially works
> fine.
> If we re-start broker B2, everything seems to re-connect, but we no longer
> get any messages to the consumer.
> If we instead re-start broker B1, everything works fine.
> I've attached a JUnit test-case illustrating the two scenarios, a working
> re-start of B1 and a breaking re-start of B2.
> Also attached is parts of a log from running the unit test.
> I'm suspicious about log lines like these, but don't know if they are related
> to the problem:
> [2006-08-08 14:36:16] DEBUG: [DemandForwardingBridge] Ignoring sub
> ConsumerInfo
> {commandId = 4, responseRequired = true, consumerId =
> ID:descartes-49241-1155040510241-5:2:1:1, destination = topic://SOME.TOPIC,
> prefetchSize = 32766, maximumPendingMessageLimit = 0, browser = false,
> dispatchAsync = false, selector = null, subcriptionName = null, noLocal =
> false, exclusive = false, retroactive = false, priority = 0, brokerPath =
> [ID:descartes-49241-1155040510241-1:5], optimizedAcknowledge = false,
> noRangeAcks = false, additionalPredicate = null} already subscribed to
> matching destination
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Fwd: AC US Hackathon
Just in case you're not subscribed to community@ -David Begin forwarded message: From: david reid <[EMAIL PROTECTED]> Date: August 14, 2006 5:28:32 AM PDT To: community@apache.org Subject: AC US Hackathon Reply-To: community@apache.org It's that time again - another ApacheCon looms! As a reminder, the hackathon is open to ALL committers and is free to attend - even if you're not able to attend the conference. It's an informal event and takes place the 2 days prior to the conference proper, so this time it's Monday October 9th and Tuesday the 10th. Once the conference starts there will be provision for continuing the hackathon, but admission will require registration for the conference. As usual there is the inevitable desire for a "cooler than cool" t- shirt for those attending the hackathon. If you have artistic tendancies and feel you could design a logo for the t-shirt then fire up your graphic apps and let your imagination go wild. The t-shirts are usually black, but it's open to discussion if you feel another color would be better suited to your design. Mens and womens are usually available. The deadline and submission instructions for design entries will be posted once it has been agreed, but the sooner you have your masterpiece completed the better :-) There may be a charge for the t-shirts and they are only available to those attending the hackathon who have entered their details prior to the ordering deadline (again, to be advised but the earlier you add your details the better). If you plan on attending the hackathon, please add your details to the file hackathons/2006/ApacheCon_US.txt in the committers SVN repository[1]. All committers have full access to this repository, so if you have any problems please contact the infrastructure team to have your access corrected! david [1] https://svn.apache.org/repos/private/committers - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (AMQ-776) ConduitBridge can malfunction when first of a set of consumers goes away
[ https://issues.apache.org/activemq/browse/AMQ-776?page=all ] Kevin Yaussy updated AMQ-776: - Attachment: DemandForwardingBridgeSupport.patch > ConduitBridge can malfunction when first of a set of consumers goes away > > > Key: AMQ-776 > URL: https://issues.apache.org/activemq/browse/AMQ-776 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.0.1 >Reporter: Kevin Yaussy > Assigned To: Rob Davies >Priority: Critical > Fix For: 4.0.3 > > Attachments: ConduitBridge.patch, DemandForwardingBridgeSupport.patch > > > When the following scenario is followed, any of the subsequent consumers will > stop receiving messages. I've reproduced this using the ConsumerTool, and > ProducerTool supplied in the example area of the distribution. > +++ > Start Broker A > Start Broker B > Start Consumer 1, connecting to Broker B, consuming FOO > Start Consumer 2, connecting to Broker B, consuming FOO > Start Publisher, connecting to Broker A, publishing FOO > Ctl-C out of Consumer 1 > Consumer 2 stops receiving messages > +++ > Seems to me that ConduitBridge is supposed to track all consumers for a given > subscription, by way of DemandSubscription. It is seeding DemandSubscription > with the originating consumer, but when subsequent consumers are added, the > ConduitBridge::addToAlreadyInterestedConsumers re-adds the original > subscriber to the DemandSubscription's map - so the map only ever has the > original subscription. > I've attached a patch. Hope the change is good. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: POM Update for Specs...need a few eyeballs
Usually, Apache maven root poms should inherit the default apache pom at org.apache apache 3which leads to the following pom: http://www.ibiblio.org/maven2/org/apache/apache/3/apache-3.pomDoing that will avoid to repeat the locations of Apache repositories (for releases and snapshots). And the site directory should be something like scp://people.apache.org/www/geronimo.apache.org/specs/maven/1.1or any other thing from scp://people.apache.org/www/geronimo.apache.org/It will contain the maven site with the javadocs. The wagon ssh-external plugin also has a more recent release which is 1.0-beta-1,though i'm not sure it is needed as the deployment uses ssh and not sshextLast, is the snapshot plugin repository needed ? I don't think so, but ...On 8/14/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: The old pom for the specifications had some old links in it. I have updated the POM with what Ithink is correct so we can use Maven 2 to release the specs rather than rely on manually doing this.This is the updated POM for the specifications. This will update the branches/1.1 pom.xmlCan you take a few minutes to take a look at the proposed pom?You can find it herehttp://svn.apache.org/repos/asf/geronimo/specs/branches/1_1/pom.xml.proposed I'd like to confirm the scm and dist sections are correct. Any other errors / comments welcome.Thanks!-- Cheers,Guillaume Nodet
[jira] Commented: (AMQ-776) ConduitBridge can malfunction when first of a set of consumers goes away
[ https://issues.apache.org/activemq/browse/AMQ-776?page=comments#action_36780 ] Kevin Yaussy commented on AMQ-776: -- I'll attach a patch file for DemandForwardingBridgeSupport.java which is baselined on the 4.0.1 version. It includes the logging changes from my other call, which you've already applied to 4.0.2. When I was analyzing the problem, it looked to me like there was more to the problem than just clearing out the subscription maps (which is what the 4.0.2 code does). It needed to forward the subscription removal to the broker, which is why my patch calls removeSubscription, which forwards the removal to the broker code, but also removes the entry from the local subscription map. It did not make any difference whether I cleared the remote subscription map, so that step is not in the patch (but could be for cleanliness). I've downloaded the current 4.0.2 snapshot, and applied this change (replacing the 4.0.2 version of clearDownSubscriptions). However, the problem still persists in 4.0.2. So, given other changes in 4.0.2, the change is not compatible - which is bad. The first patch for this call, ConduitBridge.patch, is applicable to 4.0.2. > ConduitBridge can malfunction when first of a set of consumers goes away > > > Key: AMQ-776 > URL: https://issues.apache.org/activemq/browse/AMQ-776 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.0.1 >Reporter: Kevin Yaussy > Assigned To: Rob Davies >Priority: Critical > Fix For: 4.0.3 > > Attachments: ConduitBridge.patch > > > When the following scenario is followed, any of the subsequent consumers will > stop receiving messages. I've reproduced this using the ConsumerTool, and > ProducerTool supplied in the example area of the distribution. > +++ > Start Broker A > Start Broker B > Start Consumer 1, connecting to Broker B, consuming FOO > Start Consumer 2, connecting to Broker B, consuming FOO > Start Publisher, connecting to Broker A, publishing FOO > Ctl-C out of Consumer 1 > Consumer 2 stops receiving messages > +++ > Seems to me that ConduitBridge is supposed to track all consumers for a given > subscription, by way of DemandSubscription. It is seeding DemandSubscription > with the originating consumer, but when subsequent consumers are added, the > ConduitBridge::addToAlreadyInterestedConsumers re-adds the original > subscriber to the DemandSubscription's map - so the map only ever has the > original subscription. > I've attached a patch. Hope the change is good. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC
Congratulations! -dain On Aug 14, 2006, at 11:14 AM, Matt Hogstrom wrote: The Apache Geronimo PMC would like to let everyone know that Alan Cabrera has accepted the invitation to join the Geronimo PMC. We are excited to have Alan assisting with project oversight in addition to his technical contributions to Geronimo. Alan has been active in Geronimo for many years and has helped not only to help in Geronimo directly but in related efforts like Ode, Yoko and others. Give it up for Alan :) The Apache Geronimo PMC
[jira] Created: (GERONIMO-2321) DB Pool wizard allows "/" in the DB Pool name
DB Pool wizard allows "/" in the DB Pool name - Key: GERONIMO-2321 URL: http://issues.apache.org/jira/browse/GERONIMO-2321 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: console Affects Versions: 1.1, 1.1.1 Environment: Geronimo 1.1.1 Reporter: Donald Woods Assigned To: Donald Woods Priority: Minor Fix For: 1.1.x, 1.2 Follow the database pool wizard, create a datasource with the name "jdbc/EmployeeDatasource", the connection test is successful, but when click on the button "deploy", see the following stacktrace in the server output window: org.apache.geronimo.common.DeploymentException: java.lang.IllegalArgumentException: Invalid id: console.dbpool/jdbc/EmployeeDatasource/1.0/rar at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:364) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:124) 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.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:122) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:852) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:239) at org.apache.geronimo.deployment.plugin.local.AbstractDeployCommand.doDeploy(AbstractDeployCommand.java:106) at org.apache.geronimo.deployment.plugin.local.DistributeCommand.run(DistributeCommand.java:60) at java.lang.Thread.run(Thread.java:797) Caused by: java.lang.IllegalArgumentException: Invalid id: console.dbpool/jdbc/EmployeeDatasource/1.0/rar at org.apache.geronimo.kernel.repository.Artifact.create(Artifact.java:49) at org.apache.geronimo.deployment.Deployer.notifyWatchers(Deployer.java:376) at org.apache.geronimo.deployment.Deployer.deploy(Deployer.java:325) ... 10 more The Portlet should validate that the DB Pool Name does not contain "/" or white space. -- 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] Commented: (GERONIMO-2284) Console DB/JMS and Security Realm naming inconsistent
[ http://issues.apache.org/jira/browse/GERONIMO-2284?page=comments#action_12427957 ] Donald Woods commented on GERONIMO-2284: OK, I'll open a separate JIRA for the portlet not checking for "/" in the user supplied name and rejecting such chars, as they will fail > Console DB/JMS and Security Realm naming inconsistent > - > > Key: GERONIMO-2284 > URL: http://issues.apache.org/jira/browse/GERONIMO-2284 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.1 >Reporter: Aaron Mulder > Fix For: 1.1.x > > > When the console creates a database connection pool or JMS resource, the > module ID has the group "console.dbpool" or "console.jms". However, when it > creates a security realm, the module ID just has the group "console" and the > artifact ID has the prefix "realm-". Instead, the security realm module ID > should have the group "console.realm" and the artifact ID should be the same > as the name the user specified. -- 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
POM Update for Specs...need a few eyeballs
The old pom for the specifications had some old links in it. I have updated the POM with what I think is correct so we can use Maven 2 to release the specs rather than rely on manually doing this. This is the updated POM for the specifications. This will update the branches/1.1 pom.xml Can you take a few minutes to take a look at the proposed pom? You can find it here http://svn.apache.org/repos/asf/geronimo/specs/branches/1_1/pom.xml.proposed I'd like to confirm the scm and dist sections are correct. Any other errors / comments welcome. Thanks!
[jira] Updated: (GERONIMO-2315) On Editing a database pool by changing the database name and restarting it fails to startup
[ http://issues.apache.org/jira/browse/GERONIMO-2315?page=all ] Donald Woods updated GERONIMO-2315: --- Fix Version/s: 1.1.x 1.2 Affects Version/s: 1.1 1.1.1 (was: 1.1.x) > On Editing a database pool by changing the database name and restarting it > fails to startup > --- > > Key: GERONIMO-2315 > URL: http://issues.apache.org/jira/browse/GERONIMO-2315 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.1, 1.1.1 > Environment: All Supported Platforms >Reporter: Manu T George > Fix For: 1.2, 1.1.x > > > Suppose I create an embedded derby Datasource pointing to an embedded DB > TestDB and deploy it.It works w/o any problem. Now from the console if i edit > the datasorce to point to another db and restart it fails with the exception > below > 12:31:32,231 ERROR [Servlet] Exception caught: > javax.portlet.PortletException: Exception > at > org.apache.geronimo.console.configmanager.ConfigManagerPortlet.proces > sAction(ConfigManagerPortlet.java:107) > at > org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229 > ) > at org.apache.pluto.core.PortletServlet.doGet(PortletServlet.java:158) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl > icationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF > ilterChain.java:173) > at > org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp > atcher.java:672) > at > org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationD > ispatcher.java:574) > at > org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDis > patcher.java:499) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvoke > rImpl.java:120) > at > org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvoke > rImpl.java:68) > at > org.apache.pluto.PortletContainerImpl.processPortletAction(PortletCon > tainerImpl.java:164) > at > org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processP > ortletAction(PortletContainerWrapperImpl.java:82) > at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl > icationFilterChain.java:252) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF > ilterChain.java:173) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV > alve.java:213) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextV > alve.java:178) > at > org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSu > bjectValve.java:52) > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica > torBase.java:524) > at > org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve. > invoke(GeronimoStandardContext.java:342) > at > org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(Gero > nimoBeforeAfterValve.java:31) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j > ava:126) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j > ava:105) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal > ve.java:107) > at > org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java: > 541) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav > a:148) > at > org.apache.coyote.http11.Http11Processor.process(Http11Processor.java > :869) > at > org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.p > rocessConnection(Http11BaseProtocol.java:667) > at > org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpo > int.java:527) > at > org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFol > lowerWorkerThread.java:80) > at > org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadP > ool.java:684) > at java.lang.Thread.run(Unknown Source) > Caused by: org.apache.geronimo.kernel.con
[jira] Updated: (GERONIMO-2318) Database path validation not present
[ http://issues.apache.org/jira/browse/GERONIMO-2318?page=all ] Donald Woods updated GERONIMO-2318: --- Fix Version/s: 1.1.x 1.2 Affects Version/s: 1.1 1.1.1 (was: 1.1.x) > Database path validation not present > > > Key: GERONIMO-2318 > URL: http://issues.apache.org/jira/browse/GERONIMO-2318 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.1, 1.1.1 > Environment: All Supported Platforms >Reporter: Manu T George > Fix For: 1.2, 1.1.x > > > On deploying pools referring to derby databases. Deployment is shown to be > sucessful but the pool does not start. > Steps are given below > (1)Logged into Administrative Console. > (2)Clicked "Database Pools". > (3) Next, clicked "Create a new database pool: Using the Geronimo database > pool wizard". > (4)Entered Name of Database Pool: CPRO and Database Type: Derby Embedded. > Then clicked Next. > (5)Thereafter entered the following:- > JDBC Driver Class: org.apache.derby.jdbc.EmbeddedDriver > Driver JAR: org.apache.derby/derby/10.1.2.ibm/jar > DB Username: cpro > DB Password: cpro > Database: c:\cprodb\cprodb_COSMO\csdb > Then clicked Next. > (5)The next screen showed:- > JDBC Connection URL: jdbc:derby:c:cprodbcprodb_COSMOcsdb (This being > incorrect, it was changed to jdbc:derby:c:\cprodb\cprodb_COSMO\csdb). > (6)Driver Status: Loaded successfully > (7)Now clicked "Test Connection". This showed:- > Test Result: Connected to Apache Derby 10.1.2.4 > (8)Finally clicked "Deploy" It appears that this step was successful > because:- > (i)The DOS window showed "Deployment completed successfully!" > Even though this happens when we refer to this DB Pool in an application > error occurs. > Thus there is no handling of '\' character in these two fields > Giving '/' instead of '\' solves this issue -- 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] Commented: (SM-228) Get back http parameters as inMessage.properties in a POST request.
[ https://issues.apache.org/activemq/browse/SM-228?page=comments#action_36779 ] Guillaume Nodet commented on SM-228: The bug is about parameters on the http uri, such as http://localhost:8080/?param=value These parameters are put in properties for non POST http requests. The problem with POST requests is that when the content type is application/x-www-form-urlencoded (which is usually the case), the content of the post request is also read to decode form parameters. This lead to error when using the stream as an xml. I think we could have both behaviors by adding a flag to control that. You can also access the request uri which is put in a map with all cgi headers. > Get back http parameters as inMessage.properties in a POST request. > --- > > Key: SM-228 > URL: https://issues.apache.org/activemq/browse/SM-228 > Project: ServiceMix > Issue Type: Improvement > Components: servicemix-components >Affects Versions: 3.0-M1, 2.0.1, 2.0.2, 2.0.3 > Environment: All >Reporter: Angel Gomez >Priority: Minor > Attachments: HttpMarshaler.java > > > To have the parameters of an Http Post Request available in inMessage. > This behavior was present in version 1.0 and changed in a latter version ( > 2.0.2 + ) from a change in HttpMarshaller. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: SM-228 and URL parameters
The bug is about parameters on the http uri, such as http://localhost:8080/?param=value These parameters are put in properties for non POST http requests. The problem with POST requests is that when the content type is application/x-www-form-urlencoded (which is usually the case), the content of the post request is also read to decode form parameters. This lead to error when using the stream as an xml. I think we could have both behaviors by adding a flag to control that. You can also access the request uri which is put in a map with all cgi headers. On 8/14/06, bruce76 <[EMAIL PROTECTED]> wrote: Hi, Does anyone know the status of SM-228? I see that HttpMarshaler will take the request and put the values in the NormalizedMessage as setProperty(). Is there any reason why the bug is still open? Thanks, Bruce -- View this message in context: http://www.nabble.com/SM-228-and-URL-parameters-tf2104691.html#a5800707 Sent from the ServiceMix - Dev forum at Nabble.com. -- Cheers, Guillaume Nodet
Re: [WELCOME] Please welcome Alan Cabrera as the newest member of the Geronimo PMC
Congratulations !On 8/14/06, David Blevins <[EMAIL PROTECTED]> wrote: Congrats Alan!-DavidOn Aug 14, 2006, at 11:14 AM, Matt Hogstrom wrote:> The Apache Geronimo PMC would like to let everyone know that Alan> Cabrera has accepted the invitation to join the Geronimo PMC. We > are excited to have Alan assisting with project oversight in> addition to his technical contributions to Geronimo.>> Alan has been active in Geronimo for many years and has helped not> only to help in Geronimo directly but in related efforts like Ode, > Yoko and others.>> Give it up for Alan :)>> The Apache Geronimo PMC>-- Cheers,Guillaume Nodet
Re: [WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC
welcome Matt Hogstrom wrote: > The Apache Geronimo PMC would like to let everyone know that Alan > Cabrera has accepted the invitation to join the Geronimo PMC. We are > excited to have Alan assisting with project oversight in addition to his > technical contributions to Geronimo. > > Alan has been active in Geronimo for many years and has helped not only > to help in Geronimo directly but in related efforts like Ode, Yoko and > others. > > Give it up for Alan :) > > The Apache Geronimo PMC > >
[jira] Updated: (GERONIMODEVTOOLS-42) Use gzipped archives on Unice
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-42?page=all ] Sachin Patel updated GERONIMODEVTOOLS-42: - Fix Version/s: (was: 1.x) Affects Version/s: 1.1.0 Priority: Minor (was: Trivial) This requires the following bugzilla in Eclipse-WTP: https://bugs.eclipse.org/bugs/show_bug.cgi?id=153800 >From a geronimo perspective, either another data entry with an os attribute >needs to be created or an additional feature for the tar.gz distributions. > Use gzipped archives on Unice > - > > Key: GERONIMODEVTOOLS-42 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-42 > Project: Geronimo-Devtools > Issue Type: Improvement > Components: eclipse-plugin >Affects Versions: 1.1.0 > Environment: Environment: Eclipse: 3.1.1 (Build ID: M20050929-0840) > Java 2 SE: 1.4.2_10-b03 > OS: Linux ubuntu-abysssix 2.6.12-10-686-smp >Reporter: Daniel S. Haischt >Priority: Minor > > Would it be possible to use a gzipped archive on a Unice OS? I for instance > did download geronimo-jetty.(tgz|tar.gz). Unfortunatly maven searches for a > ZIP and tries to download it because it is non-existant. > + > | Executing jar:install org.apache.geronimo.j2ee.server.v1 > | Memory: 8M/11M > + > DEPRECATED: the default goal should be specified in the section of > project.xml instead of maven.xml > DEPRECATED: the default goal should be specified in the section of > project.xml instead of maven.xml > build:end: > build:start: > java:prepare-filesystem: > java:compile: > [echo] Compiling to > /home/haischt/geronimo-eclipse-tools/plugins/org.apache.geronimo.j2ee.server.v1/target/classes > [echo] No java source files to compile. > java:jar-resources: > getzip: > [get] Getting: > http://www.apache.org/dist/geronimo/1.0/geronimo-jetty-j2ee-1.0.zip > [get] To: > /home/haischt/.maven/repository/geronimo/distributions/geronimo-jetty-j2ee-1.0.zip -- 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: [WELCOME] Please welcome Alan Cabrera as the newest member of the Geronimo PMC
Congrats Alan! -David On Aug 14, 2006, at 11:14 AM, Matt Hogstrom wrote: The Apache Geronimo PMC would like to let everyone know that Alan Cabrera has accepted the invitation to join the Geronimo PMC. We are excited to have Alan assisting with project oversight in addition to his technical contributions to Geronimo. Alan has been active in Geronimo for many years and has helped not only to help in Geronimo directly but in related efforts like Ode, Yoko and others. Give it up for Alan :) The Apache Geronimo PMC
Re: [WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC
Congrats Alan! Matt Hogstrom wrote: > The Apache Geronimo PMC would like to let everyone know that Alan > Cabrera has accepted the invitation to join the Geronimo PMC. We are > excited to have Alan assisting with project oversight in addition to his > technical contributions to Geronimo. > > Alan has been active in Geronimo for many years and has helped not only > to help in Geronimo directly but in related efforts like Ode, Yoko and > others. > > Give it up for Alan :) > > The Apache Geronimo PMC
Re: [WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC
Congratulations Alan ! Cheers Prasad On 8/14/06, Hernan Cunico <[EMAIL PROTECTED]> wrote: Congrats Alan! Cheers! Hernan Matt Hogstrom wrote: > The Apache Geronimo PMC would like to let everyone know that Alan > Cabrera has accepted the invitation to join the Geronimo PMC. We are > excited to have Alan assisting with project oversight in addition to his > technical contributions to Geronimo. > > Alan has been active in Geronimo for many years and has helped not only > to help in Geronimo directly but in related efforts like Ode, Yoko and > others. > > Give it up for Alan :) > > The Apache Geronimo PMC >
Re: [WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC
Congrats Alan! Cheers! Hernan Matt Hogstrom wrote: The Apache Geronimo PMC would like to let everyone know that Alan Cabrera has accepted the invitation to join the Geronimo PMC. We are excited to have Alan assisting with project oversight in addition to his technical contributions to Geronimo. Alan has been active in Geronimo for many years and has helped not only to help in Geronimo directly but in related efforts like Ode, Yoko and others. Give it up for Alan :) The Apache Geronimo PMC
Re: [WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC
Congrats Alan! On 8/14/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: The Apache Geronimo PMC would like to let everyone know that Alan Cabrera has accepted the invitation to join the Geronimo PMC. We are excited to have Alan assisting with project oversight in addition to his technical contributions to Geronimo. Alan has been active in Geronimo for many years and has helped not only to help in Geronimo directly but in related efforts like Ode, Yoko and others. Give it up for Alan :) The Apache Geronimo PMC
[WELCOME] Please welcome alan Cabrera as the newest member of the Geronimo PMC
The Apache Geronimo PMC would like to let everyone know that Alan Cabrera has accepted the invitation to join the Geronimo PMC. We are excited to have Alan assisting with project oversight in addition to his technical contributions to Geronimo. Alan has been active in Geronimo for many years and has helped not only to help in Geronimo directly but in related efforts like Ode, Yoko and others. Give it up for Alan :) The Apache Geronimo PMC
Re: Console JACC Security Error in 1.1.1
I'll look into this. Regards, Alan Aaron Mulder wrote: I'm not sure if this is related to the recent web app security fix or not. I hacked the build enough that I got the 1.1.1 server running. I went to the console, went to the database pool screen, selected that I wanted to create a new pool, filled out the name and DB type on that screen and hit submit, and got the error below. I have no idea why it only came up on that submission and not any of the previous ones (though it was the first POST request I think). Thanks, Aaron 18:19:51,940 WARN [/console] /console/portal/services/services_jdbc/_rp_services_jdbc_row1_col1_p1_adapterDisplayName/1_TranQL0x8Generic0x8JDBC0x8Resource0x8Adapter/_rp_services_jdbc_row1_col1_p1_rarPath/1_tranql0x3tranql-connector0x310x220x3rar/_rp_services_jdbc_row1_col1_p1_mode/1_params/_rp_services_jdbc_row1_col1_p1_driverClass/1_com0x2mysql0x2jdbc0x2Driver/_pm_services_jdbc_row1_col1_p1/view/_rp_services_jdbc_row1_col1_p1_dbtype/1_MySQL/_rp_services_jdbc_row1_col1_p1_urlPrototype/1_jdbc%3Amysql%3A0x30x3%7BHost%7D%3A%7BPort%7D0x3%7BDatabase%7D/_st_services_jdbc_row1_col1_p1/normal/_ps_services_jdbc_row1_col1_p1/normal/_pid/services_jdbc_row1_col1_p1/_md_services_jdbc_row1_col1_p1/view/_rp_services_jdbc_row1_col1_p1_name/1_JPAPool: java.lang.IllegalArgumentException: Qualifier patterns must be present when first URLPattern is an exact pattern at javax.security.jacc.URLPatternSpec.(URLPatternSpec.java:98) at javax.security.jacc.WebUserDataPermission.(WebUserDataPermission.java:83) at org.apache.geronimo.jetty.interceptor.SecurityContextBeforeAfter.checkSecurityConstraints(SecurityContextBeforeAfter.java:194) at org.apache.geronimo.jetty.JettyWebAppContext.checkSecurityConstraints(JettyWebAppContext.java:607) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:432) at org.apache.geronimo.jetty.JettyWebApplicationHandler.dispatch(JettyWebApplicationHandler.java:58) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
Re: XBean and QDox
James Strachan wrote: On 8/13/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: It seems that nobody work on QDox since several months. (see http://www.nabble.com/Anyone-developing-QDox--tf705135r1.html) Does anyone know of any replacement we could use to allow java 5 parsing ? I was thinking of introducing real annotations, but this would make xbean-spring JDK 5 specific. Any thoughts ? We could compile the source with Java 5, use source-only annotations maybe - then generate Java 1.4 compliant code via retrotranslator. Can I debug retrotranslated code in JDK14? Regards, Alan
SM-228 and URL parameters
Hi, Does anyone know the status of SM-228? I see that HttpMarshaler will take the request and put the values in the NormalizedMessage as setProperty(). Is there any reason why the bug is still open? Thanks, Bruce -- View this message in context: http://www.nabble.com/SM-228-and-URL-parameters-tf2104691.html#a5800707 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: JPA plugin (was Re: Java 1.4 and JEE 5)
On Aug 12, 2006, at 2:52 PM, David Blevins wrote: Seems like I'm walking in mid-conversation, but I hope I can add some details. Geez, I just had *seven* missing emails in this thread show up in my mailbox. Not sure what's going on with the mail, but that explains the strange gaps. -David
Re: AJAX and Geronimo
Chris, Thanks for offering to help. Since you've already got a
working Geronimo webapp that uses Dojo in GERONIMO-1823 I would love
to see how this idea holds up. How about moving the Dojo library from
your webapp into separate webapp available at the context root "/dojo"
and then adjusting your webapp to point at it? Depending on how you
referenced Dojo in your scripts and html you may have to include a
line like:
dojo.setModulePrefix("dojo", "/dojo");
after you load dojo.js. I also figured out a way to dynamically load
dojo.js from a javascript file (instead of html) if you that would
help.
To start the Dojo webapp and make its resources available you would
also need to add a line to your webapps geronimo-web.xml like
dojo
dojo-toolkit
war
Does that sound reasonable? Feel free to take this idea and run with
it, get creative, etc :-)
Best wishes,
Paul
On 8/14/06, Chris Cardona <[EMAIL PROTECTED]> wrote:
This is a good idea Paul. I'm not exactly sure how you
would implement it but let me know if I can help with
anything (testing, dev, docs, etc.). This will
definitely help those who wanted to develop Ajax
enabled apps in G. Also nice to have is if we can find
a way to do the same thing for DWR if it's possible.
Cheers,
chris
--- Paul McMahan <[EMAIL PROTECTED]> wrote:
> Dojo is a popular open source AJAX library that's
> available under the
> BSD and Academic Free licenses. The DayTrader folks
> use it in the web
> UI they recently announced on the Geronimo dev list
> and Chris used it
> in the nice LDAP UI he did for GERONIMO-1823. I
> would also like to
> start introducing some use of it into the Geronimo
> admin console when
> its appropriate to do so.
>
> The way that developers usually incorporate an AJAX
> library into their
> applications is by making a copy of its static files
> (javascript, css,
> gifs, etc) in their webapp and referencing them from
> their servlets
> and JSPs. The obvious downside is that each
> application has a
> separate copy of the AJAX library, increasing the
> server's overall
> disk footprint (Dojo is ~3mb) and preventing the
> browser from using a
> single copy of the library files from its cache.
> Another downside is
> that the AJAX library can't be upgraded
> independently from the web
> application.
>
> I think it would be great if Geronimo could provide
> a more AJAX
> friendly development environment by helping solve
> these problems. One
> idea is that Geronimo could include the Dojo library
> as a native,
> standalone webapp with its AJAX library files laid
> out so that other
> applications can point at from their HTML.
> Referencing it in
> geronimo-web.xml would cause Geronimo to start it up
> and make its
> files available at some predetermined context root,
> say /dojo.
> Referencing it with a versionless moduleId would
> make sure the most
> recent version is always used. So AJAX enabling
> your application in
> Geronimo would be a simple as "add this line to your
> geronimo-web.xml".
>
> Does this sound like a good idea? Any suggestions
> or concerns?
> Perhaps this could be done as a plugin instead of a
> native module?
>
> Best wishes,
> Paul
>
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: AJAX and Geronimo
Yep you nailed it. Dojo contains some optional stuff for server communication that I haven't played with much but its not directly tied to its core value, which is to make things wiggle. Chris's LDAP viewer (GERONIMO-1823) is a perfect example where Dojo is used for the UI and DWR is used for the server comm. Best wishes, Paul On 8/14/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: OK, so if I understand this right DWR provides the ability to invoke server-side Java APIs and translate arguments and return types between JavaScript and Java. Whereas Dojo provided more graphical bells and whistles like the ability to manipulate the page DOM, but only on the client side. So you might use an app-specific DWR transport to call something on the server, and then hand off the response to the shared Dojo scripts to create some new content on the screen and make it wiggle or something. Is that about right? Thanks, Aaron On 8/14/06, Paul McMahan <[EMAIL PROTECTED]> wrote: > Aaron, You're correct that this approach wouldn't work for DWR (at > least not in a straightforward way) since DWR uses server side classes > that need classloader access to the webapp. But Dojo is different in > that it is really just a collection of static resources (javascript, > css, images, etc) and does not require any server side communication > or even java for that matter. Developers typically just extract all > the Dojo resources into their webapp and load them into the browser > via references in their HTML. > > As a matter of fact Dojo and DWR are quite complimentary to each other > since Dojo provides UI controls and DWR provides server communication. > As you know, Geronimo already provides DWR as a jar in the repository > that can be shared between webapps and versioned separately from the > applications that use it. Providing this same type of functionality > for Dojo is a little more unnatural since its composed of static > resources instead of java class files. But I'm thinking that making > the Dojo resources available in a native webapp at a predetermined > context provides equivalent functionality except for one limitation: > multiple versions of the webapp can not run simultaneously when they > use the same context root. IMHO that limitation is acceptable since a > large number of use cases are still supported. > > Best wishes, > Paul > > > > On 8/11/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: > > I'm not sure what you're planning to do with AJAX, but wouldn't Dojo > > need access to classes in the web app? At least, when we use DWR, we > > point it to server-side classes and APIs and it automagically > > generates JavaScript wrappers for those. If so, I'm not sure it would > > work to have Dojo deployed at a static location like /dojo in a > > standalone web app, because I'm not sure how it would see the > > user-specific classes. Maybe some ThreadContextClassLoader magic? > > > > Thanks, > > Aaron > > > > On 8/11/06, Paul McMahan <[EMAIL PROTECTED]> wrote: > > > Dojo is a popular open source AJAX library that's available under the > > > BSD and Academic Free licenses. The DayTrader folks use it in the web > > > UI they recently announced on the Geronimo dev list and Chris used it > > > in the nice LDAP UI he did for GERONIMO-1823. I would also like to > > > start introducing some use of it into the Geronimo admin console when > > > its appropriate to do so. > > > > > > The way that developers usually incorporate an AJAX library into their > > > applications is by making a copy of its static files (javascript, css, > > > gifs, etc) in their webapp and referencing them from their servlets > > > and JSPs. The obvious downside is that each application has a > > > separate copy of the AJAX library, increasing the server's overall > > > disk footprint (Dojo is ~3mb) and preventing the browser from using a > > > single copy of the library files from its cache. Another downside is > > > that the AJAX library can't be upgraded independently from the web > > > application. > > > > > > I think it would be great if Geronimo could provide a more AJAX > > > friendly development environment by helping solve these problems. One > > > idea is that Geronimo could include the Dojo library as a native, > > > standalone webapp with its AJAX library files laid out so that other > > > applications can point at from their HTML. Referencing it in > > > geronimo-web.xml would cause Geronimo to start it up and make its > > > files available at some predetermined context root, say /dojo. > > > Referencing it with a versionless moduleId would make sure the most > > > recent version is always used. So AJAX enabling your application in > > > Geronimo would be a simple as "add this line to your > > > geronimo-web.xml". > > > > > > Does this sound like a good idea? Any suggestions or concerns? > > > Perhaps this could be done as a plugin instead of a native module? > > > > > > Best wishes, > > > Paul > > > > > >
Re: AJAX and Geronimo
Matt, yes there will certainly be frequent new versions of Dojo to fix bugs, broaden browser compatibility, improve performance and security, etc. I think if Dojo maintains a decent reputation for maintaining backwards compatibility that developers will want their webapp to use the "server provided version" (which they may need to upgrade using Geronimo's standard deployment mechanisms). However, when a developer has hacked their Dojo library or just needs an extra boost of certainty about their runtime env they can certainly still include a private copy in their webapp instead of referencing the server copy. To me the question of which approach a developer would want to take (private vs shared version) is analogous to deciding whether or not a deployment plan should include a version number in its gbean references (and none of the Geronimo configurations or assemblies do, AFAIK). Best wishes, Paul On 8/12/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: How about versioning of the Dojo libraries over time? I haven't played with the AJAX stuff really but I assume we'll be seeing new versions, etc. over time where different applications would be looking for different levels of the dojo libraries. So the goal would be use our "server provided version" and override it in your app if you need a newer one? Paul McMahan wrote: > Dojo is a popular open source AJAX library that's available under the > BSD and Academic Free licenses. The DayTrader folks use it in the web > UI they recently announced on the Geronimo dev list and Chris used it > in the nice LDAP UI he did for GERONIMO-1823. I would also like to > start introducing some use of it into the Geronimo admin console when > its appropriate to do so. > > The way that developers usually incorporate an AJAX library into their > applications is by making a copy of its static files (javascript, css, > gifs, etc) in their webapp and referencing them from their servlets > and JSPs. The obvious downside is that each application has a > separate copy of the AJAX library, increasing the server's overall > disk footprint (Dojo is ~3mb) and preventing the browser from using a > single copy of the library files from its cache. Another downside is > that the AJAX library can't be upgraded independently from the web > application. > > I think it would be great if Geronimo could provide a more AJAX > friendly development environment by helping solve these problems. One > idea is that Geronimo could include the Dojo library as a native, > standalone webapp with its AJAX library files laid out so that other > applications can point at from their HTML. Referencing it in > geronimo-web.xml would cause Geronimo to start it up and make its > files available at some predetermined context root, say /dojo. > Referencing it with a versionless moduleId would make sure the most > recent version is always used. So AJAX enabling your application in > Geronimo would be a simple as "add this line to your > geronimo-web.xml". > > Does this sound like a good idea? Any suggestions or concerns? > Perhaps this could be done as a plugin instead of a native module? > > Best wishes, > Paul > > >
Re: JPA Plugin Status
Excellent! Aaron Mulder wrote: > OK, now it should work if you don't set up a provider but just bundle > all the needed stuff in your WAR or set up your dependencies right. > I'd still prefer to use the provider registry for the ones we know of, > since then we can let you manage them in the console, perhaps support > default properties to be applied to all apps for that provider, etc. > > Thanks, >Aaron > > On 8/14/06, Jeff Genender <[EMAIL PROTECTED]> wrote: >> Aaron, >> >> Why do you need to have vendor code? Why can't this be a bit more >> dynamic? Long term, I think its a bad idea to have to declare a vendor >> wrapped API when our competitors just need to dump the provider jars in >> a directory somewhere or include them in a deployment. Basically, >> anyone who wants to use a provider that we haven't supported has to >> write vendor G-only code...right? If this is the case, I think that is >> a bit burdensome. Thoughts? >> >> Jeff >> >> Aaron Mulder wrote: >> > The code for the app-managed-JPA-for-web-apps plugin is up at SVN >> > https://svn.sourceforge.net/svnroot/gplugins/jpa/trunk >> > >> > So far, it's just got a TopLink provider, but if people want to copy >> > that to create providers for Cayenne or OpenJPA or whatever, that >> > would be great. It basically just needs to have a customized name and >> > ClassPath, though I'm assuming any provider we integrate with will be >> > compatible with the Geronimo JPA spec JAR (currently >> > org.apache.geronimo.specs/geronimo-jpa_3.0_spec/1.0-SNAPSHOT/jar) >> > >> > If you try to build and run this, you'll be held up by a couple things: >> > * It needs the latest car-maven-plugin, and I'm not sure whether >> > Jason has pushed a fresh snapshot since the last changes to it >> > * It needs Geronimo 1.1 CARs in the M2 repo, and Matt has said >> > posting those is on his to-do list >> > * It only runs in Geronimo 1.1.1 due to reference resolution bugs in >> > G 1.1, and currently the G 1.1.1 build is broken >> > >> > But if you get past all that (or comment out the plugins child from >> > the main POM to avoid the first two issues) and run your server under >> > Java 5, you can deploy web apps using JPA. :) >> > >> > My goal is to have a release of this plugin with sufficient user >> > documentation when G 1.1.1 is released. It would be great to have >> > some open source JPA providers for that release too. >> > >> > I also started talking to David B about the JPA work being done in >> > OpenEJB, and I think we're agreed that we probably don't need two such >> > plugins for G 1.1.x, so hopefully we can work toward a unification as >> > we move forward. >> > >> > Thanks, >> > Aaron >>
[jira] Resolved: (AMQ-848) Consolidate all LICENSE files to a single file.
[ https://issues.apache.org/activemq/browse/AMQ-848?page=all ] Hiram Chirino resolved AMQ-848. --- Fix Version/s: 4.0.2 Resolution: Fixed > Consolidate all LICENSE files to a single file. > --- > > Key: AMQ-848 > URL: https://issues.apache.org/activemq/browse/AMQ-848 > Project: ActiveMQ > Issue Type: Improvement >Affects Versions: 4.0.2 >Reporter: Hiram Chirino > Assigned To: Hiram Chirino > Fix For: 4.1, 4.0.2 > > > For an example see: > http://www.apache.org/dev/release.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: JPA Plugin Status
OK, now it should work if you don't set up a provider but just bundle all the needed stuff in your WAR or set up your dependencies right. I'd still prefer to use the provider registry for the ones we know of, since then we can let you manage them in the console, perhaps support default properties to be applied to all apps for that provider, etc. Thanks, Aaron On 8/14/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Aaron, Why do you need to have vendor code? Why can't this be a bit more dynamic? Long term, I think its a bad idea to have to declare a vendor wrapped API when our competitors just need to dump the provider jars in a directory somewhere or include them in a deployment. Basically, anyone who wants to use a provider that we haven't supported has to write vendor G-only code...right? If this is the case, I think that is a bit burdensome. Thoughts? Jeff Aaron Mulder wrote: > The code for the app-managed-JPA-for-web-apps plugin is up at SVN > https://svn.sourceforge.net/svnroot/gplugins/jpa/trunk > > So far, it's just got a TopLink provider, but if people want to copy > that to create providers for Cayenne or OpenJPA or whatever, that > would be great. It basically just needs to have a customized name and > ClassPath, though I'm assuming any provider we integrate with will be > compatible with the Geronimo JPA spec JAR (currently > org.apache.geronimo.specs/geronimo-jpa_3.0_spec/1.0-SNAPSHOT/jar) > > If you try to build and run this, you'll be held up by a couple things: > * It needs the latest car-maven-plugin, and I'm not sure whether > Jason has pushed a fresh snapshot since the last changes to it > * It needs Geronimo 1.1 CARs in the M2 repo, and Matt has said > posting those is on his to-do list > * It only runs in Geronimo 1.1.1 due to reference resolution bugs in > G 1.1, and currently the G 1.1.1 build is broken > > But if you get past all that (or comment out the plugins child from > the main POM to avoid the first two issues) and run your server under > Java 5, you can deploy web apps using JPA. :) > > My goal is to have a release of this plugin with sufficient user > documentation when G 1.1.1 is released. It would be great to have > some open source JPA providers for that release too. > > I also started talking to David B about the JPA work being done in > OpenEJB, and I think we're agreed that we probably don't need two such > plugins for G 1.1.x, so hopefully we can work toward a unification as > we move forward. > > Thanks, > Aaron
Re: Deadlock on 4.0.2
I just applied the simple fix of enabling the setter in in the 4.0 branch. If anybody feels strongly that we need to fix the naming inconsistencies in that branch too open a jira an we'll consider it. On 8/11/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: Yep it's been fixed in 4.1 but not in the 4.0 branch yet. The commit that fixed this was revision 418966: http://mail-archives.apache.org/mod_mbox/geronimo-activemq-commits/200607.mbox/[EMAIL PROTECTED] It's also got an issue: http://issues.apache.org/activemq/browse/AMQ-792 I wonder what you guys think about porting this fix to the 4.0 branch? Since it does slightly change the API (to make it consistent) it could break folks that are calling this method directly so on one hand we should not make that kind of change to the 4.0 branch. The inconstancy of the naming is a bug IMO so I think we should fix it. On 8/11/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > Btw, the docs on http://www.activemq.org/site/consumer-dispatch-async.html > refer to dispatchAsync but the code uses asyncDispatch. > I guess this is an oversight, right ? > > On 8/11/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > > > > I think that if we enable async dispatch this issue should go away. > > This would only affect vm transport since the transport oneways. We > > should look into making async to be dispatch be the default when using > > the vm transport. > > > > On 8/11/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: > > > I sometime have deadlocks while running junit tests that involve > > ActiveMQ. > > > Following is a stack trace i dumped. > > > As you can see, the two last threads are deadlocked because of the > > > MutexTransport. > > > This cause the first thread (main thread) to hang forever. > > > > > > Thread [main] (Suspended) > > > MutexTransport.oneway(Command) line: 44 > > > ==> MutexTransport (id=292) > > > ResponseCorrelator.oneway(Command) line: 58 > > > > > ManagedTransportConnection(TransportConnection).dispatch(Command) > > > line: 211 > > > > > > ManagedTransportConnection(AbstractConnection).processDispatch(Command) > > > line: 628 > > > > > ManagedTransportConnection(AbstractConnection).dispatchSync(Command) > > > line: 605 > > > TopicSubscription.dispatch(MessageReference) line: 315 > > > TopicSubscription.add(MessageReference) line: 74 > > > SimpleDispatchPolicy.dispatch(ConnectionContext, > > MessageReference, > > > MessageEvaluationContext, List) line: 50 > > > Topic.dispatch(ConnectionContext, Message) line: 443 > > > Topic.send(ConnectionContext, Message) line: 254 > > > ManagedTopicRegion(AbstractRegion).send(ConnectionContext, > > Message) > > > line: 225 > > > ManagedRegionBroker(RegionBroker).send(ConnectionContext, > > Message) > > > line: 345 > > > TransactionBroker.send(ConnectionContext, Message) line: 192 > > > AdvisoryBroker(BrokerFilter).send(ConnectionContext, Message) > > line: > > > 113 > > > CompositeDestinationBroker.send(ConnectionContext, Message) > > line: > > > 97 > > > BrokerService$2(MutableBrokerFilter).send(ConnectionContext, > > > Message) line: 126 > > > > > > ManagedTransportConnection(AbstractConnection).processMessage(Message) > > line: > > > 377 > > > ActiveMQObjectMessage(ActiveMQMessage).visit(CommandVisitor) > > line: > > > 590 > > > ManagedTransportConnection(AbstractConnection).service(Command) > > > line: 226 > > > TransportConnection$1.onCommand(Command) line: 62 > > > ResponseCorrelator.onCommand(Command) line: 91 > > > MutexTransport(TransportFilter).onCommand(Command) line: 63 > > > VMTransportServer$1(VMTransport).oneway(Command) line: 76 > > > MutexTransport.oneway(Command) line: 44 > > > => MutexTransport (id=314) > > > ResponseCorrelator.oneway(Command) line: 58 > > > ActiveMQConnection.asyncSendPacket(Command) line: 1092 > > > ActiveMQSession.send(ActiveMQMessageProducer, > > ActiveMQDestination, > > > Message, int, int, long) line: 1553 > > > ActiveMQMessageProducer.send(Destination, Message, int, int, > > long) > > > line: 462 > > > ActiveMQMessageProducer.send(Message) line: 356 > > > JCAFlow.sendJmsMessage(Destination, Serializable, boolean, > > boolean) > > > line: 707 > > > JCAFlow.onInternalEndpointUnregistered(EndpointEvent, boolean) > > line: > > > 462 > > > JCAFlow$1.internalEndpointUnregistered(EndpointEvent) line: 245 > > > EndpointRegistry.fireEvent(ServiceEndpoint, int) line: 575 > > > EndpointRegistry.unregisterInternalEndpoint(ComponentContext, > > > InternalEndpoint) line: 199 > > > Registry.deactivateEndpoint(ComponentContext, InternalEndpoint) > > > line: 205 > > > ComponentContextImpl.deactivateEndpoint(ServiceEndpoint) line: > > > 157 > > > ReceiverComponent(PojoSupport).shutDown() line: 103 > >
[jira] Updated: (AMQ-792) allow asynchronous dispatch to consumers in the broker for non-durable topics
[ https://issues.apache.org/activemq/browse/AMQ-792?page=all ] Hiram Chirino updated AMQ-792: -- Fix Version/s: 4.0.3 Applied fix to 4.0 branch in revision 431369. > allow asynchronous dispatch to consumers in the broker for non-durable topics > - > > Key: AMQ-792 > URL: https://issues.apache.org/activemq/browse/AMQ-792 > Project: ActiveMQ > Issue Type: Improvement > Components: Broker >Reporter: james strachan > Fix For: 4.1, 4.0.3 > > > We typically use the current thread in the broker to dispatch to all the > available non-durable consumers for performance - as this hugely reduces the > context switching and increases performance. However (see AMQ-688) sometimes > this can cause one dead consumer to block a producer. > Some folks may want to switch this strategy to use slower asynchronous > dispatch with a thread pool to reduce the risk of blocking a producer at the > expensive of lower performance -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: AJAX and Geronimo
OK, so if I understand this right DWR provides the ability to invoke server-side Java APIs and translate arguments and return types between JavaScript and Java. Whereas Dojo provided more graphical bells and whistles like the ability to manipulate the page DOM, but only on the client side. So you might use an app-specific DWR transport to call something on the server, and then hand off the response to the shared Dojo scripts to create some new content on the screen and make it wiggle or something. Is that about right? Thanks, Aaron On 8/14/06, Paul McMahan <[EMAIL PROTECTED]> wrote: Aaron, You're correct that this approach wouldn't work for DWR (at least not in a straightforward way) since DWR uses server side classes that need classloader access to the webapp. But Dojo is different in that it is really just a collection of static resources (javascript, css, images, etc) and does not require any server side communication or even java for that matter. Developers typically just extract all the Dojo resources into their webapp and load them into the browser via references in their HTML. As a matter of fact Dojo and DWR are quite complimentary to each other since Dojo provides UI controls and DWR provides server communication. As you know, Geronimo already provides DWR as a jar in the repository that can be shared between webapps and versioned separately from the applications that use it. Providing this same type of functionality for Dojo is a little more unnatural since its composed of static resources instead of java class files. But I'm thinking that making the Dojo resources available in a native webapp at a predetermined context provides equivalent functionality except for one limitation: multiple versions of the webapp can not run simultaneously when they use the same context root. IMHO that limitation is acceptable since a large number of use cases are still supported. Best wishes, Paul On 8/11/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: > I'm not sure what you're planning to do with AJAX, but wouldn't Dojo > need access to classes in the web app? At least, when we use DWR, we > point it to server-side classes and APIs and it automagically > generates JavaScript wrappers for those. If so, I'm not sure it would > work to have Dojo deployed at a static location like /dojo in a > standalone web app, because I'm not sure how it would see the > user-specific classes. Maybe some ThreadContextClassLoader magic? > > Thanks, > Aaron > > On 8/11/06, Paul McMahan <[EMAIL PROTECTED]> wrote: > > Dojo is a popular open source AJAX library that's available under the > > BSD and Academic Free licenses. The DayTrader folks use it in the web > > UI they recently announced on the Geronimo dev list and Chris used it > > in the nice LDAP UI he did for GERONIMO-1823. I would also like to > > start introducing some use of it into the Geronimo admin console when > > its appropriate to do so. > > > > The way that developers usually incorporate an AJAX library into their > > applications is by making a copy of its static files (javascript, css, > > gifs, etc) in their webapp and referencing them from their servlets > > and JSPs. The obvious downside is that each application has a > > separate copy of the AJAX library, increasing the server's overall > > disk footprint (Dojo is ~3mb) and preventing the browser from using a > > single copy of the library files from its cache. Another downside is > > that the AJAX library can't be upgraded independently from the web > > application. > > > > I think it would be great if Geronimo could provide a more AJAX > > friendly development environment by helping solve these problems. One > > idea is that Geronimo could include the Dojo library as a native, > > standalone webapp with its AJAX library files laid out so that other > > applications can point at from their HTML. Referencing it in > > geronimo-web.xml would cause Geronimo to start it up and make its > > files available at some predetermined context root, say /dojo. > > Referencing it with a versionless moduleId would make sure the most > > recent version is always used. So AJAX enabling your application in > > Geronimo would be a simple as "add this line to your > > geronimo-web.xml". > > > > Does this sound like a good idea? Any suggestions or concerns? > > Perhaps this could be done as a plugin instead of a native module? > > > > Best wishes, > > Paul > > >
Patches in RTC (Geronimo - 2006-08-14)
Geronimo - Monday, August 14, 2006 7 Patches in RTC [XBEAN-19] [RTC] Enable inverse classloading with the classpath element - Assignee: Guillaume Nodet - Reporter: Guillaume Nodet - Created: Fri Jun 16 14:13:24 PDT 2006 - Updated: Wed Aug 09 10:30:04 PDT 2006 - Votes: 4 1 Dain Sundstrom 2 David Blevins 3 Jeff Genender 4 Matt Hogstrom - http://issues.apache.org/jira/browse/XBEAN-19 [GERONIMO-2015] Let's replace JKS to PKCS12 key store type - Assignee: Unassigned - Reporter: Nikolay Chugunov - Created: Fri May 12 14:54:17 PDT 2006 - Updated: Thu Aug 10 10:59:06 PDT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2015 [GERONIMO-1563] [RTC] Make the JACC implementation pluggable - Assignee: David Jencks - Reporter: David Jencks - Created: Wed Feb 01 02:26:12 PST 2006 - Updated: Wed Aug 09 12:11:15 PDT 2006 - Votes: 5 1 Alan Cabrera 2 Donald Woods 3 Gianny Damour 4 Jeff Genender 5 Matt Hogstrom - http://issues.apache.org/jira/browse/GERONIMO-1563 [GERONIMO-2163] WADI Integration for Jetty - Assignee: Gianny Damour - Reporter: Gianny Damour - Created: Sun Jul 02 14:16:35 PDT 2006 - Updated: Fri Aug 04 12:03:16 PDT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2163 [XBEAN-33] [RTC] Add a new Wiki source generator that generates wiki markup so that reference docs can be pasted into confluence. - Assignee: Hiram Chirino - Reporter: Hiram Chirino - Created: Tue Aug 01 13:03:57 PDT 2006 - Updated: Wed Aug 09 15:58:47 PDT 2006 - Votes: 5 1 Dain Sundstrom 2 David Blevins 3 Guillaume Nodet 4 Jeff Genender 5 Matt Hogstrom - http://issues.apache.org/jira/browse/XBEAN-33 [XBEAN-31] [RTC] it would be great if the m2 plugin would automatically add the XSD and .xsd.html files as artifacts into the build - Assignee: Guillaume Nodet - Reporter: james strachan - Created: Tue Aug 01 03:37:03 PDT 2006 - Updated: Wed Aug 09 11:54:28 PDT 2006 - Votes: 5 1 Dain Sundstrom 2 David Jencks 3 Guillaume Nodet 4 Jeff Genender 5 Matt Hogstrom - http://issues.apache.org/jira/browse/XBEAN-31 [GERONIMO-2248] Applications portlets: List Parent and Child components against each component - Assignee: Unassigned - Reporter: Vamsavardhana Reddy - Created: Sun Jul 30 08:15:34 PDT 2006 - Updated: Thu Aug 10 12:00:04 PDT 2006 - Votes: 0 - http://issues.apache.org/jira/browse/GERONIMO-2248 NOTE: This email is generated and does not constitute and offical vote or vote result. All official voting is done on the dev list. If you do not see your issue here, click the "Begin RTC Review" link under the "Available Workflow Actions" of the JIRA page. If you do not see your vote here, click the "Vote" link under the "Operations" section of the JIRA page. *** ALL COMMUNITY MEMBERS ARE ENCOURAGED TO VOTE *** Template: http://svn.apache.org/repos/asf/geronimo/gbuild/jirareports/patchesInRtc.vm
Re: AJAX and Geronimo
Aaron, You're correct that this approach wouldn't work for DWR (at least not in a straightforward way) since DWR uses server side classes that need classloader access to the webapp. But Dojo is different in that it is really just a collection of static resources (javascript, css, images, etc) and does not require any server side communication or even java for that matter. Developers typically just extract all the Dojo resources into their webapp and load them into the browser via references in their HTML. As a matter of fact Dojo and DWR are quite complimentary to each other since Dojo provides UI controls and DWR provides server communication. As you know, Geronimo already provides DWR as a jar in the repository that can be shared between webapps and versioned separately from the applications that use it. Providing this same type of functionality for Dojo is a little more unnatural since its composed of static resources instead of java class files. But I'm thinking that making the Dojo resources available in a native webapp at a predetermined context provides equivalent functionality except for one limitation: multiple versions of the webapp can not run simultaneously when they use the same context root. IMHO that limitation is acceptable since a large number of use cases are still supported. Best wishes, Paul On 8/11/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: I'm not sure what you're planning to do with AJAX, but wouldn't Dojo need access to classes in the web app? At least, when we use DWR, we point it to server-side classes and APIs and it automagically generates JavaScript wrappers for those. If so, I'm not sure it would work to have Dojo deployed at a static location like /dojo in a standalone web app, because I'm not sure how it would see the user-specific classes. Maybe some ThreadContextClassLoader magic? Thanks, Aaron On 8/11/06, Paul McMahan <[EMAIL PROTECTED]> wrote: > Dojo is a popular open source AJAX library that's available under the > BSD and Academic Free licenses. The DayTrader folks use it in the web > UI they recently announced on the Geronimo dev list and Chris used it > in the nice LDAP UI he did for GERONIMO-1823. I would also like to > start introducing some use of it into the Geronimo admin console when > its appropriate to do so. > > The way that developers usually incorporate an AJAX library into their > applications is by making a copy of its static files (javascript, css, > gifs, etc) in their webapp and referencing them from their servlets > and JSPs. The obvious downside is that each application has a > separate copy of the AJAX library, increasing the server's overall > disk footprint (Dojo is ~3mb) and preventing the browser from using a > single copy of the library files from its cache. Another downside is > that the AJAX library can't be upgraded independently from the web > application. > > I think it would be great if Geronimo could provide a more AJAX > friendly development environment by helping solve these problems. One > idea is that Geronimo could include the Dojo library as a native, > standalone webapp with its AJAX library files laid out so that other > applications can point at from their HTML. Referencing it in > geronimo-web.xml would cause Geronimo to start it up and make its > files available at some predetermined context root, say /dojo. > Referencing it with a versionless moduleId would make sure the most > recent version is always used. So AJAX enabling your application in > Geronimo would be a simple as "add this line to your > geronimo-web.xml". > > Does this sound like a good idea? Any suggestions or concerns? > Perhaps this could be done as a plugin instead of a native module? > > Best wishes, > Paul >
http-binding sample
I am trying to run the http-binding sample but I am getting http error 301 when I run the sample client using ant. When I tried to access my http://localhost:8912/ via a browser I got http error 401. I asuume it's our company's proxy authentication. Where would I configure any userID password. Thanks -- View this message in context: http://www.nabble.com/http-binding-sample-tf2103846.html#a5798202 Sent from the ServiceMix - Dev forum at Nabble.com.
[jira] Commented: (GERONIMO-2284) Console DB/JMS and Security Realm naming inconsistent
[ http://issues.apache.org/jira/browse/GERONIMO-2284?page=comments#action_12427910 ] Aaron Mulder commented on GERONIMO-2284: Unfortunately, I'm not sure that's realistic given where we are. We currently hide the group/artifact/version/type from the user, and the name they specify becomes the artifact, with a fixed group, version, and type. Because of that, I dont' think we can accept slashes in the name. However, be aware that the point of this issue is to alter the artifact name, which is separate from the DB pool name. When mapping a resource ref you only need the DB pool name (which can be "Daytrader" or "DaytraderJDBC" just not "jdbc/Daytrader"), and for your dependency you can just list artifact=DaytraderJDBC or whatever. So, bottom line, the user should be able to stay unaware of whatever we use as the group name (curently console.dbpool), but the artifact name can't have slashes, so the DB pool name most likely can't have slashes. If it was really desirable we could have an "advanced options" screen to let the user override the group/artifact/version/type so they could leave slashes in the pool name and override the module ID to be something valid, but I don't think this adds a whole lot of value. They can already generate the plan and just add a "jdbc/" to the pool name in the plan. > Console DB/JMS and Security Realm naming inconsistent > - > > Key: GERONIMO-2284 > URL: http://issues.apache.org/jira/browse/GERONIMO-2284 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.1 >Reporter: Aaron Mulder > Fix For: 1.1.x > > > When the console creates a database connection pool or JMS resource, the > module ID has the group "console.dbpool" or "console.jms". However, when it > creates a security realm, the module ID just has the group "console" and the > artifact ID has the prefix "realm-". Instead, the security realm module ID > should have the group "console.realm" and the artifact ID should be the same > as the name the user specified. -- 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: AJAX and Geronimo
Thanks Jeff. One goal is definitely to make the admin console more interactive and user friendly. I'm also hoping we can go one step further in making Geronimo more AJAX friendly as a platform. My suggestion is that we could take a step in that direction by separating the Dojo resources into a native web application where they can be shared by many applications and so AJAX enabled applications can take advantage of Geronimo's gbean capabilities (versioning, deployment, lifecycle controls, etc). These are the basic kinds of luxuries that developers often take for granted with JAR files, and I think AJAX developers would like to take advantage of just as well. Best wishes, Paul On 8/11/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Paul, Yes...this idea has my full support. The more user friendly and better experience of the console only puts us ahead of the game. The few AJAX components we have already (thermometers) has garnered a lot of positive feedback, so the more, the merrier ;-) Jeff Paul McMahan wrote: > Dojo is a popular open source AJAX library that's available under the > BSD and Academic Free licenses. The DayTrader folks use it in the web > UI they recently announced on the Geronimo dev list and Chris used it > in the nice LDAP UI he did for GERONIMO-1823. I would also like to > start introducing some use of it into the Geronimo admin console when > its appropriate to do so. > > The way that developers usually incorporate an AJAX library into their > applications is by making a copy of its static files (javascript, css, > gifs, etc) in their webapp and referencing them from their servlets > and JSPs. The obvious downside is that each application has a > separate copy of the AJAX library, increasing the server's overall > disk footprint (Dojo is ~3mb) and preventing the browser from using a > single copy of the library files from its cache. Another downside is > that the AJAX library can't be upgraded independently from the web > application. > > I think it would be great if Geronimo could provide a more AJAX > friendly development environment by helping solve these problems. One > idea is that Geronimo could include the Dojo library as a native, > standalone webapp with its AJAX library files laid out so that other > applications can point at from their HTML. Referencing it in > geronimo-web.xml would cause Geronimo to start it up and make its > files available at some predetermined context root, say /dojo. > Referencing it with a versionless moduleId would make sure the most > recent version is always used. So AJAX enabling your application in > Geronimo would be a simple as "add this line to your > geronimo-web.xml". > > Does this sound like a good idea? Any suggestions or concerns? > Perhaps this could be done as a plugin instead of a native module? > > Best wishes, > Paul
[jira] Commented: (GERONIMO-2284) Console DB/JMS and Security Realm naming inconsistent
[ http://issues.apache.org/jira/browse/GERONIMO-2284?page=comments#action_12427902 ] Donald Woods commented on GERONIMO-2284: I disagree - the console should not be creating "console.*" specific names. For example, for DB Pools, it should allow users to create jdbc/Daytrader just like they can create from a plan file. > Console DB/JMS and Security Realm naming inconsistent > - > > Key: GERONIMO-2284 > URL: http://issues.apache.org/jira/browse/GERONIMO-2284 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.1 >Reporter: Aaron Mulder > Fix For: 1.1.x > > > When the console creates a database connection pool or JMS resource, the > module ID has the group "console.dbpool" or "console.jms". However, when it > creates a security realm, the module ID just has the group "console" and the > artifact ID has the prefix "realm-". Instead, the security realm module ID > should have the group "console.realm" and the artifact ID should be the same > as the name the user specified. -- 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-2249) Add remote-deploy and hot-deployer to Little G
[ http://issues.apache.org/jira/browse/GERONIMO-2249?page=all ] Donald Woods updated GERONIMO-2249: --- Issue Type: Wish (was: Bug) Fix Version/s: 1.2 (was: 1.1.x) Priority: Minor (was: Major) This is a feature/wish and not a bug Why not allow users who want them to add them via Plugins instead? > Add remote-deploy and hot-deployer to Little G > -- > > Key: GERONIMO-2249 > URL: http://issues.apache.org/jira/browse/GERONIMO-2249 > Project: Geronimo > Issue Type: Wish > Security Level: public(Regular issues) > Components: core >Affects Versions: 1.1 >Reporter: Aaron Mulder >Priority: Minor > Fix For: 1.2 > > > They're both small, quick to start, and have valuable functionality > (especially hot-deployer in light of the Tomcat deployment system). -- 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: AJAX and Geronimo
I definitely agree that browser compatibility is a key issue. Dojo claims compatibility with the following browsers: * IE 5.5+ (limited supported for 5.5, full support for 6.0) * Firefox 1.0+ * Latest Safari (2.0.x today). * Latest Opera (8.5 today, 9.0 soon) * Latest Konqueror (3.5 today) Fortunately, I think our team uses a pretty diversified development env and can help keep us honest (like we recently saw happen on the dev list). Paul On 8/11/06, Jason Dillon <[EMAIL PROTECTED]> wrote: If it all works in Safari and Firefox I'm all for it :-) --jason On Aug 11, 2006, at 2:17 PM, Paul McMahan wrote: > Dojo is a popular open source AJAX library that's available under the > BSD and Academic Free licenses. The DayTrader folks use it in the web > UI they recently announced on the Geronimo dev list and Chris used it > in the nice LDAP UI he did for GERONIMO-1823. I would also like to > start introducing some use of it into the Geronimo admin console when > its appropriate to do so. > > The way that developers usually incorporate an AJAX library into their > applications is by making a copy of its static files (javascript, css, > gifs, etc) in their webapp and referencing them from their servlets > and JSPs. The obvious downside is that each application has a > separate copy of the AJAX library, increasing the server's overall > disk footprint (Dojo is ~3mb) and preventing the browser from using a > single copy of the library files from its cache. Another downside is > that the AJAX library can't be upgraded independently from the web > application. > > I think it would be great if Geronimo could provide a more AJAX > friendly development environment by helping solve these problems. One > idea is that Geronimo could include the Dojo library as a native, > standalone webapp with its AJAX library files laid out so that other > applications can point at from their HTML. Referencing it in > geronimo-web.xml would cause Geronimo to start it up and make its > files available at some predetermined context root, say /dojo. > Referencing it with a versionless moduleId would make sure the most > recent version is always used. So AJAX enabling your application in > Geronimo would be a simple as "add this line to your > geronimo-web.xml". > > Does this sound like a good idea? Any suggestions or concerns? > Perhaps this could be done as a plugin instead of a native module? > > Best wishes, > Paul
[jira] Commented: (AMQ-771) org.apache.activemq.broker.TransportConnection::stop should not attempt to send a message over the connection.
[ https://issues.apache.org/activemq/browse/AMQ-771?page=comments#action_36777 ] Kevin Yaussy commented on AMQ-771: -- Rob, This issue is a bit more complex than I've noted above. I've been out for a week, but prior to leaving I got a version (based upon 4.0.1) working. I will submit comments and patches sometime today, hopefully. > org.apache.activemq.broker.TransportConnection::stop should not attempt to > send a message over the connection. > -- > > Key: AMQ-771 > URL: https://issues.apache.org/activemq/browse/AMQ-771 > Project: ActiveMQ > Issue Type: Bug > Components: Connector >Affects Versions: 4.0, 4.0.1 >Reporter: Kevin Yaussy > Assigned To: Rob Davies > > Especially when using "failover", there can be a problem with respect to > TransportConnection::stop attempting to send a "shutdown" message over the > connection. If another thread is sending messages to the connection, and it > gets stuck for some reason, such as a network freeze, the target machine > panics, or the target process freezes for some reason, the > TransportConnection::dispatch will eventually block, locking the > MutextTransport object. When the InactivityMonitor wakes up and detects that > the connection is dead, it will go through the process of stopping the > connection. This goes back into TransportConnection, and calls stop, which > attemtps to lock the MutexTransport so it can send the "shutdown" command. > Now, both threads are stuck, potentially for a long time, as a box panic will > not cleanly close the tcp connection. > I'm not sure the rationale for wanting to send a shutdown command to the > other side of the connection, since the target has to handle the connection > going down hard anyway. Seems to me, if you are intending on closing the > connection, just close it - don't try to be nice to the other side. > Especially in this code path, there is something wrong with the other side > anyway. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-776) ConduitBridge can malfunction when first of a set of consumers goes away
[ https://issues.apache.org/activemq/browse/AMQ-776?page=comments#action_36776 ] Kevin Yaussy commented on AMQ-776: -- Rob, The code for clearDownSubscriptions in DemandForwardingBridgeSupport.java is not present (empty method) in 4.0.1. Perhaps you are looking at 4.0.2 or 4.1? I haven't downloaded those versions yet. > ConduitBridge can malfunction when first of a set of consumers goes away > > > Key: AMQ-776 > URL: https://issues.apache.org/activemq/browse/AMQ-776 > Project: ActiveMQ > Issue Type: Bug > Components: Broker >Affects Versions: 4.0.1 >Reporter: Kevin Yaussy > Assigned To: Rob Davies >Priority: Critical > Fix For: 4.0.3 > > Attachments: ConduitBridge.patch > > > When the following scenario is followed, any of the subsequent consumers will > stop receiving messages. I've reproduced this using the ConsumerTool, and > ProducerTool supplied in the example area of the distribution. > +++ > Start Broker A > Start Broker B > Start Consumer 1, connecting to Broker B, consuming FOO > Start Consumer 2, connecting to Broker B, consuming FOO > Start Publisher, connecting to Broker A, publishing FOO > Ctl-C out of Consumer 1 > Consumer 2 stops receiving messages > +++ > Seems to me that ConduitBridge is supposed to track all consumers for a given > subscription, by way of DemandSubscription. It is seeding DemandSubscription > with the originating consumer, but when subsequent consumers are added, the > ConduitBridge::addToAlreadyInterestedConsumers re-adds the original > subscriber to the DemandSubscription's map - so the map only ever has the > original subscription. > I've attached a patch. Hope the change is good. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Tests are failing for the BPEL component
Tests are failing for the BPEL component!! (mvn test) --- Test set: org.apache.servicemix.bpe.BPEComponentTest --- Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.859 sec <<< FAILURE! testWithHttp(org.apache.servicemix.bpe.BPEComponentTest) Time elapsed: 0.843 sec <<< ERROR! java.lang.NoClassDefFoundError: javax/servlet/ServletRequest at org.apache.servicemix.http.HttpEndpoint.createConsumerProcessor(HttpEndpoint.java:239) at org.apache.servicemix.soap.SoapEndpoint.activate(SoapEndpoint.java:344) at org.apache.servicemix.common.ServiceUnit.start(ServiceUnit.java:50) at org.apache.servicemix.http.HttpSpringComponent$LifeCycle.doStart(HttpSpringComponent.java:93) at org.apache.servicemix.common.AsyncBaseLifeCycle.start(AsyncBaseLifeCycle.java:199) at org.apache.servicemix.jbi.framework.ComponentMBeanImpl.doStart(ComponentMBeanImpl.java:289) at org.apache.servicemix.jbi.framework.ComponentRegistry.setInitialRunningStateFromStart(ComponentRegistry.java:157) at org.apache.servicemix.jbi.framework.ComponentRegistry.start(ComponentRegistry.java:74) at org.apache.servicemix.jbi.framework.Registry.start(Registry.java:119) at org.apache.servicemix.jbi.container.JBIContainer.start(JBIContainer.java:559) at org.apache.servicemix.bpe.BPEComponentTest.testWithHttp(BPEComponentTest.java:108)
Re: JPA Plugin Status
I'm open, but how do you set up the class path if the vendor needs more than a single JAR? I don't think it's so onerous to write a single glue class when there are only a handful of vendors out there, but I'm certainly willing to revisit it. Thanks, Aaron On 8/14/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Aaron, Why do you need to have vendor code? Why can't this be a bit more dynamic? Long term, I think its a bad idea to have to declare a vendor wrapped API when our competitors just need to dump the provider jars in a directory somewhere or include them in a deployment. Basically, anyone who wants to use a provider that we haven't supported has to write vendor G-only code...right? If this is the case, I think that is a bit burdensome. Thoughts? Jeff Aaron Mulder wrote: > The code for the app-managed-JPA-for-web-apps plugin is up at SVN > https://svn.sourceforge.net/svnroot/gplugins/jpa/trunk > > So far, it's just got a TopLink provider, but if people want to copy > that to create providers for Cayenne or OpenJPA or whatever, that > would be great. It basically just needs to have a customized name and > ClassPath, though I'm assuming any provider we integrate with will be > compatible with the Geronimo JPA spec JAR (currently > org.apache.geronimo.specs/geronimo-jpa_3.0_spec/1.0-SNAPSHOT/jar) > > If you try to build and run this, you'll be held up by a couple things: > * It needs the latest car-maven-plugin, and I'm not sure whether > Jason has pushed a fresh snapshot since the last changes to it > * It needs Geronimo 1.1 CARs in the M2 repo, and Matt has said > posting those is on his to-do list > * It only runs in Geronimo 1.1.1 due to reference resolution bugs in > G 1.1, and currently the G 1.1.1 build is broken > > But if you get past all that (or comment out the plugins child from > the main POM to avoid the first two issues) and run your server under > Java 5, you can deploy web apps using JPA. :) > > My goal is to have a release of this plugin with sufficient user > documentation when G 1.1.1 is released. It would be great to have > some open source JPA providers for that release too. > > I also started talking to David B about the JPA work being done in > OpenEJB, and I think we're agreed that we probably don't need two such > plugins for G 1.1.x, so hopefully we can work toward a unification as > we move forward. > > Thanks, > Aaron
[jira] Closed: (GERONIMODEVTOOLS-40) Cannot start server programmatically
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-40?page=all ] Sachin Patel closed GERONIMODEVTOOLS-40. Resolution: Fixed I think this should be fixed now in HEAD, if you need I can make a driver available for you to verify. Let me know. Thanks. > Cannot start server programmatically > > > Key: GERONIMODEVTOOLS-40 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-40 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin > Environment: Windows XP >Reporter: Kathy Chan > Assigned To: Sachin Patel >Priority: Critical > Fix For: 1.x > > > I was using the following drivers on Windows XP: > - WTP 1.0 > - Geronimo 1.0 server > - Geronimo 20060109 plugin > With a new workspace, do the following: > - install Geronimo 1.0 server runtime > - create Geronimo server using server tooling > - start server > - create Web project "a1" with EAR > - In the Web project, create a simple Echo.java with a "hello" method that > takes a String and returns it. > Here are the procedure to create a bottom-up Web service: > - right-click on Echo.java, select Web Services -> Create Web service > - select "test Web service" and "overwrite file" on the 1st page of Web > service wizard > - click Finish > - when the Web Services Explorer comes up, you should be able to invoke the > hello method > Now, if you remove the Web project "a1" from the server and ensure that the > server is still in "started" state, then you can repeat the above steps to > create a bottom-up Web service. > However, if you do not remove the Web project from the server first, then > you'll run into the problem reported in bug > http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-39. > If you remove the Web project from the server first but stop the server > before creating the bottom-up Web service, when the Web service wizard tried > to start the server programmatically, you'll notice that the server console > indicates that > Geronimo startup complete > but server tooling still thinks that the server is started. The server start > will eventually times out. > Now, even if I use server tooling to start the server, server start would not > complete. This problem persist even if I delete the server and recreate > another one. The only way I could recover is to use a new workspace. -- 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: (GERONIMODEVTOOLS-77) The WTP adapter for Geronimo resists to add a simple web project
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-77?page=all ] Sachin Patel closed GERONIMODEVTOOLS-77. Resolution: Cannot Reproduce Assignee: Sachin Patel Cannot reproduce this. Since this has been reported on 1.0.0 can you pick up and try on the 1.1 release? If so feel free to reopen. > The WTP adapter for Geronimo resists to add a simple web project > > > Key: GERONIMODEVTOOLS-77 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-77 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin >Affects Versions: 1.0.0 > Environment: Eclipse 3.1.1 (Build: M20050929-0840) > WTP: 1.0.1.v2006 > Geronimo: 1.0 with Jetty > Eclipse command: eclipse > Java SE Version: j2sdk1.4.2_10 > OS: Windows 2k and Windows XP >Reporter: Daniel S. Haischt > Assigned To: Sachin Patel > Fix For: 1.x > > Attachments: geronimo-simple-jsp.7z > > > Today I tried to finally deploy a very simple JSP based web project (see > attached file). Unfortunatly it seems that the WTP adapter resists to deploy > the project. Can you confirm this 'misbehaviour'? > Regards > Daniel S. Haischt -- 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: JPA Plugin Status
Aaron, Why do you need to have vendor code? Why can't this be a bit more dynamic? Long term, I think its a bad idea to have to declare a vendor wrapped API when our competitors just need to dump the provider jars in a directory somewhere or include them in a deployment. Basically, anyone who wants to use a provider that we haven't supported has to write vendor G-only code...right? If this is the case, I think that is a bit burdensome. Thoughts? Jeff Aaron Mulder wrote: > The code for the app-managed-JPA-for-web-apps plugin is up at SVN > https://svn.sourceforge.net/svnroot/gplugins/jpa/trunk > > So far, it's just got a TopLink provider, but if people want to copy > that to create providers for Cayenne or OpenJPA or whatever, that > would be great. It basically just needs to have a customized name and > ClassPath, though I'm assuming any provider we integrate with will be > compatible with the Geronimo JPA spec JAR (currently > org.apache.geronimo.specs/geronimo-jpa_3.0_spec/1.0-SNAPSHOT/jar) > > If you try to build and run this, you'll be held up by a couple things: > * It needs the latest car-maven-plugin, and I'm not sure whether > Jason has pushed a fresh snapshot since the last changes to it > * It needs Geronimo 1.1 CARs in the M2 repo, and Matt has said > posting those is on his to-do list > * It only runs in Geronimo 1.1.1 due to reference resolution bugs in > G 1.1, and currently the G 1.1.1 build is broken > > But if you get past all that (or comment out the plugins child from > the main POM to avoid the first two issues) and run your server under > Java 5, you can deploy web apps using JPA. :) > > My goal is to have a release of this plugin with sufficient user > documentation when G 1.1.1 is released. It would be great to have > some open source JPA providers for that release too. > > I also started talking to David B about the JPA work being done in > OpenEJB, and I think we're agreed that we probably don't need two such > plugins for G 1.1.x, so hopefully we can work toward a unification as > we move forward. > > Thanks, > Aaron
Re: Problems with security propagation between web apps and ejbs
I've attached patches for geronimo/openejb2 trunk to GERONIMO-2313
that fix this problem, but I'd prefer to get some review before I
apply them.
thanks
david jencks
On Aug 10, 2006, at 2:47 PM, David Jencks wrote:
A user noticed that when their web app called an ejb, despite the
authentication of the user in the web app, in the ejb
isCallerinRole always returns false. I've been investigating this
and think we have some problems in how we handle run-as identities
and the ContextManager currentCaller and nextCaller values. I'm
also not sure where our defaultSubject idea fits into this. I'll
try to summarize my understanding of the specs and what we should
be doing, and make a bit of a proposal.
I'd really appreciate some review of how I think its supposed to
work and comments on my proposal. I'm working on a patch to
implement the proposal, but I believe we have to do something since
what we do now appears to be broken.
web apps (2.4 spec):
SRV.12.3 states that the getRemoteUser, isUserInRole, and
getUserPrincipal methods should return null, false, and null if
there is no authenticated user. Following the specs' usual policy
of not discussing cross context dispatch, we are left to guess that
even if a run-as role is specified somewhere the target of a cross-
context dispatch should continue to return null, false, null with
no actual authenticated user.
SRV.12.7 states that if a run-as element is specified, all calls
from any servlet in the application to an ejb must be done under a
subject associated with the run-as role.
The spec does not seem to account for the possiblity that calls to
ejbs could be done either pre- or post- user authentication: if a
run-as role is specified, all calls will be made using it whether
or not the user is authenticated.
We've introduced the concept of a defaultSubject that is used if
the user is not authenticated, but will not interfere with using
the users actual identity when the user is authenticated. IIUC (I
haven't tested) currently the default subject is used in a way that
interferes with the "null, false, null" requirements for
getRemoteUser, isUserInrole, and getUserPrincipal.
ejbs: (2.1 spec)
21.3.4.1 indicates that the run-as identity specified for an ejb
does not affect any security decisions for the ejb itself, but only
specifies the identity to be used when it is calling other ejbs ( I
need to check which identity is used use with resource adapters
using container managed security). Methods such as isCallerInRole
use the caller's identity, not the run-as identity (21.2.5.1)
We're keeping track of these two identities in ContextManager
currentCaller and nextCaller (threadLocals). All security
decisions are based on the currentCaller value. When a run-as
value is specified for an ejb, it's put into the nextCaller. When
an ejb is called, the nextCaller value is shifted into the
currentCaller: this is supposed to occur before the run-as is put
into the nextCaller.
My understanding of the requirements is that we should be:
- when a web user is authenticated we should put the subject into
currentCaller and nextCaller. The currentCaller value will be used
for security decisions in the web app, and the nextCaller value for
security decisions on any ejbs it calls.
- when a run-as role is specified for a web app we put the subject
associated with the run-as role into nextCaller (whether or not the
current user is authenticated)
- cross context dispatch may replace the nextCaller if run-as is
specified for the target, and the previous nextCaller value needs
to be restored on return. This can never affect currentCaller.
- defaultSubject (a non-spec concept) should be put into both
currentCaller and nextCaller unless run-as is specifed in which
case run-as goes in the nextCaller.
Currently the web security stuff is pretty much ignoring nextCaller
which is causing the authenticated user to be lost in ejb calls:
this causes the problem the user reported. I'm mystified as to how
the tck passes.
I think that perhaps we should organize this information into one
object with more explicit operations on the ContextManager:
class Callers {
Subject currentCaller;
Subject nextCaller;
}
in ContextManager:
void setCallers(Subject currentCaller, Subject nextCaller)
//called for servlet cross context dispatch to set the target app
run-as identity
Callers setNextCaller(Subject nextCaller);
//called for ejb call to shift the next caller to current caller
and set the next caller to the run-as subject.
// We need either another method with no params for the "no run-as"
case or if null is suppled the nextCaller is not changed
Callers pushNextCaller(Subject nextCaller);
//called on return from an ejb call or servlet-cross-context-dispatch.
void popCallers(Callers oldCallers);
This wou
[jira] Updated: (GERONIMO-2313) Subject not propagated correctly between web app and ejb
[ http://issues.apache.org/jira/browse/GERONIMO-2313?page=all ] David Jencks updated GERONIMO-2313: --- Attachment: GERONIMO-2313.diff GERONIMO-2313-openejb.diff Here are patches for geronimo trunk and openejb2 trunk to fix this problem along the lines suggested in the dev list email discussion. Although this is a bug fix I'd prefer review of this patch before I apply it. > Subject not propagated correctly between web app and ejb > > > Key: GERONIMO-2313 > URL: http://issues.apache.org/jira/browse/GERONIMO-2313 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) >Affects Versions: 1.1, 1.1.1, 1.1.x >Reporter: David Jencks > Assigned To: David Jencks > Fix For: 1.2 > > Attachments: ejbrefsec-ear-1.0-SNAPSHOT.ear, ejbrefsec.src.jar, > GERONIMO-2313-openejb.diff, GERONIMO-2313.diff > > > With a web app with security, that calls an ejb, isCallerInRole in the ejb > always returns false. > this is caused by the web app not setting nextCaller and the ejb interceptors > shifting nextCaller to currentCaller, so when the isCallerInRole is tested > there is a null subject so it returns false. -- 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: XBean and QDox
On 8/13/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: It seems that nobody work on QDox since several months. (see http://www.nabble.com/Anyone-developing-QDox--tf705135r1.html) Does anyone know of any replacement we could use to allow java 5 parsing ? I was thinking of introducing real annotations, but this would make xbean-spring JDK 5 specific. Any thoughts ? We could compile the source with Java 5, use source-only annotations maybe - then generate Java 1.4 compliant code via retrotranslator. -- James --- http://radio.weblogs.com/0112098/
