Re: [ANNOUNCE] Welcome Kevan Miller to the Geronimo PMC
Congrates Kevan , On 8/10/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: Matt Hogstrom wrote:> Please welcome Kevan Miller as the newest member of the Geronimo PMC.> Kevan recently accepted the invitation to join the PMC. As such we > now have an additional set of eyes to help with reviews as well as> other PMC oversight responsibilities. Kevan has shown that he is not> only a valuable member of the technical community but also spends much > of his time helping others as well as making sure those pesky LICENSE> files make it into every jar we ship.>> Give it up for Kevan :-0Congrats Kevan!Regards,Alan
Re: [ANNOUNCE] Welcome Paul McMahan as our newest committer
Matt Hogstrom wrote: All, We're pleased to let you know that we have a new committer in our midst. Paul McMahan has recently accepted an invitation to join the Geronimo project. Paul has been active on Geronimo for several months and has provided numerous patches for the console and related areas. He has been very helpful to users and recently worked with Genender and the Liferay folks to bring together a ifeRay plugin. We're anxious to see the kind of damage he can do to us now directly than through all those patches :) Welcome Paul! Welcome aboard Paul! Regards, Alan
Re: [ANNOUNCE] Welcome Kevan Miller to the Geronimo PMC
Matt Hogstrom wrote: Please welcome Kevan Miller as the newest member of the Geronimo PMC. Kevan recently accepted the invitation to join the PMC. As such we now have an additional set of eyes to help with reviews as well as other PMC oversight responsibilities. Kevan has shown that he is not only a valuable member of the technical community but also spends much of his time helping others as well as making sure those pesky LICENSE files make it into every jar we ship. Give it up for Kevan :-0 Congrats Kevan! Regards, Alan
Re: Independently version transaction and connector
There's a ring of truth in these paragraphs. Regards, Alan Jason Dillon wrote: For the record, I do think that it is a good idea to split G up into some smaller chunks... I am just concerned about how small the chunks become and how it may eventually lead to chaos I've been there before and would like to avoid it in the future. I am not against moving transaction and connector bits to separate peer trees... I am just trying to avoid us moving all modules to separate trees which would be a massive painful nightmare. But, I think that splitting off large/major chunks of G into versioned trees is the right direction... just need to make sure it does not get out of hand. --jason On Aug 9, 2006, at 6:42 PM, Dain Sundstrom wrote: What do everyone think about changing the transaction and connector modules to be versioned independently of the main Geronimo server? -dain
[jira] Resolved: (GERONIMO-2295) Web app security constraint ignored if url-pattern doesn't match servlet mapping exactly
[ http://issues.apache.org/jira/browse/GERONIMO-2295?page=all ]
Alan Cabrera resolved GERONIMO-2295.
Resolution: Fixed
> Web app security constraint ignored if url-pattern doesn't match servlet
> mapping exactly
>
>
> Key: GERONIMO-2295
> URL: http://issues.apache.org/jira/browse/GERONIMO-2295
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: web, security
>Affects Versions: 1.1
>Reporter: Aaron Mulder
> Assigned To: Alan Cabrera
>Priority: Blocker
> Fix For: 1.1.1, 1.2
>
> Attachments: SecurityTest.war
>
>
> If you have the following in your web.xml:
> {noformat}
>
> SecureServlet
> /secure/*
>
>
> ...
>
>
>
> Security Test
> /secure/adminonly
> GET
> POST
> PUT
>
>
> administrator
>
>
> {noformat}
> Then the page /secure/adminonly is in fact completely unprotected -- a user
> who's not logged in can see it!
--
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: (XBEAN-39) NPE in XBeanHelper.createBeanDefinitionReader with some Classloaders
[ http://issues.apache.org/jira/browse/XBEAN-39?page=all ] Stefan Kleineikenscheidt updated XBEAN-39: -- Attachment: XBEAN-39.patch Patch attached. Solution: After everyting else has failed, XBean tries to look up a system property 'xbean.dir'. The system property points to a directory, where XBean can load the property files for the custome mapping files and a additional xbean.properties file, which contains a property 'spring.version'. > NPE in XBeanHelper.createBeanDefinitionReader with some Classloaders > > > Key: XBEAN-39 > URL: http://issues.apache.org/jira/browse/XBEAN-39 > Project: XBean > Issue Type: Bug >Affects Versions: 2.0, 2.1, 2.2, 2.3, 2.4, 2.5 >Reporter: Stefan Kleineikenscheidt > Attachments: XBEAN-39.patch > > > XBean fails on systems with some classloaders, which do not return sensible > values from the following methods > pkg.getImplementationVersion(); or > cl.getResourceAsStream(name); > This leads to > a) a NPE thrown by SpringVersion.getVersion, > b) the property files with custom mappings are not found. -- 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-2295) Web app security constraint ignored if url-pattern doesn't match servlet mapping exactly
[ http://issues.apache.org/jira/browse/GERONIMO-2295?page=all ]
Alan Cabrera updated GERONIMO-2295:
---
Fix Version/s: 1.2
> Web app security constraint ignored if url-pattern doesn't match servlet
> mapping exactly
>
>
> Key: GERONIMO-2295
> URL: http://issues.apache.org/jira/browse/GERONIMO-2295
> Project: Geronimo
> Issue Type: Bug
> Security Level: public(Regular issues)
> Components: web, security
>Affects Versions: 1.1
>Reporter: Aaron Mulder
> Assigned To: Alan Cabrera
>Priority: Blocker
> Fix For: 1.2, 1.1.1
>
> Attachments: SecurityTest.war
>
>
> If you have the following in your web.xml:
> {noformat}
>
> SecureServlet
> /secure/*
>
>
> ...
>
>
>
> Security Test
> /secure/adminonly
> GET
> POST
> PUT
>
>
> administrator
>
>
> {noformat}
> Then the page /secure/adminonly is in fact completely unprotected -- a user
> who's not logged in can see it!
--
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: (XBEAN-39) NPE in XBeanHelper.createBeanDefinitionReader with some Classloaders
NPE in XBeanHelper.createBeanDefinitionReader with some Classloaders Key: XBEAN-39 URL: http://issues.apache.org/jira/browse/XBEAN-39 Project: XBean Issue Type: Bug Affects Versions: 2.5, 2.4, 2.3, 2.2, 2.1, 2.0 Reporter: Stefan Kleineikenscheidt XBean fails on systems with some classloaders, which do not return sensible values from the following methods pkg.getImplementationVersion(); or cl.getResourceAsStream(name); This leads to a) a NPE thrown by SpringVersion.getVersion, b) the property files with custom mappings are not found. -- 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: How to resolve JMS Dependency ?
attaching modified geronimo-web.xml and openejb-jar.xml in which i have added admin-object-linkThanksManishOn 8/10/06, Manish Satwani < [EMAIL PROTECTED]> wrote:Hi All,I am stillg getting this erro during deployment. Unable to resolve resource reference 'jms/AcevaPublisherQueue' (Could not auto-map to resource. Try adding a resource-ref mapping to your Geronimo deployment plan.) org.apache.geronimo.common.DeploymentException: Unable to resolve resource reference 'jms/AcevaPublisherQueue' (Could not auto-map to resource. Try adding a resource-ref mapping to your Geronimo deployment plan.) at org.apache.geronimo.naming.deployment.ENCConfigBuilder.addResourceRefs(ENCConfigBuilder.java:210) I have added admin-object-link as suggested by Aaron.I am attching my web.xml also...and whole RA plan...please do let me know if you need any other configuration filefor reference... please help me ...ThanksManishOn 8/8/06, Aaron Mulder < [EMAIL PROTECTED] > wrote:OK, let's back up a bit.In order to reference JMS resources from a web app: * For a connection factory, use a resource-ref (I think you did this) * For a topic or queue in J2EE 1.4 / Servlet 2.4, use amesssage-destination-ref * For a topic or queue in J2EE < 1.4 / Servlet < 2.4, use a resource-env-refSo your queue reference was not correct in the snippets you posted.For a walkthrough of the correct syntax, see http://chariotsolutions.com/geronimo/geronimo-1.1/web-plan.html#web-plan-jms(section 11.3.5.5 has a discussion with examples of both styles). Your EJB JAR used EJB 2.0, which suggests that you're using J2EE 1.3,but you might be using Servlet 2.4 anyway, which would make thedifference.If you want more specific help, you'll need to post your web.xml files.Thanks, AaronOn 8/8/06, Manish Satwani < [EMAIL PROTECTED]> wrote:> Hi ,>> I am new in geronimo can you please tell me where exactly should i > change> I am attaching all configuration files here >> I have 2 war in my ear thats why i attached 2 geronimo-web.xml>>> please help me>> Thanks> Manish>>> On 8/8/06, Krishnakumar B < [EMAIL PROTECTED]> wrote:> > For referring to Queues u should use> >> > > > > > > > > >> > or Message Destination Reference> >> > I think both would work> >> >> http://www.chariotsolutions.com/geronimo/geronimo-1.1/web-plan.html#web-plan-refs> > ( You can refer to resource-env-ref for J2EE Connector Administered> > Objects )> >> > Resource Environment Ref can be used to reference JMS Destinations. > >> > Regards> > Krishnakumar> >> > On 8/8/06, Manish Satwani < [EMAIL PROTECTED]> wrote:> > > Hi All, > > >> > > I am facing problem while deploying my ear on geronimo 1.1> > >> > > It is complaining regarding jms/AcevaPublisherQueue (my application need> > > this) > > >> > > I have added this queue from console.> > >> > we have acm.war file which also access (resource-ref) this queue> > > and i have acevaEJB.jar which also have (resource-ref) to this queue > > >> > > i also added resource-link entries in geronimo-web.xml and> openEJB-jar.xml> > >> > > this is in openEjb-jar.xml> > > > > > CollectionService > > >> ejb/CollectionService> > > > > >> > >> jms/AcevaPublisherConnectionFactory > > >> > >> jms/AcevaPublisherConnectionFactory> > > > > > > > >> > >> jms/AcevaPublisherQueue> > >> > >> jms/AcevaPublisherQueue > > > > > > > > >> > >> > > this is in geronimo-web.xml> > >> > > > > >> > >> jms/AcevaPublisherQueue> > >> > >> jms/AcevaPublisherQueue > > > > > >> > >> > >> > > any enviroment - > depency entry needed?> > >> > > if yes> > > > > > > > > ?> (what> > > should i write here)> > >> > > ???(what should i > write> > > here)> > > > > >> > >> > > --> > > Manish Satwani> > > Senior Software Engineer > > > Aceva Technologies | Unlock Your Working Capital> > > A-1501, Signature Towers - I,> > > South City, Gurgaon,> > > Haryana – 122001> > > Call at: > > > +91-124-2805091/92 Ext. 35 > > > +91-99113-16998> > > Visit: http://www.aceva.com> > -->> Manish Satwani> Senior Software Engineer > Aceva Technologies | Unlock Your Working Capital> A-1501, Signature Towers - I,> South City, Gurgaon,> Haryana – 122001> Call at:> +91-124-2805091/92 Ext. 35> +91-99113-16998 > Visit: http://www.aceva.com>-- Manish SatwaniSenior Software EngineerAceva Technologies | Unlock Your Working Capital A-1501, Signature Towers - I,South City, Gurgaon,Haryana – 122001Call at:+91-124-2805091/92 Ext. 35+91-99113-16998Visit: http://www.aceva.com -- Manish SatwaniSenior Software EngineerAceva Technologies | Unlock Your Working CapitalA-1501, Signature Towers - I,South City, Gurgaon, Haryana – 122001Call at:+91-124-2805091/92 Ext. 35+91-99113-16998Visit: http://www.aceva.com http://www.openejb.org/xml/ns/openejb-jar-2.1"; xmlns:naming="http://geronimo.apache.org/xml/ns/naming-1.1"; xmlns:security="http://geronimo.apache.org/xml/ns/security-1.1"; xm
Re: [jira] Commented: (AMQ-850) add the ability to timeout a consumer to
>> 1. can we use an 'elastic prefetch' buffer based on a sliding window (like >> in TCP) - this reacts to client (mis)behavior >We could start with a prefetch of 1 and increase it over time for well >behaving clients. However it doesn't fix the problem as a mis-behaving >consumer could still hog at least one message - though this would >reduce the imact from 1000 or so to 1. Note that the prefetch window needs to follow the standard tcp stuff of multiplicative decrease during problem period & additive increase upon positive ack (IMHO, there isn't much to be gained in reinventing the TCP flow control wheel, which has been honed for over a decade.) This helps in several ways: - Messages are dispatched as soon as possible, as slow consumer will automatically have a smaller 'prefetch window'. In fact by decaying the 'prefetch window' (like in the latest implementations of TCP flow control), a new slow consumer's window automatically shrinks. - I am not sure I understand the 'one message hog' case. Most of the consumers are idempotent (there are many failure cases to count on 'once and only once' delivery). So there is no harm in redelivering this one message for which no ack has been received yet. >> 2. When the broker detects a misbehaving client, reclaim the unAcked >> messages for other active consumers (and make the window size 0 or 1 in >> step >> 1 above) >If a client/connection misbehaves (e.g. becomes inactive) then the >connection is closed and all consumers are closed too causing all >their unacked messages to be redelivered. This sounds good. However, please note that misbehavior is not necessarily a binary state. Sometimes an ACK could be delayed for many reasons (either transient consumer (mis) behavior or other network related issues). It is in the gray areas that the tcp flow control works really well. Thanks James, Regards - Sridhar Komandur -- View this message in context: http://www.nabble.com/-jira--Created%3A-%28AMQ-850%29-add-the-ability-to-timeout-a-prefetch-buffer-to-prevent-a-single-consumer-grabbing-messages-tf2014900.html#a5738266 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: maven m:eclipse issue on 1.1 in OpenEJB itests
On Aug 9, 2006, at 10:04 PM, John Sisson wrote: I am trying to build the eclipse project files for a clean 1.1 build. I did the following: * svn co https://svn.apache.org/repos/asf/geronimo/branches/1.1 * cd 1.1 * maven m:fresh-checkout * maven new * maven m:eclipse -o The m:eclipse processing fails in OpenEJB itests. How do I get the geronimo-jetty-j2ee-1.1.2-SNAPSHOT.zip file to be placed in my local repository as part of the build so it doesn't fail? Sorry to ask the obvious, but are you sure 'maven new' completed successfully? I end up with the zip file in .maven/repository/ geronimo/distributions/ One additional note, I have to run 'maven m:eclipse' online the first time. Otherwise, there's a missing dependency for maven-itest- plugin-1.0.jar. Since we don't currently run itests, 'maven new' doesn't download the dependency. Suppose we could figure out how to exclude OpenEJB itest from the m:eclipse goal... --kevan Thanks, John [echo] Place java sources for xstream at R:\.geronimo-1.1.x-maven \repository\xstream\java-sources\xstream-1.1.3-sources.jar for javadoc and debugging support in Eclipse [echo] Place java sources for xpp3 at R:\.geronimo-1.1.x-maven \repository\xpp3\java-sources\xpp3-1.1.3.3-sources.jar for javadoc and debugging support in Eclipse [echo] Place java sources for commons-jelly-tags-velocity at R: \.geronimo-1.1.x-maven\repository\commons-jelly\java-sources\comm ons-jelly-tags-velocity-1.0-sources.jar for javadoc and debugging support in Eclipse [echo] Place java sources for velocity at R:\.geronimo-1.1.x- maven\repository\velocity\java-sources\velocity-1.4-sources.jar for javadoc and debugging support in Eclipse [echo] Setting default output directory to target/classes [echo] Now refresh your project in Eclipse (right click on the project and select "Refresh") + | Executing eclipse OpenEJB :: Integration Tests | Memory: 27M/32M + 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 eclipse: build:end: You are working offline so the build will continue, but openejb- builder-2.1.2-SNAPSHOT.jar may be out of date! BUILD FAILED File.. R:\.geronimo-1.1.x-maven\cache\maven-multiproject- plugin-1.4.1\plugin.jelly Element... maven:reactor Line.. 218 Column -1 The build cannot continue because of the following unsatisfied dependency: geronimo-jetty-j2ee-1.1.2-SNAPSHOT.zip Total time : 6 minutes 37 seconds Finished at : Thursday, 10 August 2006 10:33:27
[jira] Resolved: (GERONIMO-2306) Add ASL info to LICENSE/NOTICE files in geronimo-util jar file and BouncyCastle info to root directory LICENSE/NOTICE
[ http://issues.apache.org/jira/browse/GERONIMO-2306?page=all ] Kevan Miller resolved GERONIMO-2306. Resolution: Fixed I added ASL license and notice information to the license and notice files for the geronimo-util jar. I also added Bouncy Castle license and notice information to the root directory license and notice files. Appeared that the trunk license and notice files in modules/scripts/src/resources were missing some license and notice information. I brought the two files in line with their branches/1.1.1 counterparts. > Add ASL info to LICENSE/NOTICE files in geronimo-util jar file and > BouncyCastle info to root directory LICENSE/NOTICE > - > > Key: GERONIMO-2306 > URL: http://issues.apache.org/jira/browse/GERONIMO-2306 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.1.1 >Reporter: Kevan Miller > Assigned To: Kevan Miller >Priority: Blocker > Fix For: 1.1.1, 1.1.2, 1.2 > > > The BouncyCastle license and notice information are missing from the > LICENSE/NOTICE files in the root directory. ASL license and notice are > missing from the geronimo-util jar file. They must be added prior to release > of 1.1.1. -- 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: Independently version transaction and connector
For the record, I do think that it is a good idea to split G up into some smaller chunks... I am just concerned about how small the chunks become and how it may eventually lead to chaos I've been there before and would like to avoid it in the future. I am not against moving transaction and connector bits to separate peer trees... I am just trying to avoid us moving all modules to separate trees which would be a massive painful nightmare. But, I think that splitting off large/major chunks of G into versioned trees is the right direction... just need to make sure it does not get out of hand. --jason On Aug 9, 2006, at 6:42 PM, Dain Sundstrom wrote: What do everyone think about changing the transaction and connector modules to be versioned independently of the main Geronimo server? -dain
Re: [Committing] GERONIMO-2277 Remove TransactionContextManager
For future reference. This code is vastly improved, but this little guy is going to change our world once again. http://java.sun.com/javaee/5/docs/api/javax/transaction/ TransactionSynchronizationRegistry.html Can't wait Then there'll be a standard interface for 100% of what we're doing in this space. -David On Aug 9, 2006, at 4:47 PM, Dain Sundstrom wrote: The merge is complete. Thanks to everyone for reviewing this one quickly. -dain On Aug 9, 2006, at 9:28 AM, Dain Sundstrom wrote: With votes from Jeff, Jencks and Matt, I am going to committ this patch today, so please let me know if you're going to commit something significant so I can avoid conflicts :) -dain On Aug 7, 2006, at 4:07 PM, Dain Sundstrom wrote: Ok all fixed. Jason fixed the logging issue, and the other problem was that backport-concurrent-util was not in the manifest classpath of the server jar. -dain On Aug 7, 2006, at 10:05 AM, Dain Sundstrom wrote: On Aug 7, 2006, at 12:09 AM, David Jencks wrote: The notcm branch builds fine for me under m2 but the j2ee-jetty server does not start for me at the moment. Apparently the TransactionManager doesn't start. As noted in another post I don't get any log files which has so far inhibited me from investigating further. Is this just my setup? Don't know. I'll take a look -dain
maven m:eclipse issue on 1.1 in OpenEJB itests
I am trying to build the eclipse project files for a clean 1.1 build. I did the following: * svn co https://svn.apache.org/repos/asf/geronimo/branches/1.1 * cd 1.1 * maven m:fresh-checkout * maven new * maven m:eclipse -o The m:eclipse processing fails in OpenEJB itests. How do I get the geronimo-jetty-j2ee-1.1.2-SNAPSHOT.zip file to be placed in my local repository as part of the build so it doesn't fail? Thanks, John [echo] Place java sources for xstream at R:\.geronimo-1.1.x-maven\repository\xstream\java-sources\xstream-1.1.3-sources.jar for javadoc and debugging support in Eclipse [echo] Place java sources for xpp3 at R:\.geronimo-1.1.x-maven\repository\xpp3\java-sources\xpp3-1.1.3.3-sources.jar for javadoc and debugging support in Eclipse [echo] Place java sources for commons-jelly-tags-velocity at R:\.geronimo-1.1.x-maven\repository\commons-jelly\java-sources\comm ons-jelly-tags-velocity-1.0-sources.jar for javadoc and debugging support in Eclipse [echo] Place java sources for velocity at R:\.geronimo-1.1.x-maven\repository\velocity\java-sources\velocity-1.4-sources.jar for javadoc and debugging support in Eclipse [echo] Setting default output directory to target/classes [echo] Now refresh your project in Eclipse (right click on the project and select "Refresh") + | Executing eclipse OpenEJB :: Integration Tests | Memory: 27M/32M + 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 eclipse: build:end: You are working offline so the build will continue, but openejb-builder-2.1.2-SNAPSHOT.jar may be out of date! BUILD FAILED File.. R:\.geronimo-1.1.x-maven\cache\maven-multiproject-plugin-1.4.1\plugin.jelly Element... maven:reactor Line.. 218 Column -1 The build cannot continue because of the following unsatisfied dependency: geronimo-jetty-j2ee-1.1.2-SNAPSHOT.zip Total time : 6 minutes 37 seconds Finished at : Thursday, 10 August 2006 10:33:27
Re: [itests] Modify the geronimo-deployment-plugin ?
Kay :-) --jason On Aug 9, 2006, at 6:52 PM, Prasad Kashyap wrote: Jason, One of the things we discussed was to write/modify our plugins such that some oft used goals like start/stop servers, deploy/undeploy apps, start/stop apps will write it's output to a surefire like xml in the target/surefire-reports dir. Using the cargo plugin would not give us this ability to log the failures of the above popular goals in the surefire dir and to a site report eventually. Hmmm.. ?? Cheers Prasad On 8/8/06, Jason Dillon <[EMAIL PROTECTED]> wrote: More reasons for us to switch ;-) --jason On Aug 8, 2006, at 6:56 PM, Prasad Kashyap wrote: > Yep.. The last time I checked, I believe Cargo support for the G's > version of Jetty container needed Java 5 support. But we should > revisit that again. > > Cheers > Prasad > > On 8/8/06, Bill Dudney <[EMAIL PROTECTED]> wrote: >> Cool thing is someone else has already done it Cargo currently >> supports G 1.1. >> >> :-) >> >> -bd- >> >> On Aug 8, 2006, at 5:33 PM, Jason Dillon wrote: >> >> > I think that in general it would be good to have cargo support :-) >> > >> > --jason >> > >> > >> > On Aug 8, 2006, at 4:23 PM, Bill Dudney wrote: >> > >> >> Hi Prasad, >> >> >> >> The cargo plugins [1] might be another place to check to start and >> >> stop the server. >> >> >> >> I've used them before for tomcat and its good stuff for running >> >> integration tests. >> >> >> >> And what can I do to help? >> >> >> >> TTFN, >> >> >> >> -bd- >> >> >> >> [1] http://cargo.codehaus.org >> >> >> >> On Aug 4, 2006, at 10:00 AM, Prasad Kashyap wrote: >> >> >> >>> With the m2migration ready to be merged into trunk, I have >> resumed >> >>> work on the itests for Geronimo again. >> >>> >> >>> Approx 30% of our code is covered by component level tests >> that are >> >>> embedded in each module. These tests are written as junit test >> cases >> >>> and run by Maven surefire plugin. >> >>> >> >>> The itests will cover system level tests by testing the >> >>> functionalities that an end-user would use on a fully assembled >> >>> Geronimo distribution. Therefore to the extent possible, our >> itests >> >>> and it's testcases should use the very same external APIs and >> >>> workflows that a user would use. >> >>> >> >>> We have been using the startRemoteServer and stopRemoteServer >> >>> goals in >> >>> the geronimo-deployment-plugin (g-d-p) to start and stop a >> >>> server. We >> >>> have always used these "remote" goals and have never used the >> in-vm >> >>> goals startServer and stopServer. >> >>> >> >>> I propose that we convert the in-vm goals startServer and >> stopServer >> >>> to be ant mojos from their existing java mojos. Invoking the ant >> >>> mojo >> >>> goals in our itests will ensure that our tests are using the same >> >>> APIs >> >>> that a end-user uses. Thus we shall no longer use internal >> hooks in >> >>> the code to start and stop the server. >> >>> >> >>> Thoughts ? Comments ? Advice ? >> >>> >> >>> Cheers >> >>> Prasad >> >> >> > >> >>
Re: [itests] Modify the geronimo-deployment-plugin ?
Jason, One of the things we discussed was to write/modify our plugins such that some oft used goals like start/stop servers, deploy/undeploy apps, start/stop apps will write it's output to a surefire like xml in the target/surefire-reports dir. Using the cargo plugin would not give us this ability to log the failures of the above popular goals in the surefire dir and to a site report eventually. Hmmm.. ?? Cheers Prasad On 8/8/06, Jason Dillon <[EMAIL PROTECTED]> wrote: More reasons for us to switch ;-) --jason On Aug 8, 2006, at 6:56 PM, Prasad Kashyap wrote: > Yep.. The last time I checked, I believe Cargo support for the G's > version of Jetty container needed Java 5 support. But we should > revisit that again. > > Cheers > Prasad > > On 8/8/06, Bill Dudney <[EMAIL PROTECTED]> wrote: >> Cool thing is someone else has already done it Cargo currently >> supports G 1.1. >> >> :-) >> >> -bd- >> >> On Aug 8, 2006, at 5:33 PM, Jason Dillon wrote: >> >> > I think that in general it would be good to have cargo support :-) >> > >> > --jason >> > >> > >> > On Aug 8, 2006, at 4:23 PM, Bill Dudney wrote: >> > >> >> Hi Prasad, >> >> >> >> The cargo plugins [1] might be another place to check to start and >> >> stop the server. >> >> >> >> I've used them before for tomcat and its good stuff for running >> >> integration tests. >> >> >> >> And what can I do to help? >> >> >> >> TTFN, >> >> >> >> -bd- >> >> >> >> [1] http://cargo.codehaus.org >> >> >> >> On Aug 4, 2006, at 10:00 AM, Prasad Kashyap wrote: >> >> >> >>> With the m2migration ready to be merged into trunk, I have >> resumed >> >>> work on the itests for Geronimo again. >> >>> >> >>> Approx 30% of our code is covered by component level tests >> that are >> >>> embedded in each module. These tests are written as junit test >> cases >> >>> and run by Maven surefire plugin. >> >>> >> >>> The itests will cover system level tests by testing the >> >>> functionalities that an end-user would use on a fully assembled >> >>> Geronimo distribution. Therefore to the extent possible, our >> itests >> >>> and it's testcases should use the very same external APIs and >> >>> workflows that a user would use. >> >>> >> >>> We have been using the startRemoteServer and stopRemoteServer >> >>> goals in >> >>> the geronimo-deployment-plugin (g-d-p) to start and stop a >> >>> server. We >> >>> have always used these "remote" goals and have never used the >> in-vm >> >>> goals startServer and stopServer. >> >>> >> >>> I propose that we convert the in-vm goals startServer and >> stopServer >> >>> to be ant mojos from their existing java mojos. Invoking the ant >> >>> mojo >> >>> goals in our itests will ensure that our tests are using the same >> >>> APIs >> >>> that a end-user uses. Thus we shall no longer use internal >> hooks in >> >>> the code to start and stop the server. >> >>> >> >>> Thoughts ? Comments ? Advice ? >> >>> >> >>> Cheers >> >>> Prasad >> >> >> > >> >>
Re: Independently version transaction and connector
Why? That means a new trunk and added overhead to release and manage... :-\ --jason On Aug 9, 2006, at 6:42 PM, Dain Sundstrom wrote: What do everyone think about changing the transaction and connector modules to be versioned independently of the main Geronimo server? -dain
[jira] Assigned: (GERONIMO-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
[ http://issues.apache.org/jira/browse/GERONIMO-2307?page=all ] John Sisson reassigned GERONIMO-2307: - Assignee: Geir Magnusson Jr (was: John Sisson) Geir said he will follow this up. > Include appropriate license for the Sun j2ee schema files that are > redistributed > > > Key: GERONIMO-2307 > URL: http://issues.apache.org/jira/browse/GERONIMO-2307 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.0, 1.1 >Reporter: John Sisson > Assigned To: Geir Magnusson Jr >Priority: Blocker > Fix For: 1.1.1 > > > Geronimo redistributes the Sun J2EE schema files for deployment descriptors > etc but doesn't appear to include anything in the global license file about > it. > The following two statement in the copyright text in the schema files (e.g. > http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: > * This document and the technology which it describes are distributed under > licenses restricting their use, copying, distribution, and decompilation. > * No part of this document may be reproduced in any form by any means without > prior written authorization of Sun and its licensors, if any. > Considering the first point, we need to determine what license the files are > under. Seems we need written authorization for the second point. > The concern regarding copyrights for the schemas came to mind whilst testing > the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun > license at http://developers.sun.com/license/berkeley_license.html when > caching the j2ee schema files (e.g. > http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). > I can't find anything to confirm that the berkeley license displayed by > eclipse is the correct license for the schemas. -- 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: Independently version transaction and connector
Agreed. I think these modules are of the most reusable (and reused) part of G.This would also ensure maximum reusability by avoiding unnecessary ties to theremaining of Geronimo. On 8/10/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: What do everyone think about changing the transaction and connectormodules to be versioned independently of the main Geronimo server?-dain-- Cheers,Guillaume Nodet
Independently version transaction and connector
What do everyone think about changing the transaction and connector modules to be versioned independently of the main Geronimo server? -dain
[jira] Created: (GERONIMO-2307) Include appropriate license for the Sun j2ee schema files that are redistributed
Include appropriate license for the Sun j2ee schema files that are redistributed Key: GERONIMO-2307 URL: http://issues.apache.org/jira/browse/GERONIMO-2307 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem Affects Versions: 1.1, 1.0 Reporter: John Sisson Assigned To: John Sisson Priority: Blocker Fix For: 1.1.1 Geronimo redistributes the Sun J2EE schema files for deployment descriptors etc but doesn't appear to include anything in the global license file about it. The following two statement in the copyright text in the schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ) concern me: * This document and the technology which it describes are distributed under licenses restricting their use, copying, distribution, and decompilation. * No part of this document may be reproduced in any form by any means without prior written authorization of Sun and its licensors, if any. Considering the first point, we need to determine what license the files are under. Seems we need written authorization for the second point. The concern regarding copyrights for the schemas came to mind whilst testing the geronimo eclipse plugin, eclipse prompted me to acknowledge the Sun license at http://developers.sun.com/license/berkeley_license.html when caching the j2ee schema files (e.g. http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd ). I can't find anything to confirm that the berkeley license displayed by eclipse is the correct license for the schemas. -- 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-2306) Add ASL info to LICENSE/NOTICE files in geronimo-util jar file and BouncyCastle info to root directory LICENSE/NOTICE
[ http://issues.apache.org/jira/browse/GERONIMO-2306?page=all ] Kevan Miller updated GERONIMO-2306: --- Summary: Add ASL info to LICENSE/NOTICE files in geronimo-util jar file and BouncyCastle info to root directory LICENSE/NOTICE (was: Add BouncyCastle LICENSE/NOTICE information to to geronimo-util jar file and root directory LICENSE/NOTICE) Description: The BouncyCastle license and notice information are missing from the LICENSE/NOTICE files in the root directory. ASL license and notice are missing from the geronimo-util jar file. They must be added prior to release of 1.1.1. (was: The BouncyCastle license and notice information are missing from the LICENSE/NOTICE files in the root directory, as well as the geronimo-util jar file. They must be added prior to release of 1.1.1.) Assignee: Kevan Miller > Add ASL info to LICENSE/NOTICE files in geronimo-util jar file and > BouncyCastle info to root directory LICENSE/NOTICE > - > > Key: GERONIMO-2306 > URL: http://issues.apache.org/jira/browse/GERONIMO-2306 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.1.1 >Reporter: Kevan Miller > Assigned To: Kevan Miller >Priority: Blocker > Fix For: 1.1.1, 1.1.2, 1.2 > > > The BouncyCastle license and notice information are missing from the > LICENSE/NOTICE files in the root directory. ASL license and notice are > missing from the geronimo-util jar file. They must be added prior to release > of 1.1.1. -- 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-2305) geronimo.kernel.classloader.JarFileUrlStreamHandler fails with Trinidad
[ http://issues.apache.org/jira/browse/GERONIMO-2305?page=comments#action_12427069 ] David Jencks commented on GERONIMO-2305: I think this is caused by someone calling new URL(url, string) where url is created using our JarFileUrlStreamHandler and thus has the original url including the jarEntry stored inside. This constructor reuses the UrlStreamHandler from the source url which with our check of expectedUrl doesn't work. Can we notice that the expectedUrl is in the same jar file and figure out the correct jarEntry for the supplied url? > geronimo.kernel.classloader.JarFileUrlStreamHandler fails with Trinidad > --- > > Key: GERONIMO-2305 > URL: http://issues.apache.org/jira/browse/GERONIMO-2305 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 1.1 > Environment: Geronimo-jetty-1.1 running in Java 1.5.0_06 on Mac OS X > or Java 1.5.0_06 on XP > Aug. 6 Trinidad snapshot - > http://people.apache.org/maven-snapshot-repository/org/apache/myfaces/trinidad/ >Reporter: Chris Herborth >Priority: Blocker > Attachments: devSignup.war, devSignup.war > > > Web application (built with current MyFaces and Trinidad) crashes during page > loading with this stack trace: > 7-Aug-2006 10:40:40 AM > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider getCapabilities > SEVERE: could not get capabilities from capabilities document > java.lang.IllegalArgumentException: Expected url [jar:file:/C:/Documents and > Settings/chrish/Desktop/geronimo-1.1/repository/default/devsignup/1154961598406/devsignup-1154961598406.war/WEB-INF/lib/adf-faces-impl-incubator-m1-SNAPSHOT.jar!/META-INF/agent/capabilities.xml], > but was [jar:file:/C:/Documents and > Settings/chrish/Desktop/geronimo-1.1/repository/default/devsignup/1154961598406/devsignup-1154961598406.war/WEB-INF/lib/adf-faces-impl-incubator-m1-SNAPSHOT.jar!/META-INF/agent/htmlBasic.xml] > at > org.apache.geronimo.kernel.classloader.JarFileUrlStreamHandler.openConnection(JarFileUrlStreamHandler.java:63) > at java.net.URL.openConnection(Unknown Source) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilityDataDocumentParser.parse(CapabilityDataDocumentParser.java:60) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:315) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:226) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:293) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:212) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getDefaultAgentCapabilities(CapabilitiesDocument.java:117) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument.(CapabilitiesDocument.java:38) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocumentParser.endElement(CapabilitiesDocumentParser.java:184) > at > org.apache.myfaces.adfinternal.share.xml.TreeBuilder$Handler.endElement(TreeBuilder.java:463) > at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown > Source) > at > org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > at > org.apache.myfaces.adfinternal.share.xml.TreeBuilder.parse(TreeBuilder.java:166) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocumentParser.createInstance(CapabilitiesDocumentParser.java:67) > at > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider._getCapabilityDocument(CapabilitiesProvider.java:128) > at > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider._getCapabilities(CapabilitiesProvider.java:110) > at > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider.getCapabilities(CapabilitiesProvider.java:91) > at > org.apache.myfaces.adfinternal.agent.AdfFacesAgentImpl._getCapabilityMap(AdfFacesAgentImpl.java:263) > at > org.apache.myfaces.adfinternal.agent.AdfFaces
[jira] Created: (GERONIMO-2306) Add BouncyCastle LICENSE/NOTICE information to to geronimo-util jar file and root directory LICENSE/NOTICE
Add BouncyCastle LICENSE/NOTICE information to to geronimo-util jar file and root directory LICENSE/NOTICE -- Key: GERONIMO-2306 URL: http://issues.apache.org/jira/browse/GERONIMO-2306 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: buildsystem Affects Versions: 1.1.1 Reporter: Kevan Miller Priority: Blocker Fix For: 1.1.1, 1.1.2, 1.2 The BouncyCastle license and notice information are missing from the LICENSE/NOTICE files in the root directory, as well as the geronimo-util jar file. They must be added prior to release of 1.1.1. -- 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: (AMQ-850) add the ability to timeout a consumer to prevent a bad, hung or unused consumer consumer from grabbing messages
[ https://issues.apache.org/activemq/browse/AMQ-850?page=comments#action_36740 ] Maxim Fateev commented on AMQ-850: -- I think ideal solution would include self adjusting prefetch buffer size. At the beginning it couild be 1 but then increased if consumer is so fast that it gets throttled by network latency. If it slows down prefetch size should srink as well. The idea is to maintain queueing time (after being dispatched but before delivered to consumer callback) minimal while not blocking consumer. > add the ability to timeout a consumer to prevent a bad, hung or unused > consumer consumer from grabbing messages > --- > > Key: AMQ-850 > URL: https://issues.apache.org/activemq/browse/AMQ-850 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: james strachan > Fix For: 4.2 > > > If a MessageConsumer is created but not used, it still tends to get its > prefetch-buffer worth of messages. If it does not process them within a > specific time the consumer should either be closed, or the messages unacked > and flushed from the buffer so that the consumer does not hog the messages. > Similarly if a consumer gets a message but then locks up without processing > the message we should lazily kill the consumer releasing and redelivering all > its messages -- 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: [Committing] GERONIMO-2277 Remove TransactionContextManager
The merge is complete. Thanks to everyone for reviewing this one quickly. -dain On Aug 9, 2006, at 9:28 AM, Dain Sundstrom wrote: With votes from Jeff, Jencks and Matt, I am going to committ this patch today, so please let me know if you're going to commit something significant so I can avoid conflicts :) -dain On Aug 7, 2006, at 4:07 PM, Dain Sundstrom wrote: Ok all fixed. Jason fixed the logging issue, and the other problem was that backport-concurrent-util was not in the manifest classpath of the server jar. -dain On Aug 7, 2006, at 10:05 AM, Dain Sundstrom wrote: On Aug 7, 2006, at 12:09 AM, David Jencks wrote: The notcm branch builds fine for me under m2 but the j2ee-jetty server does not start for me at the moment. Apparently the TransactionManager doesn't start. As noted in another post I don't get any log files which has so far inhibited me from investigating further. Is this just my setup? Don't know. I'll take a look -dain
[jira] Closed: (GERONIMO-2277) Remove TransactionContextManager
[ http://issues.apache.org/jira/browse/GERONIMO-2277?page=all ] Dain Sundstrom closed GERONIMO-2277. > Remove TransactionContextManager > > > Key: GERONIMO-2277 > URL: http://issues.apache.org/jira/browse/GERONIMO-2277 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: transaction manager >Reporter: Dain Sundstrom > Assigned To: Dain Sundstrom > Fix For: 1.2 > > Attachments: GERONIMO-2277.patch > > > If you use the Geronimo TransactionContextManager, you can't use the > TransactionManager interface directly since the TCM needs to know about all > TM calls. Additionally, to use the TCM you must demarcate all changes in > "component context" by starting an unspecified transaction context. This is > all quite invasive and makes it hard to use our code in third part > environments such as Spring or plain old Tomcat. > I propose we remove the TransactionContextManager and replaced all uses with > a plain old TransactionManager. This will also allow us to removed all code > from web containers, app client and timer that was simply demarcating an > unspecified transaction context, which is no longer needed. -- 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: (AMQ-855) Add support for prefetchSize = 0
[ https://issues.apache.org/activemq/browse/AMQ-855?page=comments#action_36739 ] Maxim Fateev commented on AMQ-855: -- #1. I wasn't presize. Yes it holds references. But it doesn't really matter as these references are locked to the particular subsription and are not reassigned while this subscription is alive. #2. I think prefetch buffers are used to boost peformance. Pull model doesn't preclude their use. The question is if messages are assigned to subscriptions up front or only when space is available in prefetch buffers. I've already voted for it. > 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, 4.0.1, 4.0.2 > Environment: any >Reporter: Vadim Pesochinskiy >Priority: Critical > Fix For: 4.2 > > > 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] Commented: (AMQ-855) Add support for prefetchSize = 0
[ https://issues.apache.org/activemq/browse/AMQ-855?page=comments#action_36738 ] Vadim Pesochinskiy commented on AMQ-855: #1. I thought that pending holds references, not messages. When message is actually dispatched it will become unavailable to other PrefetchSubscriptions. Maybe I am wrong. #2. I thought that push was employed primarely to boost performance. Whatever the reasons are, if you feel that this should be resolve could you please vote for it? Thanks a lot. Vadim. > 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, 4.0.1, 4.0.2 > Environment: any >Reporter: Vadim Pesochinskiy >Priority: Critical > Fix For: 4.2 > > > 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] Commented: (XBEAN-33) [RTC] Add a new Wiki source generator that generates wiki markup so that reference docs can be pasted into confluence.
[ http://issues.apache.org/jira/browse/XBEAN-33?page=comments#action_12427051 ] David Blevins commented on XBEAN-33: You can paste automatically with the swizzle-confluence library. See http://docs.codehaus.org/display/SWIZZLE/Swizzle+Confluence > [RTC] Add a new Wiki source generator that generates wiki markup so that > reference docs can be pasted into confluence. > -- > > Key: XBEAN-33 > URL: http://issues.apache.org/jira/browse/XBEAN-33 > Project: XBean > Issue Type: RTC > Components: spring, maven-plugin >Reporter: Hiram Chirino > Assigned To: Hiram Chirino > Fix For: 2.6 > > Attachments: XBEAN-33.patch > > > Added a new generator plugin. -- 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: (AMQ-855) Add support for prefetchSize = 0
[ https://issues.apache.org/activemq/browse/AMQ-855?page=comments#action_36737 ] Maxim Fateev commented on AMQ-855: -- I think the failure scenario (slow consumer) is very common one and should be supported by ActiveMQ. The root cause of the problem is not the prefetch size. As James pointed out setting it to one is good enough. But the problem is that messages are assigned to consumers as soon as they are dispatched. If consuemer's prefetch buffer is full then they are kept in "pending" list (see PrefetchSubscription) implementation. This list is essentially unlimited. So messages assigned to slow consumer are never redispatched to overs unless slow consumer is disconnected or the whole broker is bounced. Standard way to solve this issue is to use "pull" model instead of "push". I.e. messages are not assigned to consumers up front but given to them when requested. I understand that "push" dispatch model of ActiveMQ is due to desire to support "selector expressions". But it doesn't mean that product should be unusable for customers that do not use selectors at all. > 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, 4.0.1, 4.0.2 > Environment: any >Reporter: Vadim Pesochinskiy >Priority: Critical > Fix For: 4.2 > > > 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] Reopened: (AMQ-855) Add support for prefetchSize = 0
[ https://issues.apache.org/activemq/browse/AMQ-855?page=all ] Maxim Fateev reopened AMQ-855: -- > 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, 4.0.1, 4.0.2 > Environment: any >Reporter: Vadim Pesochinskiy >Priority: Critical > Fix For: 4.2 > > > 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] Commented: (AMQ-855) Add support for prefetchSize = 0
[ https://issues.apache.org/activemq/browse/AMQ-855?page=comments#action_36736 ] Vadim Pesochinskiy commented on AMQ-855: > e.g. if we did implement prefetch of zero - which means don't deliver a > message to a consumer at all - > unless they perform a consumer.receive() - even then, the consumer could then > hang/deadlock and never > actually acknowledge or process the message. If consumer hangs and message is not processed is a different problem. Even if messages are lost in such case, nobody would blame AMQ. If you kill consumer and re-despatch, it would be brilliant. But if my consumers do not hang, crash or burn, can I just get my messages? James, could you please re-open this issue? I spend 1 month working on this project and now I will have to throw it all away and do explaining with my manager. I cannot apply my own fix, you will not fix it. What am I supposed to do now? > 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, 4.0.1, 4.0.2 > Environment: any >Reporter: Vadim Pesochinskiy >Priority: Critical > Fix For: 4.2 > > > 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] Commented: (SM-521) Tuning parameters configuration
[ https://issues.apache.org/activemq/browse/SM-521?page=comments#action_36735 ] Guillaume Nodet commented on SM-521: I'd like non lightweight components to be able to have throttling properties configured as well. In xbean, the tag only identifies the "component" property of the enclosing ActivationSpec, so you can not put attributes on this tag. These properties are also specific to ServiceMix container and really independant of the component itself. They are used on the DevlieryChannel for the component, but the component has really no control on them. I think these parameters should be on the activationSpec. ... For standard JBI components deployed using std JBI packaging, we need to define some abstract activationSpec. without any component defined. When a component is installed using the hot deploy dir or ant tasks / jmx, the container would look for a registered activationSpec with the same component name and use these values to configure the ComponentMBeanImpl and / or DeliveryChannelImpl. Furthermore, I think these properties should be the default value. If someone configure these properties using jms (as it is already possible), these properties should be persisted somewhere. It could be in the status file associated with the component (see ComponentMBeanImpl.stateFile). These values should override any value set in the activationSpec. Thus, there is no need for components to inherit a servicemix specific class, as these properties are controlled by the jbi container itself, and not used at all by the components the component, maybe > Tuning parameters configuration > --- > > Key: SM-521 > URL: https://issues.apache.org/activemq/browse/SM-521 > Project: ServiceMix > Issue Type: Improvement > Components: servicemix-core >Reporter: Guillaume Nodet > Fix For: 3.0-M3 > > > We need to provide a way to configure tuning parameters for servicemix: > * thread pools (core + flows + seda queues + components ) > * queues (delivery channels + seda queues) > * component throttling > This may need a way to configure dummy activationSpecs (with no components, > only the component name) > so that we can configure these parameters when using JBI std installation -- 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: (GERONIMO-2248) Applications portlets: List Parent and Child components against each component
[ http://issues.apache.org/jira/browse/GERONIMO-2248?page=comments#action_12427040 ] Joe Bohn commented on GERONIMO-2248: I agree with Matt that we should at least print the stack trace for the should not occur scenario. I also agree with Aaron on the visual aspects of the view and would like to see a link to show this on a second screen (and thereby keeping the commands on the right ... there are a few exceptions to those but we need to fix those). That would also provide more space if we want to show multiple relationships (as Aaron pointed out with the WAR-in-EAR, etc..) If those two things were done, I think it would be good enough to go ahead and integrate (with appropriate rtc votes of course). We could continue to work out more details like transitive dependencies in subsequent changes or possibly even replace the linked to view with a network view of dependencies highlighting the item in question. > Applications portlets: List Parent and Child components against each component > -- > > Key: GERONIMO-2248 > URL: http://issues.apache.org/jira/browse/GERONIMO-2248 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.2, 1.1, 1.1.1 >Reporter: Vamsavardhana Reddy > Fix For: 1.2 > > Attachments: GERONIMO-2248.patch > > > Applications portlets currently provide component status and links to > start/stop/restart/uninstall. They do not provide a listing of parent > components and child components. > If child components are listed, a user will immediatley know what all > configurations will be stopped if a particular component is stopped. > How is it useful? > I have stopped " geronimo/system-database/1.1.1-SNAPSHOT/car" to test > something. Only after an error HTTP 404 was displayed next, I realized that > the admin console had a dependency on > "geronimo/system-database/1.1.1-SNAPSHOT/car". Had there been a Child > Components listing next to "geronimo/system-database/1.1.1-SNAPSHOT/car", it > would have avoided the surprise. -- 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: (XBEAN-36) [RTC] Support annotating properties with the ProperyEditor that should be used when wiring in the value.
[
http://issues.apache.org/jira/browse/XBEAN-36?page=comments#action_12427039 ]
Hiram Chirino commented on XBEAN-36:
good catch. I'll fix it in a jiffy.
> [RTC] Support annotating properties with the ProperyEditor that should be
> used when wiring in the value.
>
>
> Key: XBEAN-36
> URL: http://issues.apache.org/jira/browse/XBEAN-36
> Project: XBean
> Issue Type: New Feature
> Components: spring
>Reporter: Hiram Chirino
> Assigned To: Hiram Chirino
> Fix For: 2.6
>
> Attachments: XBEAN-36.patch
>
>
> This patch allows you to configure a PropertyEditor for any property. For
> example, if you annotate a property as follows:
>/**
> * Sets the amount of beer remaining in the keg (in ml)
> *
> * @org.apache.xbean.Property
> propertyEditor="org.apache.xbean.spring.example.MilliLittersPropertyEditor"
> * @param remaining
> */
> public void setRemaining(long remaining) {
> this.remaining = remaining;
> }
> Then when you configure the value of the 'remaining' property in xbean then
> the MilliLittersPropertyEditor will be used to convert the string value to a
> long. In the test case, our MilliLittersPropertyEditor can handle converting
> different units of measurement to ml. For example:
> http://xbean.apache.org/schemas/pizza";>
>
>
>
>
>
--
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-2248) Applications portlets: List Parent and Child components against each component
[ http://issues.apache.org/jira/browse/GERONIMO-2248?page=comments#action_12427038 ] Aaron Mulder commented on GERONIMO-2248: I'm not real happy with this: * It puts data to the right of commands, where usually commands are on the far right * It shows Module IDs without any more useful data for the children * It increases the height of the display * we should think about whether to show child modules such as WAR-within-EAR or child modules such as WAR-dependent-on-DB-pool or both * if we're trying to show everything that will be stopped if the module is stopped, the list should show transitive children, and the entry for e.g. rmi-naming will be unimaginably huge * I'm not sure it's a good idea to load the Confiiguration if it's not already loaded I think it would be better to hyperlink the module ID in the current display and introduce a new screen with more module details and move this kind of stuff to that screen. > Applications portlets: List Parent and Child components against each component > -- > > Key: GERONIMO-2248 > URL: http://issues.apache.org/jira/browse/GERONIMO-2248 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.2, 1.1, 1.1.1 >Reporter: Vamsavardhana Reddy > Fix For: 1.2 > > Attachments: GERONIMO-2248.patch > > > Applications portlets currently provide component status and links to > start/stop/restart/uninstall. They do not provide a listing of parent > components and child components. > If child components are listed, a user will immediatley know what all > configurations will be stopped if a particular component is stopped. > How is it useful? > I have stopped " geronimo/system-database/1.1.1-SNAPSHOT/car" to test > something. Only after an error HTTP 404 was displayed next, I realized that > the admin console had a dependency on > "geronimo/system-database/1.1.1-SNAPSHOT/car". Had there been a Child > Components listing next to "geronimo/system-database/1.1.1-SNAPSHOT/car", it > would have avoided the surprise. -- 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: Tagging the 2.1.1 release of OpenEJB
Sounds good. --kevan On Aug 9, 2006, at 3:02 PM, Matt Hogstrom wrote: Looks like the testing of OpenEJB is good. I'd like to go ahead with the tagging and bagging of OEJB 2.1.1. If there are no objections I'll update branches/v2_1_1 to be 2.1.1 and then move it to tags. Objections?
[jira] Updated: (GERONIMO-2305) geronimo.kernel.classloader.JarFileUrlStreamHandler fails with Trinidad
[ http://issues.apache.org/jira/browse/GERONIMO-2305?page=all ] Chris Herborth updated GERONIMO-2305: - Attachment: devSignup.war The first WAR I uploaded had a couple of errors; thanks to Matthias for pointing them out. This is the fixed WAR file, which apparently works as expected on plain Tomcat. > geronimo.kernel.classloader.JarFileUrlStreamHandler fails with Trinidad > --- > > Key: GERONIMO-2305 > URL: http://issues.apache.org/jira/browse/GERONIMO-2305 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 1.1 > Environment: Geronimo-jetty-1.1 running in Java 1.5.0_06 on Mac OS X > or Java 1.5.0_06 on XP > Aug. 6 Trinidad snapshot - > http://people.apache.org/maven-snapshot-repository/org/apache/myfaces/trinidad/ >Reporter: Chris Herborth >Priority: Blocker > Attachments: devSignup.war, devSignup.war > > > Web application (built with current MyFaces and Trinidad) crashes during page > loading with this stack trace: > 7-Aug-2006 10:40:40 AM > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider getCapabilities > SEVERE: could not get capabilities from capabilities document > java.lang.IllegalArgumentException: Expected url [jar:file:/C:/Documents and > Settings/chrish/Desktop/geronimo-1.1/repository/default/devsignup/1154961598406/devsignup-1154961598406.war/WEB-INF/lib/adf-faces-impl-incubator-m1-SNAPSHOT.jar!/META-INF/agent/capabilities.xml], > but was [jar:file:/C:/Documents and > Settings/chrish/Desktop/geronimo-1.1/repository/default/devsignup/1154961598406/devsignup-1154961598406.war/WEB-INF/lib/adf-faces-impl-incubator-m1-SNAPSHOT.jar!/META-INF/agent/htmlBasic.xml] > at > org.apache.geronimo.kernel.classloader.JarFileUrlStreamHandler.openConnection(JarFileUrlStreamHandler.java:63) > at java.net.URL.openConnection(Unknown Source) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilityDataDocumentParser.parse(CapabilityDataDocumentParser.java:60) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:315) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:226) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:293) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:212) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getDefaultAgentCapabilities(CapabilitiesDocument.java:117) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument.(CapabilitiesDocument.java:38) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocumentParser.endElement(CapabilitiesDocumentParser.java:184) > at > org.apache.myfaces.adfinternal.share.xml.TreeBuilder$Handler.endElement(TreeBuilder.java:463) > at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown > Source) > at > org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > at > org.apache.myfaces.adfinternal.share.xml.TreeBuilder.parse(TreeBuilder.java:166) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocumentParser.createInstance(CapabilitiesDocumentParser.java:67) > at > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider._getCapabilityDocument(CapabilitiesProvider.java:128) > at > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider._getCapabilities(CapabilitiesProvider.java:110) > at > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider.getCapabilities(CapabilitiesProvider.java:91) > at > org.apache.myfaces.adfinternal.agent.AdfFacesAgentImpl._getCapabilityMap(AdfFacesAgentImpl.java:263) > at > org.apache.myfaces.adfinternal.agent.AdfFacesAgentImpl._initialize(AdfFacesAgentImpl.java:233) > at > org.apache.myfaces.adfinternal.agent.AdfFacesAgentImpl.(AdfFacesAgentImpl.java:40) > at > org.apache.myfaces.adfinternal.context.AdfFacesContextImpl.getAgent(AdfFacesContextImpl.java:533) >
Re: Tagging the 2.1.1 release of OpenEJB
On Aug 9, 2006, at 12:02 PM, Matt Hogstrom wrote: Looks like the testing of OpenEJB is good. I'd like to go ahead with the tagging and bagging of OEJB 2.1.1. If there are no objections I'll update branches/v2_1_1 to be 2.1.1 and then move it to tags. Great! Thanks for doing the release work, very appreciated! I assume we also owe Kevan a big thanks for manually running the TCK for us. Thank you Kevan! If you need help publishing the binaries, let me know. -David
[jira] Commented: (GERONIMO-2305) geronimo.kernel.classloader.JarFileUrlStreamHandler fails with Trinidad
[ http://issues.apache.org/jira/browse/GERONIMO-2305?page=comments#action_12427020 ] Matthias Weßendorf commented on GERONIMO-2305: -- that example is not running in tomcat (not tested geronimo), because wrong web.xml and wrong pages (using "old" taglibs from Trinidad) > geronimo.kernel.classloader.JarFileUrlStreamHandler fails with Trinidad > --- > > Key: GERONIMO-2305 > URL: http://issues.apache.org/jira/browse/GERONIMO-2305 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 1.1 > Environment: Geronimo-jetty-1.1 running in Java 1.5.0_06 on Mac OS X > or Java 1.5.0_06 on XP > Aug. 6 Trinidad snapshot - > http://people.apache.org/maven-snapshot-repository/org/apache/myfaces/trinidad/ >Reporter: Chris Herborth >Priority: Blocker > Attachments: devSignup.war > > > Web application (built with current MyFaces and Trinidad) crashes during page > loading with this stack trace: > 7-Aug-2006 10:40:40 AM > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider getCapabilities > SEVERE: could not get capabilities from capabilities document > java.lang.IllegalArgumentException: Expected url [jar:file:/C:/Documents and > Settings/chrish/Desktop/geronimo-1.1/repository/default/devsignup/1154961598406/devsignup-1154961598406.war/WEB-INF/lib/adf-faces-impl-incubator-m1-SNAPSHOT.jar!/META-INF/agent/capabilities.xml], > but was [jar:file:/C:/Documents and > Settings/chrish/Desktop/geronimo-1.1/repository/default/devsignup/1154961598406/devsignup-1154961598406.war/WEB-INF/lib/adf-faces-impl-incubator-m1-SNAPSHOT.jar!/META-INF/agent/htmlBasic.xml] > at > org.apache.geronimo.kernel.classloader.JarFileUrlStreamHandler.openConnection(JarFileUrlStreamHandler.java:63) > at java.net.URL.openConnection(Unknown Source) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilityDataDocumentParser.parse(CapabilityDataDocumentParser.java:60) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:315) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:226) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:293) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:212) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getDefaultAgentCapabilities(CapabilitiesDocument.java:117) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument.(CapabilitiesDocument.java:38) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocumentParser.endElement(CapabilitiesDocumentParser.java:184) > at > org.apache.myfaces.adfinternal.share.xml.TreeBuilder$Handler.endElement(TreeBuilder.java:463) > at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown > Source) > at > org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > at > org.apache.myfaces.adfinternal.share.xml.TreeBuilder.parse(TreeBuilder.java:166) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocumentParser.createInstance(CapabilitiesDocumentParser.java:67) > at > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider._getCapabilityDocument(CapabilitiesProvider.java:128) > at > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider._getCapabilities(CapabilitiesProvider.java:110) > at > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider.getCapabilities(CapabilitiesProvider.java:91) > at > org.apache.myfaces.adfinternal.agent.AdfFacesAgentImpl._getCapabilityMap(AdfFacesAgentImpl.java:263) > at > org.apache.myfaces.adfinternal.agent.AdfFacesAgentImpl._initialize(AdfFacesAgentImpl.java:233) > at > org.apache.myfaces.adfinternal.agent.AdfFacesAgentImpl.(AdfFacesAgentImpl.java:40) > at > org.apache.myfaces.adfinternal.context.AdfFacesContextImpl.getAgent(AdfFacesContextImpl.java:533) > at > org.apache.myface
[jira] Assigned: (GERONIMO-2169) Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding tagged version of OpenEJB (not a branch)
[ http://issues.apache.org/jira/browse/GERONIMO-2169?page=all ] Matt Hogstrom reassigned GERONIMO-2169: --- Assignee: Matt Hogstrom (was: Kevan Miller) > Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding > tagged version of OpenEJB (not a branch) > --- > > Key: GERONIMO-2169 > URL: http://issues.apache.org/jira/browse/GERONIMO-2169 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: buildsystem >Affects Versions: 1.1.1 >Reporter: Kevan Miller > Assigned To: Matt Hogstrom > Fix For: 1.1.1 > > > The m:co goal in tags/1.1.0 will checkout the branches/2.1 version of > OpenEJB. It should be checking out tags/v2_1. > We need to fix in Geronimo 1.1.1. The release process should be updated to > insure we don't repeat this mistake in the future. -- 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: Drop the m1 build
So far there have been no negative reponses, and several PMC +1s Can we start an official vote and then plan for the removal of m1? --jason On Aug 9, 2006, at 1:24 PM, Matt Hogstrom wrote: +1 Dain Sundstrom wrote: I propose we remove the m1 build. It has been broken for several days now and no one has noticed. Here is my vote: +1 to remove the m1 build -dain
Re: Java Service Wrapper or Commons Daemon?
I've never used the commons daemon stuff, but everyone I know uses jsw, so I think it is the obvious choice. -dain On Aug 9, 2006, at 12:50 PM, Jason Dillon wrote: I guess :-P Well, lemme know what you guys end up using, cause we will do the same for Geronimo. --jason On Aug 9, 2006, at 12:40 PM, James Strachan wrote: On 8/9/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Both of these look like then use natives... which I don't really understand. For windows... sure, but do they need natives for POSIX systems? Yes - they are used to do things like monitor, kill and restart JVMs if they hang up etc. -- James --- http://radio.weblogs.com/0112098/
Re: Drop the m1 build
+1 Dain Sundstrom wrote: I propose we remove the m1 build. It has been broken for several days now and no one has noticed. Here is my vote: +1 to remove the m1 build -dain
[jira] Closed: (GERONIMO-2269) Error after redeploy (with no version in module ID)
[ http://issues.apache.org/jira/browse/GERONIMO-2269?page=all ] Matt Hogstrom closed GERONIMO-2269. --- Fix Version/s: 1.1.2 1.2 Resolution: Fixed Sending 1.1.1/modules/kernel/src/java/org/apache/geronimo/kernel/config/SimpleConfigurationManager.java Transmitting file data . Committed revision 430135. Decided to include in 1.1.1 since we're waiting for another blocker patch to come in. > Error after redeploy (with no version in module ID) > --- > > Key: GERONIMO-2269 > URL: http://issues.apache.org/jira/browse/GERONIMO-2269 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: deployment, kernel >Affects Versions: 1.1 >Reporter: Aaron Mulder > Assigned To: Aaron Mulder > Fix For: 1.1.1, 1.1.2, 1.2 > > Attachments: 2269-fix-jndi-while-reloading.patch, > 2269-fix-jndi-while-reloading.patch > > > I deployed a web application (including a resource-ref to a database pool) > successfully, with a module ID containing only an artifact element. > I changed the web.xml and redeployed it. It failed due to a syntax error in > web.xml (I changed the login page to not start with a / and it complained; > apparently the / is necessary). The application still appeared to be > running, though I didn't test it. > I fixed the web.xml and redeployed it. It failed with the following error. > It seems that after the redeploy the JNDI entry for the data source was > invalid? > UPDATE: a simple redeploy of the working application causes the error -- it's > not necessary to have the failed redeploy in between. > 11:57:44,865 ERROR [ContextLoader] Context initialization failed > org.springframework.beans.factory.BeanCreationException: Error creating bean > with name 'DataSource' defined in resource [/WEB-INF/applicationContext.xml] > of ServletContext: Initialization of bean failed; nested exception is > javax.naming.NamingException: Could not look up : env/jdbc/Database > javax.naming.NamingException: Could not look up : env/jdbc/Database [Root > exception is org.apache.geronimo.kernel.proxy.DeadProxyException: Proxy is no > longer valid] > at > org.apache.geronimo.naming.enc.CachingReference.resolveReference(CachingReference.java:59) > at > org.apache.geronimo.naming.enc.CachingReference.get(CachingReference.java:45) > at > org.apache.geronimo.naming.enc.AbstractReadOnlyContext.lookup(AbstractReadOnlyContext.java:86) > at > org.apache.geronimo.naming.java.RootContext.lookup(RootContext.java:51) > at javax.naming.InitialContext.lookup(InitialContext.java:347) > at > org.springframework.jndi.JndiTemplate$1.doInContext(JndiTemplate.java:120) > at org.springframework.jndi.JndiTemplate.execute(JndiTemplate.java:85) > at org.springframework.jndi.JndiTemplate.lookup(JndiTemplate.java:117) > at > org.springframework.jndi.AbstractJndiLocator.lookup(AbstractJndiLocator.java:181) > at > org.springframework.jndi.AbstractJndiLocator.afterPropertiesSet(AbstractJndiLocator.java:171) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:801) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:249) > at > org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:177) > at > org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:159) > at > org.springframework.beans.factory.support.DefaultListableBeanFactory.preInstantiateSingletons(DefaultListableBeanFactory.java:177) > at > org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:268) > at > org.springframework.web.context.support.XmlWebApplicationContext.refresh(XmlWebApplicationContext.java:131) > at > org.springframework.web.context.ContextLoader.createWebApplicationContext(ContextLoader.java:156) > at > org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:97) > at > org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:48) > at > org.mortbay.jetty.servlet.WebApplicationContext.doStart(WebApplicationContext.java:495) > at > org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:401) > at org.mortbay.util.Container.start(Container.java:72) > at > org.apache.geronimo.jetty.JettyWebAppContext.doStart(JettyWebAppContext.java:389) > at > org.apache.geronimo.gbean.ru
Re: Drop the m1 build
Its probably important to note that if the TCK passes against an m1 build of 1.2, that does not mean that it will also pass against an m2 build. So, I don't see any reason to keep m1 around anymore. * * * Kevan, what needs to be done to get the TCK runnable against the m2 build of 1.2? --jason On Aug 9, 2006, at 1:03 PM, Kevan Miller wrote: It definitely impacts aspects of TCK. Agreed that it's important that we hear from the people who are going to get those aspects of the TCK working... ;-) At this point, I don't see any harm in dropping m1. It's not going to add any additional work and will drive our adoption of m2... --kevan On Aug 7, 2006, at 11:26 PM, Jeff Genender wrote: I am all for dropping the m1 build too... But I think the people who run the TCK should speak up first as this may impact them significantly... Jeff Alan D. Cabrera wrote: Dain Sundstrom wrote: I propose we remove the m1 build. It has been broken for several days now and no one has noticed. Here is my vote: +1 to remove the m1 build -dain +1 Regards, Alan
Re: [jira] Commented: (AMQ-850) add the ability to timeout a consumer to
On 8/9/06, Komandur <[EMAIL PROTECTED]> wrote: I read the link, reread the thread & I misunderstood the prefetch feature ... the broker is pushing messages into the clientside pre-fetch buffers upto the limit. Here are some ideas, let me know what you think ... 1. can we use an 'elastic prefetch' buffer based on a sliding window (like in TCP) - this reacts to client (mis)behavior We could start with a prefetch of 1 and increase it over time for well behaving clients. However it doesn't fix the problem as a mis-behaving consumer could still hog at least one message - though this would reduce the imact from 1000 or so to 1. 2. When the broker detects a misbehaving client, reclaim the unAcked messages for other active consumers (and make the window size 0 or 1 in step 1 above) If a client/connection misbehaves (e.g. becomes inactive) then the connection is closed and all consumers are closed too causing all their unacked messages to be redelivered. The issue AMQ-850 is specifically to reclaim the prefetch buffer of unacked messages from a misbehaving consumer. e.g. if 1 consumer goes bad yet the rest of the client appears to be fine such as if a consumer is created but never used or a consumer locks up before grabbing another message or during the processing of a message. -- James --- http://radio.weblogs.com/0112098/
Re: Drop the m1 build
It definitely impacts aspects of TCK. Agreed that it's important that we hear from the people who are going to get those aspects of the TCK working... ;-) At this point, I don't see any harm in dropping m1. It's not going to add any additional work and will drive our adoption of m2... --kevan On Aug 7, 2006, at 11:26 PM, Jeff Genender wrote: I am all for dropping the m1 build too... But I think the people who run the TCK should speak up first as this may impact them significantly... Jeff Alan D. Cabrera wrote: Dain Sundstrom wrote: I propose we remove the m1 build. It has been broken for several days now and no one has noticed. Here is my vote: +1 to remove the m1 build -dain +1 Regards, Alan
Re: Java Service Wrapper or Commons Daemon?
I guess :-P Well, lemme know what you guys end up using, cause we will do the same for Geronimo. --jason On Aug 9, 2006, at 12:40 PM, James Strachan wrote: On 8/9/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Both of these look like then use natives... which I don't really understand. For windows... sure, but do they need natives for POSIX systems? Yes - they are used to do things like monitor, kill and restart JVMs if they hang up etc. -- James --- http://radio.weblogs.com/0112098/
Re: [jira] Commented: (AMQ-850) add the ability to timeout a consumer to
I read the link, reread the thread & I misunderstood the prefetch feature ... the broker is pushing messages into the clientside pre-fetch buffers upto the limit. Here are some ideas, let me know what you think ... 1. can we use an 'elastic prefetch' buffer based on a sliding window (like in TCP) - this reacts to client (mis)behavior 2. When the broker detects a misbehaving client, reclaim the unAcked messages for other active consumers (and make the window size 0 or 1 in step 1 above) Thanks Regards - Sridhar Komandur -- View this message in context: http://www.nabble.com/-jira--Created%3A-%28AMQ-850%29-add-the-ability-to-timeout-a-prefetch-buffer-to-prevent-a-single-consumer-grabbing-messages-tf2014900.html#a5732625 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Tagging the 2.1.1 release of OpenEJB
Sounds good to me. Thanks, Aaorn On 8/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Looks like the testing of OpenEJB is good. I'd like to go ahead with the tagging and bagging of OEJB 2.1.1. If there are no objections I'll update branches/v2_1_1 to be 2.1.1 and then move it to tags. Objections?
Re: Java Service Wrapper or Commons Daemon?
On 8/9/06, Jason Dillon <[EMAIL PROTECTED]> wrote: Both of these look like then use natives... which I don't really understand. For windows... sure, but do they need natives for POSIX systems? Yes - they are used to do things like monitor, kill and restart JVMs if they hang up etc. -- James --- http://radio.weblogs.com/0112098/
Re: Java Service Wrapper or Commons Daemon?
Both of these look like then use natives... which I don't really understand. For windows... sure, but do they need natives for POSIX systems? --jason On Aug 9, 2006, at 4:41 AM, James Strachan wrote: Anyone have any experience of these 2 solutions to know which one is the best to use when creating a windows/unix service? http://wrapper.tanukisoftware.org/doc/english/introduction.html http://jakarta.apache.org/commons/daemon/index.html It'd be nice to have a service for ActiveMQ - am just not sure which one we should use. Clearly the latter is also hosted at Apache so we're more likely to be able to patch it if it has issues. The latter is also used by Tomcat so is very well used. Anyone used both before who could offer feedback? -- James --- http://radio.weblogs.com/0112098/
[jira] Updated: (GERONIMO-2305) geronimo.kernel.classloader.JarFileUrlStreamHandler fails with Trinidad
[ http://issues.apache.org/jira/browse/GERONIMO-2305?page=all ] Chris Herborth updated GERONIMO-2305: - Attachment: devSignup.war Install via Geronimo console, runs at /devSignup and is pretty trivial. signup.jsp is the root document, and you can ignore temperature-converter.jsp entirely because Ajax4jsf is disabled in this build. > geronimo.kernel.classloader.JarFileUrlStreamHandler fails with Trinidad > --- > > Key: GERONIMO-2305 > URL: http://issues.apache.org/jira/browse/GERONIMO-2305 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 1.1 > Environment: Geronimo-jetty-1.1 running in Java 1.5.0_06 on Mac OS X > or Java 1.5.0_06 on XP > Aug. 6 Trinidad snapshot - > http://people.apache.org/maven-snapshot-repository/org/apache/myfaces/trinidad/ >Reporter: Chris Herborth >Priority: Blocker > Attachments: devSignup.war > > > Web application (built with current MyFaces and Trinidad) crashes during page > loading with this stack trace: > 7-Aug-2006 10:40:40 AM > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider getCapabilities > SEVERE: could not get capabilities from capabilities document > java.lang.IllegalArgumentException: Expected url [jar:file:/C:/Documents and > Settings/chrish/Desktop/geronimo-1.1/repository/default/devsignup/1154961598406/devsignup-1154961598406.war/WEB-INF/lib/adf-faces-impl-incubator-m1-SNAPSHOT.jar!/META-INF/agent/capabilities.xml], > but was [jar:file:/C:/Documents and > Settings/chrish/Desktop/geronimo-1.1/repository/default/devsignup/1154961598406/devsignup-1154961598406.war/WEB-INF/lib/adf-faces-impl-incubator-m1-SNAPSHOT.jar!/META-INF/agent/htmlBasic.xml] > at > org.apache.geronimo.kernel.classloader.JarFileUrlStreamHandler.openConnection(JarFileUrlStreamHandler.java:63) > at java.net.URL.openConnection(Unknown Source) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilityDataDocumentParser.parse(CapabilityDataDocumentParser.java:60) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:315) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:226) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:293) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:212) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getDefaultAgentCapabilities(CapabilitiesDocument.java:117) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument.(CapabilitiesDocument.java:38) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocumentParser.endElement(CapabilitiesDocumentParser.java:184) > at > org.apache.myfaces.adfinternal.share.xml.TreeBuilder$Handler.endElement(TreeBuilder.java:463) > at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown > Source) > at > org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown > Source) > at > org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown > Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) > at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) > at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) > at > org.apache.myfaces.adfinternal.share.xml.TreeBuilder.parse(TreeBuilder.java:166) > at > org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocumentParser.createInstance(CapabilitiesDocumentParser.java:67) > at > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider._getCapabilityDocument(CapabilitiesProvider.java:128) > at > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider._getCapabilities(CapabilitiesProvider.java:110) > at > org.apache.myfaces.adfinternal.agent.CapabilitiesProvider.getCapabilities(CapabilitiesProvider.java:91) > at > org.apache.myfaces.adfinternal.agent.AdfFacesAgentImpl._getCapabilityMap(AdfFacesAgentImpl.java:263) > at > org.apache.myfaces.adfinternal.agent.AdfFacesAgentImpl._initialize(AdfFacesAgentImpl.java:233) > at > org.apache.myfaces.adfinternal.agent.AdfFacesAgentImpl.(AdfFacesAgentImpl.java:40) > at > org.apache.myfaces.adfinternal.context.AdfFacesContextImpl.getAgent(AdfFacesContext
[jira] Closed: (GERONIMO-2264) Created branches/1.1.1 to start release process
[ http://issues.apache.org/jira/browse/GERONIMO-2264?page=all ] Matt Hogstrom closed GERONIMO-2264. --- Resolution: Fixed Branch was completed and now entering re-entry. > Created branches/1.1.1 to start release process > --- > > Key: GERONIMO-2264 > URL: http://issues.apache.org/jira/browse/GERONIMO-2264 > Project: Geronimo > Issue Type: Task > Security Level: public(Regular issues) >Affects Versions: 1.1.1 >Reporter: Matt Hogstrom > Assigned To: Matt Hogstrom > Fix For: 1.1.1 > > > svn cp https://svn.apache.org/repos/asf/geronimo/branches/1.1 > https://svn.apache.org/repos/asf/geronimo/branches/1.1.1 > Committed revision 428093. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-2305) geronimo.kernel.classloader.JarFileUrlStreamHandler fails with Trinidad
geronimo.kernel.classloader.JarFileUrlStreamHandler fails with Trinidad --- Key: GERONIMO-2305 URL: http://issues.apache.org/jira/browse/GERONIMO-2305 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: kernel Affects Versions: 1.1 Environment: Geronimo-jetty-1.1 running in Java 1.5.0_06 on Mac OS X or Java 1.5.0_06 on XP Aug. 6 Trinidad snapshot - http://people.apache.org/maven-snapshot-repository/org/apache/myfaces/trinidad/ Reporter: Chris Herborth Priority: Blocker Web application (built with current MyFaces and Trinidad) crashes during page loading with this stack trace: 7-Aug-2006 10:40:40 AM org.apache.myfaces.adfinternal.agent.CapabilitiesProvider getCapabilities SEVERE: could not get capabilities from capabilities document java.lang.IllegalArgumentException: Expected url [jar:file:/C:/Documents and Settings/chrish/Desktop/geronimo-1.1/repository/default/devsignup/1154961598406/devsignup-1154961598406.war/WEB-INF/lib/adf-faces-impl-incubator-m1-SNAPSHOT.jar!/META-INF/agent/capabilities.xml], but was [jar:file:/C:/Documents and Settings/chrish/Desktop/geronimo-1.1/repository/default/devsignup/1154961598406/devsignup-1154961598406.war/WEB-INF/lib/adf-faces-impl-incubator-m1-SNAPSHOT.jar!/META-INF/agent/htmlBasic.xml] at org.apache.geronimo.kernel.classloader.JarFileUrlStreamHandler.openConnection(JarFileUrlStreamHandler.java:63) at java.net.URL.openConnection(Unknown Source) at org.apache.myfaces.adfinternal.agent.parse.CapabilityDataDocumentParser.parse(CapabilityDataDocumentParser.java:60) at org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:315) at org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:226) at org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:293) at org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getCapabilities(CapabilitiesDocument.java:212) at org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument._getDefaultAgentCapabilities(CapabilitiesDocument.java:117) at org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocument.(CapabilitiesDocument.java:38) at org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocumentParser.endElement(CapabilitiesDocumentParser.java:184) at org.apache.myfaces.adfinternal.share.xml.TreeBuilder$Handler.endElement(TreeBuilder.java:463) at org.apache.xerces.parsers.AbstractSAXParser.endElement(Unknown Source) at org.apache.xerces.impl.XMLNSDocumentScannerImpl.scanEndElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.myfaces.adfinternal.share.xml.TreeBuilder.parse(TreeBuilder.java:166) at org.apache.myfaces.adfinternal.agent.parse.CapabilitiesDocumentParser.createInstance(CapabilitiesDocumentParser.java:67) at org.apache.myfaces.adfinternal.agent.CapabilitiesProvider._getCapabilityDocument(CapabilitiesProvider.java:128) at org.apache.myfaces.adfinternal.agent.CapabilitiesProvider._getCapabilities(CapabilitiesProvider.java:110) at org.apache.myfaces.adfinternal.agent.CapabilitiesProvider.getCapabilities(CapabilitiesProvider.java:91) at org.apache.myfaces.adfinternal.agent.AdfFacesAgentImpl._getCapabilityMap(AdfFacesAgentImpl.java:263) at org.apache.myfaces.adfinternal.agent.AdfFacesAgentImpl._initialize(AdfFacesAgentImpl.java:233) at org.apache.myfaces.adfinternal.agent.AdfFacesAgentImpl.(AdfFacesAgentImpl.java:40) at org.apache.myfaces.adfinternal.context.AdfFacesContextImpl.getAgent(AdfFacesContextImpl.java:533) at org.apache.myfaces.adfinternal.renderkit.core.CoreRenderKit.chooseRenderKit(CoreRenderKit.java:144) at org.apache.myfaces.adfinternal.renderkit.CoreRenderKitFactory.getRenderKit(CoreRenderKitFactory.java:50) at org.apache.myfaces.context.servlet.ServletFacesContextImpl.getRenderKit(ServletFacesContextImpl.java:184) at org.apache.myfaces.adfinternal.context.FacesContextFactoryImpl$CacheRenderKit.getRenderKit(FacesContextFactoryImpl.java:103) at org.apache.myfaces.adfinternal.application.ViewHandlerImp
Re: M2 : car-maven-plugin and geronimo-plugin.xml files
Well, you got me. Given that so many people are heavily into Maven I have to admit ignorance in there. I think Anita had made a comment that she was reusing existing Geronimo code and that you were using something from Plexus. Not everyone has that same mighty mass of knowledge you take for granted :) Thanks for the clarification. Jason Dillon wrote: On Aug 9, 2006, at 8:49 AM, Matt Hogstrom wrote: Also, it sounds like some of the changes are preferences based on style. It would be a fair debate as to one should use Plexus or Geronimo infrastructure for the file delete activity. Are you kidding me? Maven2 is built upon Plexus... Maven2 is a Plexus application. Mojo's the Maven2 plugin system are also Plexus components. All of the major plugins are using the support framework that Plaxus provides to handle these types of tasks. There is absolutely no reason why we need to have duplicate code to delete files in our mojos. This is not style, this is common sense and appropriate reuse of the Maven2 platform for our builds. --jason
Re: [jira] Commented: (AMQ-850) add the ability to timeout a consumer to
Thanks for the reply James. Reading AMQ-855 and this thread, it seemed like messages were stuck in prefetch buffers when the associated consumer behaved. Would you mind some clarification to confirm what I am suggesting is what is happening :-) 1 When are the messages actually moved to prefetch buffer upto its limit ? By "moved" I mean that it is not available to be dispatched to another active consumer. The 'prefetch' had the connotation of preallocating 'yet to be sent' messages to a consumer. 2 *Assuming* a message is put in prefetch buffer associated with a consumer *after* it is sent: is there a notion of message expiry (based on either time or misbehaving client detection) and returning the message to a central pool from which they can be sent to other active consumers ? Thanks Regards - Sridhar -- View this message in context: http://www.nabble.com/-jira--Created%3A-%28AMQ-850%29-add-the-ability-to-timeout-a-prefetch-buffer-to-prevent-a-single-consumer-grabbing-messages-tf2014900.html#a5732254 Sent from the ActiveMQ - Dev forum at Nabble.com.
[jira] Commented: (GERONIMO-1563) [RTC] Make the JACC implementation pluggable
[ http://issues.apache.org/jira/browse/GERONIMO-1563?page=comments#action_12427010 ] Jeff Genender commented on GERONIMO-1563: - +1...same comment as Matt Hogstrom. > [RTC] Make the JACC implementation pluggable > > > Key: GERONIMO-1563 > URL: http://issues.apache.org/jira/browse/GERONIMO-1563 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: security >Affects Versions: 1.2 >Reporter: David Jencks > Assigned To: David Jencks > Attachments: GERONIMO-1563-step2.1-v1-openejb.diff, > GERONIMO-1563-step2.1-v1.diff, GERONIMO-1563-step2.1-v2-openejb.diff, > GERONIMO-1563-step2.1-v2.diff, GERONIMO-1563-step2.1-v4-openejb.diff, > GERONIMO-1563-step2.1-v4.diff > > > Currently we are hardcoded into using our JACC implementation. This means we > can't use third party authorization/security servers such as Tivoli AM. > The runtime hardcoding is that the installation of the spec permissions into > the policy configuration is mixed in with pushing our proprietary > principal-role mapping into the policy configuration. > The build time hardcoding is that the only proprietary security configuration > we accept is our own xml for principal-role mapping, and we insist on it > being present. > Some steps for this: > 1. make separate gbeans for the spec and proprietary access to the policy > configuration. These should be connected by an interface, and the spec gbean > should control the proprietary gbean and pass it the contextIds in the > current application. > 2. The security builder should be partly namespace driven, with the > proprietary xml interpretation driven by the namespace. > 2.a the base security builder should construct the > ApplicationPolicyConfigurationGBean and hand off to the namespace-selected > gbean for the proprietary stuff. > 2.b the proprietary-xml builder should install the "role-mapper" gbean with > the info needed for e.g. principal-role mapping. > When we're done with this we should be able to support e.g. IBM pluggable > JACC implementations that support their role-mapping capabilities by just > writing an xml format and a gbean that pushes role mapping info into their > interfaces. The ibm interfaces are explained here: > http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/topic/com.ibm.websphere.express.doc/info/exp/ae/rsec_jaccspis.html > If anyone knows how other app servers configure the non-spec part of JACC > references would be very much appreciated. -- 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: RTC voting and in particular pluggable jacc issue
Yes...+1I have changed my practice and place a comment in the JIRA. I think I voted before changing my practice ;-) David Jencks wrote: > AFAICT it's not possible to find out from jira when votes on issues were > done, nor do they get comments. Therefore I think we need to ask PMC > members voting on RTC issues to both vote and include a comment > explicitly indicating that they are voting +1 as an official RTC vote. > > In particular GERONIMO-1563 pluggable jacc has 3 pmc votes but only 2 > comments from pmc members specifically indicating a +1 RTC vote. I have > no way to determine if Jeff's vote was before or after he rejoined the > PMC. Jeff, could you clarify? > > thanks > david jencks
Re: M2 : car-maven-plugin and geronimo-plugin.xml files
On Aug 9, 2006, at 8:04 AM, anita kulshreshtha wrote: The patch on July 27th was for m2migration and it is clearly written. Where is it? I keep getting lost in all of the patches. --jason
Re: M2 : car-maven-plugin and geronimo-plugin.xml files
On Aug 9, 2006, at 8:49 AM, Matt Hogstrom wrote: Also, it sounds like some of the changes are preferences based on style. It would be a fair debate as to one should use Plexus or Geronimo infrastructure for the file delete activity. Are you kidding me? Maven2 is built upon Plexus... Maven2 is a Plexus application. Mojo's the Maven2 plugin system are also Plexus components. All of the major plugins are using the support framework that Plaxus provides to handle these types of tasks. There is absolutely no reason why we need to have duplicate code to delete files in our mojos. This is not style, this is common sense and appropriate reuse of the Maven2 platform for our builds. --jason
Tagging the 2.1.1 release of OpenEJB
Looks like the testing of OpenEJB is good. I'd like to go ahead with the tagging and bagging of OEJB 2.1.1. If there are no objections I'll update branches/v2_1_1 to be 2.1.1 and then move it to tags. Objections?
Re: RTC voting and in particular pluggable jacc issue
Agreed, the JIRA coting mechanism is auxilary and only to help show in the review reports, but votes need to be make in comments. The JIRA voting mechanism has no history, does not trigger an email and includes no detail, so this must not be used as official votes. --jason On Aug 9, 2006, at 11:21 AM, David Jencks wrote: AFAICT it's not possible to find out from jira when votes on issues were done, nor do they get comments. Therefore I think we need to ask PMC members voting on RTC issues to both vote and include a comment explicitly indicating that they are voting +1 as an official RTC vote. In particular GERONIMO-1563 pluggable jacc has 3 pmc votes but only 2 comments from pmc members specifically indicating a +1 RTC vote. I have no way to determine if Jeff's vote was before or after he rejoined the PMC. Jeff, could you clarify? thanks david jencks
Re: DayTrader with an AJAX based Web interface
This is definitely not happy in Safari :-( ... and when run from Camino it popped up a little dialog saying that the script was unresponsive, but telling it to continue eventually did display the UI.--jasonOn Aug 9, 2006, at 11:29 AM, Christopher Blythe wrote:All, Here's a first pass at a new Web 2.0, AJAX-based, Web interface for DayTrader! Take a look at and let me know what you think: http://porky.hogstrom.org:8080/dojo_trader/daytrader.html FYI - I highly suggest using Firefox or Mozzilla to view this. Also, thanks to Matt Hogstrom for his assistance. This is merely a first pass that provides all of the operational features of DayTrader "classic", but also leverages the various _javascript_ libraries (widget, io, storage, etc.) within the Dojo toolkit to provide a better user experience. Eventually, I would like for this to serve as an addition to DayTrader 2.0 and would like feedback and other contributions on how we can evolve DayTrader to look less like a traditional browser-based, click-and-wait type application and more like a stand-alone app. I am by no means a _javascript_ or CSS expert, so any help, recommendations, etc. would be gratefully appreciated... Thanks...
Re: RTC voting and in particular pluggable jacc issue
I generally vote and post a comment. I like the idea David. David Jencks wrote: AFAICT it's not possible to find out from jira when votes on issues were done, nor do they get comments. Therefore I think we need to ask PMC members voting on RTC issues to both vote and include a comment explicitly indicating that they are voting +1 as an official RTC vote. In particular GERONIMO-1563 pluggable jacc has 3 pmc votes but only 2 comments from pmc members specifically indicating a +1 RTC vote. I have no way to determine if Jeff's vote was before or after he rejoined the PMC. Jeff, could you clarify? thanks david jencks
[jira] Commented: (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
[ http://issues.apache.org/jira/browse/XBEAN-31?page=comments#action_12427004 ] David Jencks commented on XBEAN-31: --- Matt's version of the patch applies and builds for me, I'll repeat my +1 > [RTC] it would be great if the m2 plugin would automatically add the XSD and > .xsd.html files as artifacts into the build > > > Key: XBEAN-31 > URL: http://issues.apache.org/jira/browse/XBEAN-31 > Project: XBean > Issue Type: Wish > Components: maven-plugin >Reporter: james strachan > Assigned To: Guillaume Nodet > Fix For: 2.6 > > Attachments: XBEAN-31.diff, XBEAN-31.diff, XBEAN-31.matt.diff > > > So that the XSD and HTML reference would be automatically deployed into the > m2 repository. > See the attach-artifact for how to do it manually in each POM. But given how > many projects are using the m2 plugin it would simplify our lives if the m2 > plugin did this for us > http://mojo.codehaus.org/build-helper-maven-plugin/howto.html -- 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: DayTrader with an AJAX based Web interface
Awesome :) Unfortunately it doesn't do well with Safari but I hit it from a Windows IE box and it looks great. Your going to force us to start making some decisions on how to restructure the beast in terms of the config and J2EE componentry going forward. Would you be ammenable to sending in the code and we can put it in the sandbox to play with. Other items for consideration is to add Spring support as well as EJB 3.0 support. Looks excellent. Thanks! Christopher Blythe wrote: All, Here's a first pass at a new Web 2.0, AJAX-based, Web interface for DayTrader! Take a look at and let me know what you think: http://porky.hogstrom.org:8080/dojo_trader/daytrader.html FYI - I highly suggest using Firefox or Mozzilla to view this. Also, thanks to Matt Hogstrom for his assistance. This is merely a first pass that provides all of the operational features of DayTrader "classic", but also leverages the various javascript libraries (widget, io, storage, etc.) within the Dojo toolkit to provide a better user experience. Eventually, I would like for this to serve as an addition to DayTrader 2.0 and would like feedback and other contributions on how we can evolve DayTrader to look less like a traditional browser-based, click-and-wait type application and more like a stand-alone app. I am by no means a javascript or CSS expert, so any help, recommendations, etc. would be gratefully appreciated... Thanks... Chris On 3/16/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: That definitely sounds like an attractive thing to benchmark to me! As with the persistence options, etc. I think it would be best to be able to run it both ways and see what you get with a traditional web interface and compare that to an AJAX-ified interface. Thanks, Aaron On 3/16/06, J. Stan Cox <[EMAIL PROTECTED]> wrote: > Geronimos, > > I've worked on the "Trade" benchmark in the past that has been donated > to Geronimo and is now known as "DayTrader". I think it will grow and > flourish in the open source environment and become a nice showcase for > Geronimo's performance and capabilities. > > I'm interested in adding a rich, AJAX based Web interface to DayTrader > for performance research. DayTrader is a perfect type of application to > leverage AJAX capabilities. I will collapse all of the current web > pages into a single rich page with dynamic and asynchronous updates of > stock prices, user holdings, buys/sells, etc. > > I plan to leverage the DoJo AJAX toolkit which is being pulled into > Apache MyFaces. The basic architecture would look like: > > > browser < -REST- --> DayTrader >DayTrader <--- Java ---> DayTrader > (dojo libs,proxy > servlet Web services J2EE App > javascript)soap/rest transform > > > |--GERONIMO ---| > > There are several variations to this to pursue for performance comparison. > > Any feedback? > > Stan. > > > > >
Re: soap-binding sample error
Thanks a lot! -- View this message in context: http://www.nabble.com/soap-binding-sample-error-tf2079610.html#a5731560 Sent from the ServiceMix - Dev forum at Nabble.com.
[jira] Commented: (XBEAN-36) [RTC] Support annotating properties with the ProperyEditor that should be used when wiring in the value.
[
http://issues.apache.org/jira/browse/XBEAN-36?page=comments#action_12426997 ]
David Jencks commented on XBEAN-36:
---
I _think_ that some jdk 1.5 specific code was installed in this patch -- at
least new IllegalArgumentException(String, Throwable)
Do we aim to preserve jdk 1.4 support?
> [RTC] Support annotating properties with the ProperyEditor that should be
> used when wiring in the value.
>
>
> Key: XBEAN-36
> URL: http://issues.apache.org/jira/browse/XBEAN-36
> Project: XBean
> Issue Type: New Feature
> Components: spring
>Reporter: Hiram Chirino
> Assigned To: Hiram Chirino
> Fix For: 2.6
>
> Attachments: XBEAN-36.patch
>
>
> This patch allows you to configure a PropertyEditor for any property. For
> example, if you annotate a property as follows:
>/**
> * Sets the amount of beer remaining in the keg (in ml)
> *
> * @org.apache.xbean.Property
> propertyEditor="org.apache.xbean.spring.example.MilliLittersPropertyEditor"
> * @param remaining
> */
> public void setRemaining(long remaining) {
> this.remaining = remaining;
> }
> Then when you configure the value of the 'remaining' property in xbean then
> the MilliLittersPropertyEditor will be used to convert the string value to a
> long. In the test case, our MilliLittersPropertyEditor can handle converting
> different units of measurement to ml. For example:
> http://xbean.apache.org/schemas/pizza";>
>
>
>
>
>
--
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: DayTrader with an AJAX based Web interface
All,Here's a first pass at a new Web 2.0, AJAX-based, Web interface for DayTrader! Take a look at and let me know what you think: http://porky.hogstrom.org:8080/dojo_trader/daytrader.htmlFYI - I highly suggest using Firefox or Mozzilla to view this. Also, thanks to Matt Hogstrom for his assistance.This is merely a first pass that provides all of the operational features of DayTrader "classic", but also leverages the various _javascript_ libraries (widget, io, storage, etc.) within the Dojo toolkit to provide a better user experience. Eventually, I would like for this to serve as an addition to DayTrader 2.0 and would like feedback and other contributions on how we can evolve DayTrader to look less like a traditional browser-based, click-and-wait type application and more like a stand-alone app. I am by no means a _javascript_ or CSS expert, so any help, recommendations, etc. would be gratefully appreciated... Thanks...ChrisOn 3/16/06, Aaron Mulder <[EMAIL PROTECTED]> wrote: That definitely sounds like an attractive thing to benchmark to me!As with the persistence options, etc. I think it would be best to be able to run it both ways and see what you get with a traditional webinterface and compare that to an AJAX-ified interface.Thanks,AaronOn 3/16/06, J. Stan Cox < [EMAIL PROTECTED]> wrote:> Geronimos,>> I've worked on the "Trade" benchmark in the past that has been donated> to Geronimo and is now known as "DayTrader". I think it will grow and > flourish in the open source environment and become a nice showcase for> Geronimo's performance and capabilities.>> I'm interested in adding a rich, AJAX based Web interface to DayTrader> for performance research. DayTrader is a perfect type of application to > leverage AJAX capabilities. I will collapse all of the current web> pages into a single rich page with dynamic and asynchronous updates of> stock prices, user holdings, buys/sells, etc.> > I plan to leverage the DoJo AJAX toolkit which is being pulled into> Apache MyFaces. The basic architecture would look like:>>> browser < -REST- --> DayTrader >DayTrader <--- Java ---> DayTrader> (dojo libs,proxy> servlet Web services J2EE App> _javascript_)soap/rest transform >>> |--GERONIMO ---|>> There are several variations to this to pursue for performance comparison.>> Any feedback?>> Stan. >
RTC voting and in particular pluggable jacc issue
AFAICT it's not possible to find out from jira when votes on issues were done, nor do they get comments. Therefore I think we need to ask PMC members voting on RTC issues to both vote and include a comment explicitly indicating that they are voting +1 as an official RTC vote. In particular GERONIMO-1563 pluggable jacc has 3 pmc votes but only 2 comments from pmc members specifically indicating a +1 RTC vote. I have no way to determine if Jeff's vote was before or after he rejoined the PMC. Jeff, could you clarify? thanks david jencks
[jira] Commented: (AMQ-850) add the ability to timeout a consumer to prevent a bad, hung or unused consumer consumer from grabbing messages
[ https://issues.apache.org/activemq/browse/AMQ-850?page=comments#action_36734 ] james strachan commented on AMQ-850: Sridhar: I don't quite follow your suggestion. We kinda do what you suggest - the broker maintains a record of how many messages have been dispatched to which consumer together with maintaining a list of the messages which are targetted for different consumers (i.e. which messages could be sent to a consumer). The act of dispatching a message to a given consumer is the same thing as adding it to its prefetch buffer. Note that the main use of the prefetch buffer is to actually physically send the messages to the consumer as fast as possible - up to the prefetch count - so that they are immediately available on the client side. http://incubator.apache.org/activemq/what-is-the-prefetch-limit-for.html > add the ability to timeout a consumer to prevent a bad, hung or unused > consumer consumer from grabbing messages > --- > > Key: AMQ-850 > URL: https://issues.apache.org/activemq/browse/AMQ-850 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: james strachan > Fix For: 4.2 > > > If a MessageConsumer is created but not used, it still tends to get its > prefetch-buffer worth of messages. If it does not process them within a > specific time the consumer should either be closed, or the messages unacked > and flushed from the buffer so that the consumer does not hog the messages. > Similarly if a consumer gets a message but then locks up without processing > the message we should lazily kill the consumer releasing and redelivering all > its messages -- 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-850) add the ability to timeout a consumer to prevent a bad, hung or unused consumer consumer from grabbing messages
[ https://issues.apache.org/activemq/browse/AMQ-850?page=comments#action_36733 ] james strachan commented on AMQ-850: Vadim: agreed in the case where the consumer just never processes any messages and the receive() method is never called. A consumer would basically be terminated until a call to receive*() which would re-awaken it again. Though the consumer may be in the middle of processing a message but is just taking too long due to some hang/lock (either after calling receive() and not calling commit() / acknowledge() - or be inside a MessageListener method call - and may need to actually be closed preventing any future messages being dispatched. > add the ability to timeout a consumer to prevent a bad, hung or unused > consumer consumer from grabbing messages > --- > > Key: AMQ-850 > URL: https://issues.apache.org/activemq/browse/AMQ-850 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: james strachan > Fix For: 4.2 > > > If a MessageConsumer is created but not used, it still tends to get its > prefetch-buffer worth of messages. If it does not process them within a > specific time the consumer should either be closed, or the messages unacked > and flushed from the buffer so that the consumer does not hog the messages. > Similarly if a consumer gets a message but then locks up without processing > the message we should lazily kill the consumer releasing and redelivering all > its messages -- 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: [jira] Commented: (AMQ-850) add the ability to timeout a consumer to
Continuing my previous posting ... Also, note that message related accounting can happen in the central pool; for example, any dispatched messages are marked appropriately in the message meta-data (which consumer it was dispatched, timestamp etc). The dispatched messages can go to the "back" of the pool or moved to another "Ack pool" (potentially sorted by consumer specific expiry time), which can be visited periodically(and lazily) for further cleanup/processing. Thanks Regards - Sridhar Komandur -- View this message in context: http://www.nabble.com/-jira--Created%3A-%28AMQ-850%29-add-the-ability-to-timeout-a-prefetch-buffer-to-prevent-a-single-consumer-grabbing-messages-tf2014900.html#a5731150 Sent from the ActiveMQ - Dev forum at Nabble.com.
[jira] Commented: (AMQ-850) add the ability to timeout a consumer to prevent a bad, hung or unused consumer consumer from grabbing messages
[ https://issues.apache.org/activemq/browse/AMQ-850?page=comments#action_36732 ] Sridhar Komandur commented on AMQ-850: -- James/Hiram, Here is another proposal for fixing this issue. At a high level, we need break the coupling between the messages allocated to a consumer and the actual act of scheduling a message, using a central pool (from which all the consumers get their messages). I propose that the prefetch buffer just keep track of token count, which indicates the messages that are available to be sent to a consumer. In effect, this is used to do flow control to the consumer. We can extend this to additional policies like "high priority message tokens" etc. When a message is actually scheduled to the consumer (whatever be the policy used for this), an actual message is obtained from the central pool and dispatched to the consumer. After this, the token count is decremented. This proposal, as a side affect, helps in minimizing reordering of messages unnecessarily to the consumer system (comprising of a large number of consumer entities). Thanks Regards - Sridhar Komandur > add the ability to timeout a consumer to prevent a bad, hung or unused > consumer consumer from grabbing messages > --- > > Key: AMQ-850 > URL: https://issues.apache.org/activemq/browse/AMQ-850 > Project: ActiveMQ > Issue Type: New Feature > Components: Broker >Reporter: james strachan > Fix For: 4.2 > > > If a MessageConsumer is created but not used, it still tends to get its > prefetch-buffer worth of messages. If it does not process them within a > specific time the consumer should either be closed, or the messages unacked > and flushed from the buffer so that the consumer does not hog the messages. > Similarly if a consumer gets a message but then locks up without processing > the message we should lazily kill the consumer releasing and redelivering all > its messages -- 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: Start JavaMail by default in 1.1.1?
+1 -dain On Aug 9, 2006, at 10:04 AM, Matt Hogstrom wrote: sounds good to me Aaron Mulder wrote: On 8/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Starting it is fine but it does require some customization as Aaron pointed out. Will the start be graceful enough that users will know that they need to customize it? Perhaps a WARNING message issues at startup if it hasn't been configured would be nice. It doesn't always need to be configured even if you're using it as a J2EE resource -- many Linux boxes come with an MTA already running, so the default mail server of localhost may be perfectly reasonable. Thanks, Aaron Rick McGuire wrote: > Aaron Mulder wrote: >> I don't see a great reason that we're not starting the JavaMail module >> by default. Granted, the user may need to change the SMTP server, but >> it's going to be easier if they don't need to enable the module too >> (e.g. the console usually doesn't see disabled GBeans, and the >> load=false is easy enough to miss in config.xml). > I think this is probably a good idea. Most of the problems I've seen > with users attempting to use javamail have been caused by the fact the > javamail module has not been started. This usually manifests as a > provider resolution failure because the transport jars are not showing > up in the classpath. Because the spec jars ARE there by default, this > error doesn't show up until it is used. > > >> >> What do you think? >> >> Thanks, >> Aaron >> > > > >
[jira] Updated: (GERONIMO-1917) repository doesn't deal well with case insensitive file systems
[ http://issues.apache.org/jira/browse/GERONIMO-1917?page=all ] Matt Hogstrom updated GERONIMO-1917: Fix Version/s: 1.1.2 1.2 (was: 1.1.1) Affects Version/s: 1.1.1 1.1.2 1.1.x Moving to 1.1.2 for rework and inclusion. > repository doesn't deal well with case insensitive file systems > --- > > Key: GERONIMO-1917 > URL: http://issues.apache.org/jira/browse/GERONIMO-1917 > Project: Geronimo > Issue Type: Bug > Security Level: public(Regular issues) > Components: kernel >Affects Versions: 1.1, 1.1.1, 1.1.x, 1.1.2 >Reporter: David Jencks > Fix For: 1.1.2, 1.2 > > > If you've installed a configuration A/B/1/car and then look for a/b/1/car, > the repository will claim it's there on a case insensitive file system, but > then further logic in the config store/ manager blows up because those are > different artifacts. Solution appears to be to check when locating an > artifact that the case from the file system matches the case you are asking > for. -- 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-1716) Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console
[ http://issues.apache.org/jira/browse/GERONIMO-1716?page=all ]
Matt Hogstrom updated GERONIMO-1716:
Fix Version/s: 1.1.2
1.2
(was: 1.1.1)
> Add usage of SimpleEncryption to PropertiesFileLoginModule and Admin Console
>
>
> Key: GERONIMO-1716
> URL: http://issues.apache.org/jira/browse/GERONIMO-1716
> Project: Geronimo
> Issue Type: Improvement
> Security Level: public(Regular issues)
> Components: security
>Affects Versions: 1.0, 1.1, 1.2
> Environment: Any
>Reporter: Donald Woods
> Assigned To: Donald Woods
>Priority: Minor
> Fix For: 1.1.2, 1.2
>
> Attachments: Geronimo-1716.patch
>
>
> Enhancement to the default PropertiesFileLoginModule and Console to encrypt
> user passwords in users.properties.
> To do this, PropertiesFileLoginModule and Console will be updated to use the
> SimpleEncryption utility class, just like the deployer, to read/write
> passwords that have the {Simple} key in front of encrypted passwords.
> The loadProperties() method in PropertiesFileLoginModule will also be updated
> to rewrite the users.properties file if it detects unencrypted passwords,
> which will allow users to manually edit the file to update a password and
> then have it automatically encrypted when the next login event occurs.
--
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-2015) Let's replace JKS to PKCS12 key store type
[ http://issues.apache.org/jira/browse/GERONIMO-2015?page=comments#action_12426986 ] Matt Hogstrom commented on GERONIMO-2015: - -1 for the 1.x line of the server. Users would most likely be expecting some compatibility from previous versions. I'm ok for considering this on 2.0 as users will expect significant changes. I'm also concerned about Vamsi's comment about not being able to switch VMs. Any other input? Otherwise I'll move this to 2.0 > Let's replace JKS to PKCS12 key store type > -- > > Key: GERONIMO-2015 > URL: http://issues.apache.org/jira/browse/GERONIMO-2015 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: security >Reporter: Nikolay Chugunov > Fix For: 1.2 > > Attachments: JKSToPKCS12.java, jksToPKCS12.patch, keystore > > > Hello > Let's replace JKS to PKCS12 key store type; because PKCS12 is widely used key > store and Geronimo may not work on non-Sun VMs. > To fix this problem I have created the patch for Geronimo sources. > In brief the patch (attached) replaces JKS to PKCS12 key store type in > configurations files. > PKCS12 format of key store file is not java-specific and can be created and > read by other programs, e.g. Internet Explorer. In addition PKCS12 exists in > Bouncy Castle (http://www.bouncycastle.org) security provider, while JKS is > Sun specific key store and does not exist in Bouncy Castle. > Also it is needed to replace JKS to PKCS12 keystore file (attached) to > assemblies/j2ee-tomcat-server/src/var/security, > assemblies/j2ee-installer/src/var/security, > assemblies/j2ee-jetty-server/src/var/security directories. Key store file was > generating using JKSToPKCS12 class (attached). This class transfers key and > certificate of Geronimo from JKS to PKCS12. > After I apply this patch to Geronimo 1.0 sources and build Geronimo I can > login to Geronimo console over https. -- 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-2248) Applications portlets: List Parent and Child components against each component
[ http://issues.apache.org/jira/browse/GERONIMO-2248?page=comments#action_12426984 ] Matt Hogstrom commented on GERONIMO-2248: - I think this is fine for inclusion in 1.1.2. Although it is an "improvement" it improves server usability. My +1 for 1.1.2 Vamsi, can you rework the patch to spit out a stack trace when the "Should Not Occur" issue arises :) > Applications portlets: List Parent and Child components against each component > -- > > Key: GERONIMO-2248 > URL: http://issues.apache.org/jira/browse/GERONIMO-2248 > Project: Geronimo > Issue Type: Improvement > Security Level: public(Regular issues) > Components: console >Affects Versions: 1.2, 1.1, 1.1.1 >Reporter: Vamsavardhana Reddy > Fix For: 1.2 > > Attachments: GERONIMO-2248.patch > > > Applications portlets currently provide component status and links to > start/stop/restart/uninstall. They do not provide a listing of parent > components and child components. > If child components are listed, a user will immediatley know what all > configurations will be stopped if a particular component is stopped. > How is it useful? > I have stopped " geronimo/system-database/1.1.1-SNAPSHOT/car" to test > something. Only after an error HTTP 404 was displayed next, I realized that > the admin console had a dependency on > "geronimo/system-database/1.1.1-SNAPSHOT/car". Had there been a Child > Components listing next to "geronimo/system-database/1.1.1-SNAPSHOT/car", it > would have avoided the surprise. -- 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: (XBEAN-19) [RTC] Enable inverse classloading with the classpath element
[ http://issues.apache.org/jira/browse/XBEAN-19?page=comments#action_12426983 ] Matt Hogstrom commented on XBEAN-19: +1...applied and tested. Need one more vote. > [RTC] Enable inverse classloading with the classpath element > > > Key: XBEAN-19 > URL: http://issues.apache.org/jira/browse/XBEAN-19 > Project: XBean > Issue Type: New Feature > Components: server >Affects Versions: 2.4 >Reporter: Guillaume Nodet > Assigned To: Guillaume Nodet > Fix For: 2.6 > > Attachments: XBEAN-19.patch > > > We could do something like > > the default being parent -- 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] Reopened: (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
[ http://issues.apache.org/jira/browse/XBEAN-31?page=all ] Matt Hogstrom reopened XBEAN-31: Resetting vote. > [RTC] it would be great if the m2 plugin would automatically add the XSD and > .xsd.html files as artifacts into the build > > > Key: XBEAN-31 > URL: http://issues.apache.org/jira/browse/XBEAN-31 > Project: XBean > Issue Type: Wish > Components: maven-plugin >Reporter: james strachan > Assigned To: Guillaume Nodet > Fix For: 2.6 > > Attachments: XBEAN-31.diff, XBEAN-31.diff, XBEAN-31.matt.diff > > > So that the XSD and HTML reference would be automatically deployed into the > m2 repository. > See the attach-artifact for how to do it manually in each POM. But given how > many projects are using the m2 plugin it would simplify our lives if the m2 > plugin did this for us > http://mojo.codehaus.org/build-helper-maven-plugin/howto.html -- 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: (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
[ http://issues.apache.org/jira/browse/XBEAN-31?page=all ] Matt Hogstrom updated XBEAN-31: --- Attachment: XBEAN-31.matt.diff > [RTC] it would be great if the m2 plugin would automatically add the XSD and > .xsd.html files as artifacts into the build > > > Key: XBEAN-31 > URL: http://issues.apache.org/jira/browse/XBEAN-31 > Project: XBean > Issue Type: Wish > Components: maven-plugin >Reporter: james strachan > Assigned To: Guillaume Nodet > Fix For: 2.6 > > Attachments: XBEAN-31.diff, XBEAN-31.diff, XBEAN-31.matt.diff > > > So that the XSD and HTML reference would be automatically deployed into the > m2 repository. > See the attach-artifact for how to do it manually in each POM. But given how > many projects are using the m2 plugin it would simplify our lives if the m2 > plugin did this for us > http://mojo.codehaus.org/build-helper-maven-plugin/howto.html -- 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: (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
[ http://issues.apache.org/jira/browse/XBEAN-31?page=comments#action_12426977 ] Matt Hogstrom commented on XBEAN-31: Guillaume, I tried the patch and it didn't work. Since it was fairly small I went ahead and manually applied the changes. And I think this will work. The patch is applied from geronimo/xbean/trunk via patch -p0 < XBEAN-31.matt.diff I also corrected a typo in one of the System.outs for AsArtifactId. Since this is your patch, I'll reset the vote and give this my +1 Cheers. > [RTC] it would be great if the m2 plugin would automatically add the XSD and > .xsd.html files as artifacts into the build > > > Key: XBEAN-31 > URL: http://issues.apache.org/jira/browse/XBEAN-31 > Project: XBean > Issue Type: Wish > Components: maven-plugin >Reporter: james strachan > Assigned To: Guillaume Nodet > Fix For: 2.6 > > Attachments: XBEAN-31.diff, XBEAN-31.diff, XBEAN-31.matt.diff > > > So that the XSD and HTML reference would be automatically deployed into the > m2 repository. > See the attach-artifact for how to do it manually in each POM. But given how > many projects are using the m2 plugin it would simplify our lives if the m2 > plugin did this for us > http://mojo.codehaus.org/build-helper-maven-plugin/howto.html -- 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-521) Tuning parameters configuration
[ https://issues.apache.org/activemq/browse/SM-521?page=comments#action_36731 ] Ramon Buckland commented on SM-521: --- for Component throttling, this is handling the ConfigMBeanImpl. Every component registered with the JBIContainer will get their own Bean. What would be nice is to have How would this config translate to an XBean ? is there a magical way using the xbean config to also set these values ? I am thinking that these two properties should sit on the BaseComponent class and on init after it is registered itself, it gets a hold of it's own MBean and sets the relevant values. Issue is, a fair few components don't extend BaseComponent but rather implement directly the jbi interface component. > Tuning parameters configuration > --- > > Key: SM-521 > URL: https://issues.apache.org/activemq/browse/SM-521 > Project: ServiceMix > Issue Type: Improvement > Components: servicemix-core >Reporter: Guillaume Nodet > Fix For: 3.0-M3 > > > We need to provide a way to configure tuning parameters for servicemix: > * thread pools (core + flows + seda queues + components ) > * queues (delivery channels + seda queues) > * component throttling > This may need a way to configure dummy activationSpecs (with no components, > only the component name) > so that we can configure these parameters when using JBI std installation -- 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: [Committing] GERONIMO-2277 Remove TransactionContextManager
Yay! On Aug 9, 2006, at 9:28 AM, Dain Sundstrom wrote: With votes from Jeff, Jencks and Matt, I am going to committ this patch today, so please let me know if you're going to commit something significant so I can avoid conflicts :) -dain On Aug 7, 2006, at 4:07 PM, Dain Sundstrom wrote: Ok all fixed. Jason fixed the logging issue, and the other problem was that backport-concurrent-util was not in the manifest classpath of the server jar. -dain On Aug 7, 2006, at 10:05 AM, Dain Sundstrom wrote: On Aug 7, 2006, at 12:09 AM, David Jencks wrote: The notcm branch builds fine for me under m2 but the j2ee-jetty server does not start for me at the moment. Apparently the TransactionManager doesn't start. As noted in another post I don't get any log files which has so far inhibited me from investigating further. Is this just my setup? Don't know. I'll take a look -dain
[jira] Commented: (AMQ-855) Add support for prefetchSize = 0
[ https://issues.apache.org/activemq/browse/AMQ-855?page=comments#action_36730 ] Vadim Pesochinskiy commented on AMQ-855: James & Hiram, I understand that you are trying to keep the scope of AMQ in check and I appreciate this as I believe we will benefit in quality. However, I just do not think I can proceed with using this product, because it does not satisfy my project's requirements. The requirements are not artificial and I am sure they cannot be resolved with either of the solutions that you proposed. I do not want to abuse your CPU with long explanation of why it is so. Due to whatever reasons I have multiple synchronous consumers (no listener, receive*(*) methods) and some of them are not used for extended periods of time. This results in the message broker not dispatching messages. Is this not a bug?!!! I do not know if setting prefetchSize=0 is the solution, but somehow AMQ needs to support the case when consumers are not getting any messages until they request them. - Vadim. > 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, 4.0.1, 4.0.2 > Environment: any >Reporter: Vadim Pesochinskiy >Priority: Critical > Fix For: 4.2 > > > 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: Start JavaMail by default in 1.1.1?
sounds good to me Aaron Mulder wrote: On 8/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Starting it is fine but it does require some customization as Aaron pointed out. Will the start be graceful enough that users will know that they need to customize it? Perhaps a WARNING message issues at startup if it hasn't been configured would be nice. It doesn't always need to be configured even if you're using it as a J2EE resource -- many Linux boxes come with an MTA already running, so the default mail server of localhost may be perfectly reasonable. Thanks, Aaron Rick McGuire wrote: > Aaron Mulder wrote: >> I don't see a great reason that we're not starting the JavaMail module >> by default. Granted, the user may need to change the SMTP server, but >> it's going to be easier if they don't need to enable the module too >> (e.g. the console usually doesn't see disabled GBeans, and the >> load=false is easy enough to miss in config.xml). > I think this is probably a good idea. Most of the problems I've seen > with users attempting to use javamail have been caused by the fact the > javamail module has not been started. This usually manifests as a > provider resolution failure because the transport jars are not showing > up in the classpath. Because the spec jars ARE there by default, this > error doesn't show up until it is used. > > >> >> What do you think? >> >> Thanks, >> Aaron >> > > > >
Re: soap-binding sample error
These are several commands. Try ant setup then servicemix servicemix.xml On 8/9/06, ajayk_goel <[EMAIL PROTECTED]> wrote: Sorry if it is duplicate post, I did try searching for this error though... I am new to servicemix and am trying to run the soap-binding sample provided by 3.0 M2. When I try to run the xml file by saying (servicemix is in my path) "ant setup servicemix servicemix.xml" I get an error "Target `servicemix' does not exist in this project." What am I missing? -- View this message in context: http://www.nabble.com/soap-binding-sample-error-tf2079610.html#a5728499 Sent from the ServiceMix - Dev forum at Nabble.com. -- Cheers, Guillaume Nodet
Re: Start JavaMail by default in 1.1.1?
On 8/9/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote: Starting it is fine but it does require some customization as Aaron pointed out. Will the start be graceful enough that users will know that they need to customize it? Perhaps a WARNING message issues at startup if it hasn't been configured would be nice. It doesn't always need to be configured even if you're using it as a J2EE resource -- many Linux boxes come with an MTA already running, so the default mail server of localhost may be perfectly reasonable. Thanks, Aaron Rick McGuire wrote: > Aaron Mulder wrote: >> I don't see a great reason that we're not starting the JavaMail module >> by default. Granted, the user may need to change the SMTP server, but >> it's going to be easier if they don't need to enable the module too >> (e.g. the console usually doesn't see disabled GBeans, and the >> load=false is easy enough to miss in config.xml). > I think this is probably a good idea. Most of the problems I've seen > with users attempting to use javamail have been caused by the fact the > javamail module has not been started. This usually manifests as a > provider resolution failure because the transport jars are not showing > up in the classpath. Because the spec jars ARE there by default, this > error doesn't show up until it is used. > > >> >> What do you think? >> >> Thanks, >> Aaron >> > > > >
Re: Start JavaMail by default in 1.1.1?
Matt Hogstrom wrote: Starting it is fine but it does require some customization as Aaron pointed out. Will the start be graceful enough that users will know that they need to customize it? Perhaps a WARNING message issues at startup if it hasn't been configured would be nice. Rick McGuire wrote: Aaron Mulder wrote: I don't see a great reason that we're not starting the JavaMail module by default. Granted, the user may need to change the SMTP server, but it's going to be easier if they don't need to enable the module too (e.g. the console usually doesn't see disabled GBeans, and the load=false is easy enough to miss in config.xml). I think this is probably a good idea. Most of the problems I've seen with users attempting to use javamail have been caused by the fact the javamail module has not been started. This usually manifests as a provider resolution failure because the transport jars are not showing up in the classpath. Because the spec jars ARE there by default, this error doesn't show up until it is used. Well, it sort of requires customization. One way to use it is to request the javamail resource, then request a transport object from the resource. In that mode, yes, customization is required. However, most of the questions I've been seeing from the user list involved people who just wish to use the javamail APIs directly. They don't require the configured javamail resource, just a full set of javamail jars. Since the provider jars don't get pulled in unless the javamail config is loaded, the smtp provider can't be located. These users are required to make a config change just to get the jar files loaded. We could satisfy the needs of these users by redoing the dependencies a bit and decoupling the providers from the mail config. What do you think? Thanks, Aaron
[jira] Created: (SM-528) using the new ClientFactory for the JSR181 proxy inside jsr181 service unit
using the new ClientFactory for the JSR181 proxy inside jsr181 service unit --- Key: SM-528 URL: https://issues.apache.org/activemq/browse/SM-528 Project: ServiceMix Issue Type: Improvement Components: servicemix-jsr181 Affects Versions: 3.0-M2 Reporter: James Bradt Priority: Minor Unfortunately, you currently need a reference to the JBI container (or a ComponentContext). But neither the JBIContainer nor the ComponentContext are available at the time the xbean file is loaded. This could now be solved by using the new ClientFactory which is available in JNDI, but has been coded yet. Could you please raise a JIRA for that ? For now, you need to create the JbiProxy programmaticaly from your POJO. On 8/8/06, James Bradt <[EMAIL PROTECTED]> wrote: > > I've taken a look at the unit test for jsr181 proxy (and the small amount > of > info in the wiki area), but I can't seem to answer this question. > > Can a jsr181:proxy tag be defined within the xbean.xml for a jsr181 > service > unit, or can it only be used within a lwcontainer service unit? > > If I can use it within a jsr181 service unit, what is the container name > that I should I reference within the jsr181:proxy element? > > Thanks, > James > > > > -- Cheers, Guillaume Nodet -- 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
[Committing] GERONIMO-2277 Remove TransactionContextManager
With votes from Jeff, Jencks and Matt, I am going to committ this patch today, so please let me know if you're going to commit something significant so I can avoid conflicts :) -dain On Aug 7, 2006, at 4:07 PM, Dain Sundstrom wrote: Ok all fixed. Jason fixed the logging issue, and the other problem was that backport-concurrent-util was not in the manifest classpath of the server jar. -dain On Aug 7, 2006, at 10:05 AM, Dain Sundstrom wrote: On Aug 7, 2006, at 12:09 AM, David Jencks wrote: The notcm branch builds fine for me under m2 but the j2ee-jetty server does not start for me at the moment. Apparently the TransactionManager doesn't start. As noted in another post I don't get any log files which has so far inhibited me from investigating further. Is this just my setup? Don't know. I'll take a look -dain
soap-binding sample error
Sorry if it is duplicate post, I did try searching for this error though... I am new to servicemix and am trying to run the soap-binding sample provided by 3.0 M2. When I try to run the xml file by saying (servicemix is in my path) "ant setup servicemix servicemix.xml" I get an error "Target `servicemix' does not exist in this project." What am I missing? -- View this message in context: http://www.nabble.com/soap-binding-sample-error-tf2079610.html#a5728499 Sent from the ServiceMix - Dev forum at Nabble.com.
Re: Proposal to change the tooling version to be 3.0-incubating-SNAPSHOT
Instead of hand carving the version changes through the files. It could be more elegantly written as find . -type f -name '*.xml' -or -name '*.properties' | xargs -l1 grep -l SNAPSHOT | xargs -l1 perl -pi.backup -s 's/(3.0-incubating-SNAPSHOT|3.0-SNAPSHOT|1.0-i ncubating-SNAPSHOT)/3.0-2006-08-02-r427980/' Which can be translated as # # Find all the files that end in XML or properties # find . -type f -name '*.xml' -or -name '*.properties' \ # # filter so we ONLY get the ones that contain the word SNAPSHOT # but just list the file .. (don't grep it's contents) # xargs is a magic little "streamliner" that takes a list and # feeds them into the command that follows, it has a magic option of # -l1, meaning .. 1 at a time .. # xargs -l1 grep -l SNAPSHOT \ # # now do the textual replacement in that file that we have found. # use perl, which we also backup the file before it makes the change # -pi.backup (eg: pom.xml.backup) # # The regexp says, change any occurence of 3.0-incubating-SNAPSHOT, or or # to the version string "3.0-2006-08-02-r427980" # xargs -l1 perl -pi.backup -s 's/(3.0-incubating-SNAPSHOT|3.0-SNAPSHOT|1.0-i ncubating-SNAPSHOT)/3.0-2006-08-02-r427980/' hope that is a little clearer :-) cheers ramon Guillaume Nodet wrote: Wow, thx. I don't understand what it does, but i will try it :) On 8/9/06, Ramon Buckland <[EMAIL PROTECTED]> wrote: +1 here also Here is what I use to do it :-) grep -lR SNAPSHOT * | egrep "(xml|properties)$" | xargs -l1 -iXX perl -pi.sm-b4-IC-change.incubating.orig -e 's/(3.0-incubating-SNAPSHOT|3.0-SNAPSHOT|1.0-i ncubating-SNAPSHOT)/3.0-2006-08-02-r427980/' XX Philip Dodds wrote: > +1 for having everthing sync up on 3.0 > > P > > On 8/8/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote: >> >> I was wondering if we should change the maven plugin / archetype version >> to >> be in sync with the container / components. >> Currently, everything as the same release cycle, so I do not really see >> the >> point in having a 3.0 for container and 1.0 for >> tooling. I think it may be confusing for users. >> >> -- >> Cheers, >> Guillaume Nodet >> >> >
Re: M2 : car-maven-plugin and geronimo-plugin.xml files
I get the sense that both of you are a bit frustrated. The transition to the new RTC development
model has been challenging for all. The PMC has not kept up with the number of reviews and that has
allowed the codebase to drift while patches then get stale.
Recently we've made several steps forward to improve the process. Several new PMC members have been
added in the last few weeks that are active committers to the project so the ability to provide
timely feedback has been improved. Along with some better mechanisms to track what needs to be
reviewed so we can quickly address them. (I think we got the pluggable JAAC completed last night).
All this to say it has made us stumble a bit in the process, we're not perfect yet, but we're making
some important headway.
Everyone who has worked on the Maven 2 conversion needs to get some kudos as it is slightly larger
than a bread box :) and given the somewhat binary nature of the change does not lend itself well to
using patches as the vehicle to get the job done.
All that said, Jason, as your going through the patches and making changes what is the primary way
to get feedback to the person who contributed the patch? It sounds like you have some good feedback
that would help Anita produce patches that you are both in more agreement on. Also, it sounds like
some of the changes are preferences based on style. It would be a fair debate as to one should use
Plexus or Geronimo infrastructure for the file delete activity.
All this said, you guys are to be commended for the progress you've made. For the time being the
review and collaboration feels like we've gone from a sprint to a jog but as we hit our stride I
hope the pace will pick up as well.
anita kulshreshtha wrote:
inline..
--- Jason Dillon <[EMAIL PROTECTED]> wrote:
On Aug 7, 2006, at 10:33 PM, anita kulshreshtha wrote:
This code is from servlets-examples-jetty config (rev 429124):
${pom.basedir}/src/conf
META-INF
geronimo-plugin.xml
true
This code has been added to many applications config. Which
means
that you are trying to write it yourself and have no intention of
using
the patch.
I was simply reusing the existing Maven2 resources plugin to handle
filtering of resources.
This high quality code does not do what it is supposed to do, i.e. put
geronimo-plugin.xml in the generated car.
I looked over your patch and could not apply it directly due to the
number of other changes made to the tree since the patch was
originally crafted.
Why did you ask me to make the patch?
I asked you to roll new patches against m2migration and not off of
trunk so that I could quickly verify and apply them.
The patch on July 27th was for m2migration and it is clearly written.
Wow.. I don't blame you for exercising the power of a committer.
you
get to commit code that does nothing and reject the code that
works!
You have the power to shut down other peoples work.
I am starting to take offense to some of these comments you are
making. I'm not sure if you are trying to goat me into a conflict or
if you are trying to resolve the work you have done and move forward.
:-(
Jason, I was also aware of the issues with the code and had been
wanting to fix them and add more functionality. You are constantly
changing the code that I wrote without any communication. You have
made
it _impossible_ for me to work on this code. I am not saying that
you
are doing it intentionally.
Since these commits end up with my user id attached to them, I am not
willing to commit something that does not meet my standards for
quality. I am not trying to invalidate your work, I am trying to get
our m2 build functional and at the same time ensure a high standard
of quality for the code that supports it.
FYI, the code you are talking about was already committed by David
Jencks! David helped me write the plugin by expaining how the configs
work. He patiently reviewed massive patches, tested them, committed
them and made sure that the first server could be started.
IMO, you should have accepted the code
because it provided the required functionality and allowed me to
make
improvements.
The code submitted in the patches that I reviewed (and some that I
committed and then changed) were not using the Mojo API appropriately
or effectively. Just because a chunk of code "works" does not mean
that it should be blindly applied to the tree.
Isn't it because you added Mojo for the code that is not even being
used?
I accepted the bulk of the code and cleaned it up to meet my
standards before I committed it. Though some of your code I have not
even begun to review since it is scattered amongst several issues and
then into several patches in those issues, which makes it much harder
for me to quickly verify
[jira] Assigned: (GERONIMODEVTOOLS-52) Move away from generic server framework
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-52?page=all ] Sachin Patel reassigned GERONIMODEVTOOLS-52: Assignee: Sachin Patel > Move away from generic server framework > --- > > Key: GERONIMODEVTOOLS-52 > URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-52 > Project: Geronimo-Devtools > Issue Type: New Feature > Components: eclipse-plugin >Reporter: Sachin Patel > Assigned To: Sachin Patel > Fix For: 1.x > > > As more geronimo specific features are needed, using the generic server > framework in wtp is no longer suitable and the current server adapter is > quickly outgrowing its need for it. The server support needs to be > re-written to provide a complete custom implementation for geronimo server > support in WTP. -- 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
