Re: Geronimo v1.1.1 release
Jacek Laskowski wrote: On 7/7/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: When did we want to push this out the door? I see a lot of work scheduled for this micro release. I think that we should time box this puppy for a freeze on 7/21 and for a release on 7/28. Any issues that haven't been picked up by Monday, with firm commitments to getting the fixes done before the freeze, would get pulled off and, maybe, scheduled for 1.1.2 or 1.2.0. It will be nice to get a nice rhythm on the releases. Thoughts? +1 While I don't know how much work is to be done, it's worth to try out anyway. Who's a release manager/coordinator? Alan? Congrats! ;-) Sure. I'll be happy to help. Regards, Alan
Re: What is the point of the CAR file?
To be clear...er I am still not convinced that we need CAR files to make G work... but we can look into this more later once we have a functional build and most likely 1.2+ out the door. We'll see... maybe i will see the light and hop on the CAR bandwagon... or maybe not. I commented on this to get a better understanding for while it was needed to make G operate (and still pending some concrete details). My gut tells me that there is a simpler way to get to the same goal... and we should examine if that is possible... BUT, I'm not suggesting in any way that we block progress (of the m2 build or anything) because of it. --jason On Jun 27, 2006, at 11:17 PM, David Jencks wrote: On Jun 27, 2006, at 3:25 PM, Jason Dillon wrote: Can someone briefly explain what the point of CAR files are? They appears to be compiled plan.xml or something... but why do we need this? Why not deploy the plan.xml and then let any processing happen inside of the server... and eliminate the need for any build-tiime custom CAR mucky muck? I'm not real enthusiastic about debating this at length right now, but I strongly object to removing the concept of car files. I'm not thrilled with replaicing the seriailzed gbean content with xml but don't object. I do object to requiring any builders to be running in a server in order to start any modules. The idea behind car files is to convert any kind of input configuration info into a basic format that requires no thought to load and run. Starting with the plan.xml at runtime will require making sure somehow that any builders needed to interpret the plan are started. Right now this is restricted to XmlAttributeBuilders and XmlReferenceBuilders but the patch I'm working on for pluggable jacc will introduce the possibility of using any namespace driven builder to interpret pretty much arbitrary content. thanks david jencks --jason
Re: JEE 5.0 Report Card
Thanks for taking action on this Dave...great idea. Jeff David Klavon wrote: > There has been a couple of requests on the user list about where > Geronimo is in regard to moving to JEE 5.0. I started a 'JEE 5.0 Report > Card' in the wiki in an attempt to capture all of the JEE 5.0 JSRs, and > communicate where Geronimo plans to gain support for the various spec > upgrades. Some of the packages listed are just ideas at this point in > order to launch further discussion. > > Given that the JEE 5.0 rollout is expected to be implemented across > several months and releases, it would be helpful to keep this chart > updated as each JSR is addressed so our users know our rollout plan. > > Take a look... comments for improvement are welcomed. > http://cwiki.apache.org/GMOxPMGT/geronimo-jee-50-report-card.html > > Dave
Re: JEE 5.0 Report Card
Thanks Dave. --jason On Jul 7, 2006, at 7:57 PM, David Klavon wrote: There has been a couple of requests on the user list about where Geronimo is in regard to moving to JEE 5.0. I started a 'JEE 5.0 Report Card' in the wiki in an attempt to capture all of the JEE 5.0 JSRs, and communicate where Geronimo plans to gain support for the various spec upgrades. Some of the packages listed are just ideas at this point in order to launch further discussion. Given that the JEE 5.0 rollout is expected to be implemented across several months and releases, it would be helpful to keep this chart updated as each JSR is addressed so our users know our rollout plan. Take a look... comments for improvement are welcomed. http://cwiki.apache.org/GMOxPMGT/geronimo-jee-50-report-card.html Dave
A few tests need some help
I've reconfigured all modules to us the latest surefire plugin, and
most tests work... except for a few exceptions:
system/**/PluginInstallerTest.java
security/**/LoginKerberosTest.java
connector-builder/**/Connector15DCBTest.java
mail/**/MailcapTest.java
Each of these fail in someway that was not obvious to me why, so I
configured these specific tests to be excluded. I've removed all of
the maven.test.skip=true bits from poms and recommend that they never
be re-added. IMO, the tests must always pass and they should be
quick enough to run and thus not force people to disable them to run
builds.
All of this work is in this branch:
https://svn.apache.org/repos/asf/geronimo/sandbox/svkmerge/
m2migration/
I've given up on submitting patches for the moment, but I plan on
creating an RTC issue when there is significant change to be applied
back to trunk... and will provide a patch for clarity, but recommend
that folks use this branch to test/validate on top of scanning the
patch.
I would appreciate some help in resoling why the above listed tests
are failing.
One major thing that has changed, is that the working directory for
tests has been changed from ${basedir} to ${basedir}/target, so there
were several changes needed to bind files to the correct path. IMO
this is a best practice, regardless of what the working directory
is tests should always use ${basedir} to root themselves and
ensure that the tests will work even when the working directory changes.
I do not believe that the failed tests listed above fail because of
this change, but it is possible that they are for reasons I do not
understand.
* * *
A side note, we should create a module that contains support classes
for unit (and integration) tests to allow some of the redundant code
to be collected, organized and maintained in a central location. I
believe we will want to implement this soon after the m2 migration is
complete and update all tests to extend from that framework to
simplify the code required to perform highly reliable testing.
Logging configuration is still a bit whack for tests... some tests
spit out a bunch of junk while others just complain with Log4j
configuration warnings. I will be resolving this shortly with the
implementation of the logging-config plugin extension, which will
allow all modules to share the same config.. BUT before this will
work we need to setup a peer project for all of the independent build
plugins.
More mail to come on that soon. I plan on setting up a project in
the sandbox, proving and example for how it works using this sandbox/
svkmerge/m2migration branch and then detailing/documenting it to the
list once it is functional.
If you have any questions or comments please let me know.
And... again, can I get someone to look at why the tests listed above
fail?
Thanks,
--jason
PS. sandbox/svkmerge/m2migration also has the latest assembly plugin
changes from GERONIMO-1737 which I am also evaluating.
JEE 5.0 Report Card
There has been a couple of requests on the user list about where Geronimo is in regard to moving to JEE 5.0. I started a 'JEE 5.0 Report Card' in the wiki in an attempt to capture all of the JEE 5.0 JSRs, and communicate where Geronimo plans to gain support for the various spec upgrades. Some of the packages listed are just ideas at this point in order to launch further discussion. Given that the JEE 5.0 rollout is expected to be implemented across several months and releases, it would be helpful to keep this chart updated as each JSR is addressed so our users know our rollout plan. Take a look... comments for improvement are welcomed. http://cwiki.apache.org/GMOxPMGT/geronimo-jee-50-report-card.html Dave
[jira] Updated: (GERONIMO-2125) Classpath entries in the web app archive META-INF/MANIFEST.MF are not added to the wep app class path
[ http://issues.apache.org/jira/browse/GERONIMO-2125?page=all ] David Jencks updated GERONIMO-2125: --- Fix Version: 1.1.1 1.2 > Classpath entries in the web app archive META-INF/MANIFEST.MF are not added > to the wep app class path > - > > Key: GERONIMO-2125 > URL: http://issues.apache.org/jira/browse/GERONIMO-2125 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: deployment > Versions: 1.1 > Environment: 1.1 release > Reporter: Mario Ruebsam > Priority: Blocker > Fix For: 1.2, 1.1.1 > > A working EAR for Geronimo 1.0 with this structure: > app.ear/ > app.jar > cpa.jar > found.jar > webclient.war > The util JARs are referenced from the webclient.war/META-INF/MANIFEST.MF > Class-Path: app.jar cpa.jar found.jar > Deployment of this EAR in G 1.1-rc1 result in ClassNotFoundExceptions because > of the missing classes in the JARs which are not found. > Putting the JARs into the webclient.war/WEB-INF/lib worked. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMODEVTOOLS-90) Deployment errors all on one line
Deployment errors all on one line - Key: GERONIMODEVTOOLS-90 URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-90 Project: Geronimo-Devtools Type: Bug Components: eclipse-plugin Environment: Windows, Eclipse Callisto, Geronimo Eclipse Plugin 1.1 RC3 Reporter: Neal Sanche Whenever there is a deployment error, the stacktrace of the error is displayed all on one line. I don't know why that would be, perhaps it is being formatted with UNIX end of line characters instead of DOS \r\n? Anyway, it would be nice if this error message were displayed properly. Perhaps the Message property of the exception, and any inner exceptions could be displayed, followed by the stacktrace? -- 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-2172) Remove staged m2 build when Maven has been fixed
Remove staged m2 build when Maven has been fixed Key: GERONIMO-2172 URL: http://issues.apache.org/jira/browse/GERONIMO-2172 Project: Geronimo Type: Task Security: public (Regular issues) Components: buildsystem Versions: 1.2 Reporter: Jason Dillon Assigned to: Jason Dillon Priority: Trivial We should remove the staged build that is currently implemented in 1.2-SNAPSHOT once this issue has been resolved: http://jira.codehaus.org/browse/MNG-1911 -- 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
Derby JMX and Geronimo
I don't know if this is the right place to talk about this, but I'm working on adding JMX to derby. I had certain doubts in mind regarding the whole GBean and MBean thing (I'm sure this would have been asked several times before). Will my calls to ManagementFactory.getPlatformMBean() work inside Geronimo? I dont see a reason for them to not work, but just wanted to confirm. Further, what is there an interoperability between GBeans and MBeans? Can I expose my MBeans from inside an GBean to expose the management/monitoring interface or do I need to code some extra stuff?? If I have a Derby jar with JMX built into it, will it break Geronimo's code? Any help will be greatly appriciated. Best Regards, Sanket Sharma On 7/7/06, John Sisson <[EMAIL PROTECTED]> wrote: In the "Derby library does not have line number debug information" mail thread [1] a few weeks ago I asked whether people wanted to upgrade to the Derby 10.1.3 maintenance release [2]. David Jencks was the only person who mentioned it should go in the 1.1.1 release but did not hear any objections from others. If anyone disagrees with this plan, please speak up before I start looking into this next week. John [1] http://www.mail-archive.com/dev@geronimo.apache.org/msg25051.html [2] http://mail-archives.apache.org/mod_mbox/db-derby-user/200607.mbox/[EMAIL PROTECTED]
Re: Geronimo plugin repositories
It won't be bad to change the URL, but I think the more pressing need is for the user to be able to add new repositories directly. The plugin repository list GBean tracks both the repositories downloaded from the "official" list and a group of user-added repositories that will be kept even if the contents of the official list change so the other entries are replaced. So we need a button/link and a screen or JavaScript popup or something so the user can select to add a new repository and it will be added to the list of user repositories. You're welcome to work on that. Thanks, Aaron On 7/7/06, Paul McMahan <[EMAIL PROTECTED]> wrote: In Geronimo 1.1 the console retrieves its default list of plugin repositories from a URL under people.apache.org. This can be changed by overriding an attribute of the DownloadedPluginRepos gbean in config.xml. GERONIMO-2076 calls out the need for making the list of plugin repositories configurable without having to manually edit config.xml. Since the 1.1.1 release is gearing up I was looking for JIRAs I can work on. Unless someone else already has their eye on this JIRA (Aaron?) I would like to provide a new portlet that will allow the user to easily add/remove plugin repositories. The list would still be persisted in config.xml. I can also change the location of the default repository list to somewhere under geronimo.apache.org, which would be handy since those documents are version controlled and (I would assume) hosted on a higher volume server. Thoughts? Best wishes, Paul
[jira] Created: (GERONIMO-2171) some portions of a build still look at cvs.apache.org/repository
some portions of a build still look at cvs.apache.org/repository Key: GERONIMO-2171 URL: http://issues.apache.org/jira/browse/GERONIMO-2171 Project: Geronimo Type: Bug Security: public (Regular issues) Components: buildsystem Versions: 1.1.1 Reporter: Kevan Miller Assigned to: Kevan Miller Priority: Minor Fix For: 1.1.1 There are some project.properties files that cause maven to attempt to download artifacts from cvs.apache.org. They need to be people.apache.org. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1959) Console: plugin % complete shoudl reset to 0 while preparing a download
[ http://issues.apache.org/jira/browse/GERONIMO-1959?page=all ] Paul McMahan reassigned GERONIMO-1959: -- Assign To: Paul McMahan > Console: plugin % complete shoudl reset to 0 while preparing a download > --- > > Key: GERONIMO-1959 > URL: http://issues.apache.org/jira/browse/GERONIMO-1959 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.1 > Reporter: Aaron Mulder > Assignee: Paul McMahan > Priority: Minor > Fix For: 1.1.1 > > The console progress bar should go back to 0 if the percent complete is set > to -1 (which should handle resetting it to 0 during the "preparing to > download" phase, whereas now it stays at whatever value it had for the last > status message) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1887) Remove unneeded jars from console WEB-INF/lib directories
[ http://issues.apache.org/jira/browse/GERONIMO-1887?page=all ] Paul McMahan reassigned GERONIMO-1887: -- Assign To: Paul McMahan > Remove unneeded jars from console WEB-INF/lib directories > - > > Key: GERONIMO-1887 > URL: http://issues.apache.org/jira/browse/GERONIMO-1887 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: console > Versions: 1.x > Reporter: Paul McMahan > Assignee: Paul McMahan > Priority: Minor > Fix For: 1.1.1 > > Several of the jars in the console's WEB-INF/lib directories are unneeded > - both copies of jasper-compiler-5.5.12.jar (400K each) > - both copies of jasper-runtime-5.5.12.jar (80K each) > - the copy of castor-0.9.5.3.jar in console-standard (1.7M) > Removing these jars will decrease the server footprint and binary image > download size. -- 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: OSGi overview (was Re: Geronimo/Equinox integration status?)
Hi Jacek, On Fri, Jul 07, 2006 at 10:22:34PM +0200, Jacek Laskowski wrote: > Would you point out another short introductory material about it or > just suggest I'll simply take a look at the spec to get the gist of > it? The spec is big, too big for my bleary eyes to read on-screen, and yet I feel guilty printing it out. I'd start at this web page [1], and then if you're still curious try this 17pp whitepaper [2], only then the full spec. Looking at it from a different persective, there's a brief tutorial showing how to write a simple bundle [3], provided by the Oscar OSGi folks. Part of it uses their "Gravity" framework and as such isn't strictly OSGi, but it looks as if they've left that part 'till the end. Toby [1] http://osgi.org/osgi_technology/index.asp?section=2 [2] http://osgi.org/documents/osgi_technology/osgi-sp-overview.pdf [3] http://oscar-osgi.sourceforge.net/tutorial/
Geronimo plugin repositories
In Geronimo 1.1 the console retrieves its default list of plugin repositories from a URL under people.apache.org. This can be changed by overriding an attribute of the DownloadedPluginRepos gbean in config.xml. GERONIMO-2076 calls out the need for making the list of plugin repositories configurable without having to manually edit config.xml. Since the 1.1.1 release is gearing up I was looking for JIRAs I can work on. Unless someone else already has their eye on this JIRA (Aaron?) I would like to provide a new portlet that will allow the user to easily add/remove plugin repositories. The list would still be persisted in config.xml. I can also change the location of the default repository list to somewhere under geronimo.apache.org, which would be handy since those documents are version controlled and (I would assume) hosted on a higher volume server. Thoughts? Best wishes, Paul
Re: svn commit: r419764 - /geronimo/trunk/m2-plugins/pom.xml
On 7/7/06, Jason Dillon <[EMAIL PROTECTED]> wrote: On Jul 7, 2006, at 1:12 AM, Jacek Laskowski wrote: > It is when one's doing some non-trivial changes > without careful thinking how to sort out issues with testing/applying > before they become painful when it comes to applying them to trunk, What exactly are you suggesting by this statement?! Just to quote what you said: "This is an unfortunate reality that occurs when delaying major changes for a significant period." We've got troubles with patches and their testing. I'm really concerned that we don't approach it, but await the next 'major change' that will again remind us about it. I wonder how much time will it take to apply another m2 patch and how we work on it. So, the above should be read as: 'I'm really concerned that although we know we're in a big trouble with patches and their way to trunk, we don't want to sort it out once and for all, but rather ignore it until there's no other way'. I'm preparing a doc about a possible solution that will guide us thru this bumpy RTC road. Will surely take some time, but I hope it's worth it. See you soon...;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [long] OSGi overview (was Re: Geronimo/Equinox integration status?)
Hi Toby, Thanks for the gentle introduction to OSGi. It's the shortest yet very informative description of OSGi I could read and really enjoyed it. Much appreciated. Would you point out another short introductory material about it or just suggest I'll simply take a look at the spec to get the gist of it? Jacek On 7/7/06, toby cabot <[EMAIL PROTECTED]> wrote: Jacek, Thanks for the info. On Wed, Jul 05, 2006 at 10:06:46PM +0200, Jacek Laskowski wrote: > On 7/5/06, toby cabot <[EMAIL PROTECTED]> wrote: > >What's the status of the Geronimo/Equinox (OSGi server) integration? > > Dunno, but great you've asked as it was one of the questions during > the Apache Geronimo panel at TSSJS in Barcelona, which James S. > answered positively, i.e. there's a fit for it in Geronimo and it > should or will be soon available. I think Dain mentioned it a couple > of times (it was something about classloading architecture or alike). That's great to hear. I'd be willing to help out. > I wonder how it's different from what we've got now? How does it > compare to XBean if at all? A short introduction would be of help. I'm far from an OSGi expert, but let me take a swing. Either I'll be correct or someone will correct me, and either way we'll learn something. OSGi [1] is both an organization and a specification. The spec [2], currently at release 4 and weighing in at >260 pages, describes what they call a "service platform" [3] which really amounts to an application server. It's somewhat analogous to GBeans in that it specifies the interface between application components and the server that runs them. It's much smaller and less featureful than J2EE, having been originally intended (and still used often) for embedded systems. The spec has been around for quite some time but seems to be gaining a lot more mindshare recently. Probably a big part of that is due to the Eclipse project using OSGi technology inside their IDE. The basic OSGi software package is called a "bundle". A bundle is basically a jar file + metadata. The metadata indicates which "services" a bundle exports and which it depends on; this allows a server to do automatic dependency resolution, so if you ask it to download a particular bundle from a remote bundle server it can first download and start all of the dependencies automatically. There's also a JNDI-ish "registry" within an OSGi server that allows bundles to find services and bind to them at run-time. So I guess you can say that a bundle is somewhere between a GBean and a Configuration, but closer a GBean plus some additional packaging. Within Eclipse, the things that Eclipse calls "plugins" are basically OSGi bundles with some additional Eclipse metadata. From my admittedly naive perspective, I don't see huge differences between bundles and GBeans, but I wouldn't be surprised if they were there. So far I've seen two integration approaches mentioned - OSGi-centric and Geronimo-centric. The OSGi-centric approach [4] involves taking the various Geronimo services, repackaging them as bundles, and running them in an OSGi server. The Geronimo-centric approach [5] involves building a GBean wrapper around bundles and services, so the GBean server can manage them. In either case I think that having the ability to run J2EE apps *and* OSGi bundles is very powerful. My interest in OSGi technology stems from the fact that my employer uses Geronimo currently but is planning to also support OSGi, so my best-case scenario is a nice integration between the two technologies. Thanks, Toby [1] http://www.osgi.org [2] Specs are "by-request" at http://www.osgi.org/osgi_technology/download_specs.asp?section=2 [3] http://www.osgi.org/osgi_technology/index.asp?section=2 [4] http://www.mail-archive.com/dev@geronimo.apache.org/msg10923.html [5] http://www.mail-archive.com/dev@geronimo.apache.org/msg10822.html -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Commented: (AMQ-762) Message Group based load balancing not well distributed across brokers
[ https://issues.apache.org/activemq/browse/AMQ-762?page=comments#action_36537 ] Sanjiv Jivan commented on AMQ-762: -- Unfortunately SimpleMessageListenerContainer doesnt seem to be helping. > Message Group based load balancing not well distributed across brokers > -- > > Key: AMQ-762 > URL: https://issues.apache.org/activemq/browse/AMQ-762 > Project: ActiveMQ > Type: Bug > Versions: 4.0 > Environment: Active MQ 4.0, Lingo 1.1 > Reporter: Sanjiv Jivan > Attachments: lingocluster.zip > > > I started 2 servers, each of which have an embedded broker. A shell based > chield sends messages to 30 different message groups (using command "register > " in the samepl app provided. Only 2 mesages are received by > server1, 3 by server2 and 25 by server3. The load balancing distribution is > highly unenen. > As suggested, I also tried setting a low destination queue prefetch value > (consumer.prefetch=1) but the result was the same. > To run sample : > 1. Unzip attached file and run "maven.bat" from the oot directory (Maven 1.0) > 2. Open 3 DOS boxes in the dist\bin folder and run > "startoptimizerPooled.bat", "startOptimizerPooled2.bat" and > "startOptimizerPooled3.bat" in each DOS box respectively. > 3. Step 2 starts a network of 3 servers apps which have an embedded broker. > The Spring configuration files for each of these servers is in the dist\conf > directory. > 4. Open another DOS box in dist\bin and start a test client by running > "startClientShell.bat" > 5. This command driver test client accepts commads in the form > "register " > "close " > and "exit" > NOTE: The command "close " is supposed to close/reset the > message group by issueing a "JMSXGroupSeq" header as described here : > http://www.activemq.org/site/message-groups.html > 6. Try sending several messages to the server by issuing several commands > like "regeister A", "register B", "register C" and so on.. You'll see the > highly uneven distibution of messages. Only one or two messages are received > my 2 servers while the third one receives a majority of the messages. > Please let me know if you have trouble running the sample or replicating the > issue. > Thanks, > Sanjiv -- 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-762) Message Group based load balancing not well distributed across brokers
[ https://issues.apache.org/activemq/browse/AMQ-762?page=comments#action_36536 ] Sunil Bosco Rodrigues commented on AMQ-762: --- Using spring 2.0 and Active MQ 4.0 I had the original problem reported by Craig. INFO Service - Sync error occurred: javax.jms.InvalidClientIDException: Broker: localhost - Client: ID:inspiron-1410-114619274 7453-2:1 already connected I could get this to work by replacing the DefaultMessageListenerFactory with the SimpleMessageListenerFactory class and I did not have this problem. It's a workaround so hope it helps resolving the original issue. Thanks, Rodrigues. > Message Group based load balancing not well distributed across brokers > -- > > Key: AMQ-762 > URL: https://issues.apache.org/activemq/browse/AMQ-762 > Project: ActiveMQ > Type: Bug > Versions: 4.0 > Environment: Active MQ 4.0, Lingo 1.1 > Reporter: Sanjiv Jivan > Attachments: lingocluster.zip > > > I started 2 servers, each of which have an embedded broker. A shell based > chield sends messages to 30 different message groups (using command "register > " in the samepl app provided. Only 2 mesages are received by > server1, 3 by server2 and 25 by server3. The load balancing distribution is > highly unenen. > As suggested, I also tried setting a low destination queue prefetch value > (consumer.prefetch=1) but the result was the same. > To run sample : > 1. Unzip attached file and run "maven.bat" from the oot directory (Maven 1.0) > 2. Open 3 DOS boxes in the dist\bin folder and run > "startoptimizerPooled.bat", "startOptimizerPooled2.bat" and > "startOptimizerPooled3.bat" in each DOS box respectively. > 3. Step 2 starts a network of 3 servers apps which have an embedded broker. > The Spring configuration files for each of these servers is in the dist\conf > directory. > 4. Open another DOS box in dist\bin and start a test client by running > "startClientShell.bat" > 5. This command driver test client accepts commads in the form > "register " > "close " > and "exit" > NOTE: The command "close " is supposed to close/reset the > message group by issueing a "JMSXGroupSeq" header as described here : > http://www.activemq.org/site/message-groups.html > 6. Try sending several messages to the server by issuing several commands > like "regeister A", "register B", "register C" and so on.. You'll see the > highly uneven distibution of messages. Only one or two messages are received > my 2 servers while the third one receives a majority of the messages. > Please let me know if you have trouble running the sample or replicating the > issue. > Thanks, > Sanjiv -- 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: running a snapshot
[/home/bmadigan/workspaces/activemq/trunk/activemq-core] < 0.39 2006/07/07 15:04:10 > $ maven run:broker [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'run'. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] The plugin 'org.apache.maven.plugins:maven-run-plugin' does not exist or no valid version could be found [/home/bmadigan/workspaces/activemq/trunk/assembly] < 0.42 2006/07/07 15:04:05 > $ maven server [INFO] Scanning for projects... [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Invalid task 'server': you must specify a valid lifecycle phase. -- View this message in context: http://www.nabble.com/running-a-snapshot-tf1908015.html#a5223899 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: [jira] Created: (GERONIMO-2170) Tagged versions of Geronimo should not include people.apache.org/repository in their list of maven repositories
On Jul 7, 2006, at 12:47 PM, Matt Hogstrom wrote: I have the repo I released 1.1 on. Should we make this available as an optional download? I like the idea, but not without some review. The repo would contain some binaries which we don't ship in Geronimo. I think we need to do some due diligence first We still need to fix the reference to people.apache.org... --kevan Kevan Miller (JIRA) wrote: Tagged versions of Geronimo should not include people.apache.org/ repository in their list of maven repositories - -- Key: GERONIMO-2170 URL: http://issues.apache.org/jira/browse/GERONIMO-2170 Project: Geronimo Type: Bug Security: public (Regular issues) Components: buildsystem Versions: 1.1.1Reporter: Kevan Miller Fix For: 1.1.1 Geronimo 1.1.0 includes people.apache.org/repository in its list of maven repo's. This repository is liable to be relocated in the future and is not used to hold "released" version of packages. A tagged version of geronimo should not be dependent on any resources in this repository. 1.1.1 should not use this repository (and therefore will not be dependent on any resources in the repository). The release checklist should be updated to insure that this mistake is not repeated in the future.
[jira] Resolved: (GERONIMO-1703) ServerInfo.getBaseDirectory() returns null
[ http://issues.apache.org/jira/browse/GERONIMO-1703?page=all ] Paul McMahan resolved GERONIMO-1703: Resolution: Invalid Assign To: Paul McMahan Vamsi, please see my comment from 5/9 which highlights the fact that the current behavior matches the javadoc. If you agree then please close this JIRA. Thanks. > ServerInfo.getBaseDirectory() returns null > -- > > Key: GERONIMO-1703 > URL: http://issues.apache.org/jira/browse/GERONIMO-1703 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: startup/shutdown > Environment: Sun JDK 1.4.2_08, Win XP, Geronimo-Tomcat > Reporter: Vamsavardhana Reddy > Assignee: Paul McMahan > Priority: Critical > Fix For: 1.1.1 > Attachments: ServerInfoWebApp.war, ServerInfoWebApp_g1.1.war > > Calling getBaseDirectory on org.apache.geronimo.system.serverinfo.ServerInfo > returned by KernelManagementHelper.getServerInfo() returns null instead of > Geronimo Base Directory. -- 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-776) ConduitBridge can malfunction when first of a set of consumers goes away
[ https://issues.apache.org/activemq/browse/AMQ-776?page=comments#action_36535 ] Kevin Yaussy commented on AMQ-776: -- I found another scenario, but have not had time to discover whether it is due to problem in ConduitBridge or not. But, it seems likely: +++ Start Broker A Start Publisher, connecting to Broker A, publishing FOO Start Broker B Start Consumer, connecting to Broker B, consuming FOO (needs to use failover on connect url, but just connect to Broker B) kill-9 Broker B Restart Broker B Consumer no longer gets FOO + This problem happens regardless of whether the patched ConduitBridge code is used. > ConduitBridge can malfunction when first of a set of consumers goes away > > > Key: AMQ-776 > URL: https://issues.apache.org/activemq/browse/AMQ-776 > Project: ActiveMQ > Type: Bug > Components: Broker > Versions: 4.0.1 > Reporter: Kevin Yaussy > Priority: Critical > Attachments: ConduitBridge.patch > > > When the following scenario is followed, any of the subsequent consumers will > stop receiving messages. I've reproduced this using the ConsumerTool, and > ProducerTool supplied in the example area of the distribution. > +++ > Start Broker A > Start Broker B > Start Consumer 1, connecting to Broker B, consuming FOO > Start Consumer 2, connecting to Broker B, consuming FOO > Start Publisher, connecting to Broker A, publishing FOO > Ctl-C out of Consumer 1 > Consumer 2 stops receiving messages > +++ > Seems to me that ConduitBridge is supposed to track all consumers for a given > subscription, by way of DemandSubscription. It is seeding DemandSubscription > with the originating consumer, but when subsequent consumers are added, the > ConduitBridge::addToAlreadyInterestedConsumers re-adds the original > subscriber to the DemandSubscription's map - so the map only ever has the > original subscription. > I've attached a patch. Hope the change is good. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1524) DB pool portlet should let you select multiple driver JARs
[ http://issues.apache.org/jira/browse/GERONIMO-1524?page=all ] Paul McMahan reassigned GERONIMO-1524: -- Assign To: Paul McMahan > DB pool portlet should let you select multiple driver JARs > -- > > Key: GERONIMO-1524 > URL: http://issues.apache.org/jira/browse/GERONIMO-1524 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: console > Versions: 1.0 > Reporter: Aaron Mulder > Assignee: Paul McMahan > Priority: Critical > Fix For: 1.1.1 > Attachments: GERONIMO-1524.patch > > Currently the database pool portlet can handle a driver requiring multiple > JARs, but the UI doesn't actually let you select more than one. Some drivers > known to need more include DB/2 and MS SQL Server. Perhaps the screen should > have a checkbox to reveal another 2 driver selection pick lists (the security > realm portlet advanced config screen has an example of revealing extra fields > if you check a particular checkbox). -- 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-2147) Remove javamail-transport from Geronimo build and replace with javamail-provider dependency.
[ http://issues.apache.org/jira/browse/GERONIMO-2147?page=all ] Rick McGuire updated GERONIMO-2147: --- Attachment: notrans2.diff Since originally posted, several files got updated underneath this patch, causing errors when applied. This version is generated from a fresh build. Like with the previous patch, ignore errors on any javamail-transport module and delete that directory before trying to build. > Remove javamail-transport from Geronimo build and replace with > javamail-provider dependency. > > > Key: GERONIMO-2147 > URL: http://issues.apache.org/jira/browse/GERONIMO-2147 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: mail > Versions: 1.2 > Reporter: Rick McGuire > Assignee: Rick McGuire > Fix For: 1.2 > Attachments: notrans.diff, notrans2.diff > > Now that the javamail-provider repository and build is available, it's time > to replace the javamail-transport module in the Geronimo code tree with a > dependency on the javamail_provider_1.3.1 jar file. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1492) Many "org/apache/geronimo" configIds still live in source tree
[ http://issues.apache.org/jira/browse/GERONIMO-1492?page=all ] Paul McMahan reassigned GERONIMO-1492: -- Assign To: Paul McMahan > Many "org/apache/geronimo" configIds still live in source tree > -- > > Key: GERONIMO-1492 > URL: http://issues.apache.org/jira/browse/GERONIMO-1492 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Versions: 1.1 > Reporter: Aaron Mulder > Assignee: Paul McMahan > Priority: Blocker > Fix For: 1.1.1 > Attachments: GERONIMO-1492-1.patch, GERONIMO-1492.diff, > annotated-grep-output.txt > > I created a couple separate issues, but beyond those a quick search brought > up a few more in magic G ball and day trader -- I stopped before it went any > further, but we should grep for that and try to eliminate all the references > to old-style config IDs. -- 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
Official m2 distribution management configuration?
What are the official SCP URLs to the Apache m2 snapshot and release repositories? What are the requirements to push content to these? Like need .ssh/ authorized_keys setup etc... --jason
running a snapshot
I've been trying to install and run a 4.1-SNAPSHOT from source. cd activemq-core maven run:broker maven server none work. Also, how do you build a release from a snapshot for deploying locally? -- View this message in context: http://www.nabble.com/running-a-snapshot-tf1908015.html#a5222527 Sent from the ActiveMQ - Dev forum at Nabble.com.
Re: Geronimo Tooling 1.1 Release Plans
Thanks Paul, see inline... On Jul 7, 2006, at 11:13 AM, Paul McMahan wrote: Sachin, I just checked out the RC3 and it looks GREAT!! I love the fact that using the Eclipse plugin I can create a web project, deploy it to Geronimo, debug/update my JSP and see the changes reflected immediately (and I mean *immediately*) via a simple app republish, "simple app republish" Simple as it is to do, this is still a problem that needs to be solved. And is partially solved in this release. If you are working with static content only, if you open the server editor and select the "run resources from workspace" option, and restart the server and redeploy your app, any changes to static content dont require a republish and you can simply refresh your browser. I want to be able to run an entire ear from within the project without having to generate an ear, and this will take some work in the server to be able to do this. So currently this feature is restricted to stand-alone web apps with static only content. and then export my application as a Geronimo plugin using the admin console launched within Eclipse. This makes it so easy to create, debug, and export applications. Nice work!! I would feel remiss if I didn't provide at least a couple of suggestions, so I would say that it would be nice if you could export Geronimo plugins directly from the navigator without having to launch the admin console. Maybe this could be modeled after Eclipse's own plugin development features. Also, longer term it would be cool if I could create a Geronimo based portal server using, say, Jetspeed or Liferay in Eclipse and deploy portlets to it. I'm interested in helping out if you like these ideas. Best wishes, Paul On 7/7/06, Sachin Patel <[EMAIL PROTECTED]> wrote: So to close out the 1.1 eclipse tooling release here is what I'm planning to do... RC3 is currently available to pull down and test. I still need to do some sniff testing on the update-site distribution and making sure existing 1.0 plugin users can update directly to 1.1. (Since plugins where completely renamed in 1.1.1 I'm hoping eclipse knows how to handle this correctly and disables old plugins not in the latest feature.) After I create the release notes I plan to call a vote within the next 24-48 hours. Looking ahead to 1.1.1 I'm hoping there will not be any incompatible changes in 1.1.1 and so the 1.1 jars I'm repackaging in the eclipse- plugin will work for deployments to 1.1.1. Also the eclipse PDE builder has a feature that supports generating qualified builds that TLPs are now exploiting so projects can provide updates at a much more frequent and granular level. I plan to implement a similar feature in the eclipse plugin m2 build that will allow similar capability. This should help us get to a model where we can have frequent maintenance releases with minimum work for the developer to put out these releases. (i.e simply commit fixes, build, and the generated plugins versions will have generated qualifiers appended to them that can simply pushed to the update site). -sachin -sachin
[long] OSGi overview (was Re: Geronimo/Equinox integration status?)
Jacek, Thanks for the info. On Wed, Jul 05, 2006 at 10:06:46PM +0200, Jacek Laskowski wrote: > On 7/5/06, toby cabot <[EMAIL PROTECTED]> wrote: > >What's the status of the Geronimo/Equinox (OSGi server) integration? > > Dunno, but great you've asked as it was one of the questions during > the Apache Geronimo panel at TSSJS in Barcelona, which James S. > answered positively, i.e. there's a fit for it in Geronimo and it > should or will be soon available. I think Dain mentioned it a couple > of times (it was something about classloading architecture or alike). That's great to hear. I'd be willing to help out. > I wonder how it's different from what we've got now? How does it > compare to XBean if at all? A short introduction would be of help. I'm far from an OSGi expert, but let me take a swing. Either I'll be correct or someone will correct me, and either way we'll learn something. OSGi [1] is both an organization and a specification. The spec [2], currently at release 4 and weighing in at >260 pages, describes what they call a "service platform" [3] which really amounts to an application server. It's somewhat analogous to GBeans in that it specifies the interface between application components and the server that runs them. It's much smaller and less featureful than J2EE, having been originally intended (and still used often) for embedded systems. The spec has been around for quite some time but seems to be gaining a lot more mindshare recently. Probably a big part of that is due to the Eclipse project using OSGi technology inside their IDE. The basic OSGi software package is called a "bundle". A bundle is basically a jar file + metadata. The metadata indicates which "services" a bundle exports and which it depends on; this allows a server to do automatic dependency resolution, so if you ask it to download a particular bundle from a remote bundle server it can first download and start all of the dependencies automatically. There's also a JNDI-ish "registry" within an OSGi server that allows bundles to find services and bind to them at run-time. So I guess you can say that a bundle is somewhere between a GBean and a Configuration, but closer a GBean plus some additional packaging. Within Eclipse, the things that Eclipse calls "plugins" are basically OSGi bundles with some additional Eclipse metadata. >From my admittedly naive perspective, I don't see huge differences between bundles and GBeans, but I wouldn't be surprised if they were there. So far I've seen two integration approaches mentioned - OSGi-centric and Geronimo-centric. The OSGi-centric approach [4] involves taking the various Geronimo services, repackaging them as bundles, and running them in an OSGi server. The Geronimo-centric approach [5] involves building a GBean wrapper around bundles and services, so the GBean server can manage them. In either case I think that having the ability to run J2EE apps *and* OSGi bundles is very powerful. My interest in OSGi technology stems from the fact that my employer uses Geronimo currently but is planning to also support OSGi, so my best-case scenario is a nice integration between the two technologies. Thanks, Toby [1] http://www.osgi.org [2] Specs are "by-request" at http://www.osgi.org/osgi_technology/download_specs.asp?section=2 [3] http://www.osgi.org/osgi_technology/index.asp?section=2 [4] http://www.mail-archive.com/dev@geronimo.apache.org/msg10923.html [5] http://www.mail-archive.com/dev@geronimo.apache.org/msg10822.html
Re: Tag 1.1 issue?
On Jul 7, 2006, at 8:41 AM, Jeff Genender wrote: David Blevins wrote: On Jul 7, 2006, at 6:32 AM, Kevan Miller wrote: On Jul 6, 2006, at 11:30 PM, Jeff Genender wrote: I tried to build the v1.1 of Geronimo tag and I noticed that when I went to do a m:co of openejb, it is giving me the openejb branch instead of the 2.1 tag. Sure enough, upon perusal of the tagged root maven.xml, its pulling the openejb branch and not the tag. I am assuming this is an oversight and it should pull the tag orf openejb, not the branch. Do we need this fixed so we can do a build of our svn tagged 1.1? Yes, I noticed this yesterday, also. The build works if you don't run m:co (the openejb 2.1 dependencies). So, I don't think we need to rush to fix this. Instead we can wait to fix in the normal 1.1.1 release cycle, which I think should be soon (in July). Clearly something that needs to be in a release process checklist. At release time is one of the rare moments where we don't have a snapshot dependency on OpenEJB. Why wouldn't we just disable the m:co? I still believe there is value getting the state of OpenEJB at tagged level and accessing it with m:co. Here is an example... I am trying to research some classloading issues regarding OpenEJB and Geronimo 1.1. It behooves me to have source level access to both OpenEJB and Geronimo for the state of the Geronimo 1.1 release so I can accurately debug the problem. It would be nice to have the m:co checkout the tagged version of OpenEJB since we are not really supposed to have any snapshots in there. Makes sense. -David
Re: Tag 1.1 issue?
Hi Jeff,I think dropping the m:co is fine as long as there is a way to get to the source code. I did not see openejb src released with the jar's here;http://www.ibiblio.org/maven2/openejb/openejb-core/2.0/but if I recall correctly its a snap to get m2 to push src jars as well. Maybe we could get one pushed from the tag and then disable the m:co?Just a thought.TTFN, Bill DudneyMyFaces - http://myfaces.apache.orgCayenne - http://incubator.apache.org/projects/cayenne.htmlOn Jul 7, 2006, at 11:47 AM, Jeff Genender wrote:I agree, but if we are not using snapshots, i.e. a true release ofopenejb, then this should be a moot point...the m:co could be changed topoint at the openejb tag rather than the branch. If we aren't going torun after this, then I may go along with the best thing to do is toremove the m:co as it will give very bad results (as I and others havefound). Thoughts?JeffMatt Hogstrom wrote: It would be nice to have closure on this. Perhaps, we'll have it whenOpenEJB makes it to Apache. However, we've had issues with other Apacheprojects not releasing on time...Axis is the example that comes to mind.I think it would be nice to have everything bundled up but in manyrespects its outside our control.Jeff Genender wrote: David Blevins wrote: On Jul 7, 2006, at 6:32 AM, Kevan Miller wrote: On Jul 6, 2006, at 11:30 PM, Jeff Genender wrote: I tried to build the v1.1 of Geronimo tag and I noticed that when Iwentto do a m:co of openejb, it is giving me the openejb branch instead ofthe 2.1 tag. Sure enough, upon perusal of the tagged root maven.xml,its pulling the openejb branch and not the tag.I am assuming this is an oversight and it should pull the tag orfopenejb, not the branch. Do we need this fixed so we can do abuild ofour svn tagged 1.1? Yes, I noticed this yesterday, also. The build works if you don't runm:co (the openejb 2.1 dependencies). So, I don't think we need to rushto fix this. Instead we can wait to fix in the normal 1.1.1 releasecycle, which I think should be soon (in July).Clearly something that needs to be in a release process checklist. At release time is one of the rare moments where we don't have asnapshot dependency on OpenEJB. Why wouldn't we just disable the m:co? I still believe there is value getting the state of OpenEJB at taggedlevel and accessing it with m:co. Here is an example...I am trying to research some classloading issues regarding OpenEJB andGeronimo 1.1. It behooves me to have source level access to bothOpenEJB and Geronimo for the state of the Geronimo 1.1 release so I canaccurately debug the problem. It would be nice to have the m:cocheckout the tagged version of OpenEJB since we are not really supposedto have any snapshots in there. -David
Re: Tag 1.1 issue?
I agree, but if we are not using snapshots, i.e. a true release of openejb, then this should be a moot point...the m:co could be changed to point at the openejb tag rather than the branch. If we aren't going to run after this, then I may go along with the best thing to do is to remove the m:co as it will give very bad results (as I and others have found). Thoughts? Jeff Matt Hogstrom wrote: > It would be nice to have closure on this. Perhaps, we'll have it when > OpenEJB makes it to Apache. However, we've had issues with other Apache > projects not releasing on time...Axis is the example that comes to mind. > > I think it would be nice to have everything bundled up but in many > respects its outside our control. > > Jeff Genender wrote: >> >> David Blevins wrote: >>> On Jul 7, 2006, at 6:32 AM, Kevan Miller wrote: >>> On Jul 6, 2006, at 11:30 PM, Jeff Genender wrote: > I tried to build the v1.1 of Geronimo tag and I noticed that when I > went > to do a m:co of openejb, it is giving me the openejb branch instead of > the 2.1 tag. Sure enough, upon perusal of the tagged root maven.xml, > its pulling the openejb branch and not the tag. > > I am assuming this is an oversight and it should pull the tag orf > openejb, not the branch. Do we need this fixed so we can do a > build of > our svn tagged 1.1? Yes, I noticed this yesterday, also. The build works if you don't run m:co (the openejb 2.1 dependencies). So, I don't think we need to rush to fix this. Instead we can wait to fix in the normal 1.1.1 release cycle, which I think should be soon (in July). Clearly something that needs to be in a release process checklist. >>> At release time is one of the rare moments where we don't have a >>> snapshot dependency on OpenEJB. Why wouldn't we just disable the m:co? >>> >> >> I still believe there is value getting the state of OpenEJB at tagged >> level and accessing it with m:co. Here is an example... >> >> I am trying to research some classloading issues regarding OpenEJB and >> Geronimo 1.1. It behooves me to have source level access to both >> OpenEJB and Geronimo for the state of the Geronimo 1.1 release so I can >> accurately debug the problem. It would be nice to have the m:co >> checkout the tagged version of OpenEJB since we are not really supposed >> to have any snapshots in there. >> >>> -David >>> >>> >> >> >>
[jira] Resolved: (AMQ-798) provide a new JMS header to indiciate the first message in a sequence being dispatched to a consumer
[ https://issues.apache.org/activemq/browse/AMQ-798?page=all ] james strachan resolved AMQ-798: Fix Version: 4.1 Resolution: Fixed Now supported with the new boolean header JMSXGroupFirstForConsumer. For more details see... http://activemq.org/site/message-groups.html > provide a new JMS header to indiciate the first message in a sequence being > dispatched to a consumer > > > Key: AMQ-798 > URL: https://issues.apache.org/activemq/browse/AMQ-798 > Project: ActiveMQ > Type: New Feature > Reporter: james strachan > Assignee: james strachan > Fix For: 4.1 > > > This would allow consumers to listen for this message and if the boolean is > set its the first message being dispatched for a group & so the consumer > could flush a cache or something -- 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] Created: (GERONIMO-2170) Tagged versions of Geronimo should not include people.apache.org/repository in their list of maven repositories
I have the repo I released 1.1 on. Should we make this available as an optional download? Kevan Miller (JIRA) wrote: Tagged versions of Geronimo should not include people.apache.org/repository in their list of maven repositories --- Key: GERONIMO-2170 URL: http://issues.apache.org/jira/browse/GERONIMO-2170 Project: Geronimo Type: Bug Security: public (Regular issues) Components: buildsystem Versions: 1.1.1 Reporter: Kevan Miller Fix For: 1.1.1 Geronimo 1.1.0 includes people.apache.org/repository in its list of maven repo's. This repository is liable to be relocated in the future and is not used to hold "released" version of packages. A tagged version of geronimo should not be dependent on any resources in this repository. 1.1.1 should not use this repository (and therefore will not be dependent on any resources in the repository). The release checklist should be updated to insure that this mistake is not repeated in the future.
Re: why may2006 branch and trunk for site
The only reason I can see that a branches would be needed would be to help collaboration when a major redesign of the site is being done. IMO it doesn't hurt anything to keep it. --jason On Jul 7, 2006, at 7:37 AM, Sachin Patel wrote: Why do we have a branch and trunk for the website? Is the may2006 branch dead? If so can we move it out to a tags/may2006 dir? -sachin
Re: Tag 1.1 issue?
It would be nice to have closure on this. Perhaps, we'll have it when OpenEJB makes it to Apache. However, we've had issues with other Apache projects not releasing on time...Axis is the example that comes to mind. I think it would be nice to have everything bundled up but in many respects its outside our control. Jeff Genender wrote: David Blevins wrote: On Jul 7, 2006, at 6:32 AM, Kevan Miller wrote: On Jul 6, 2006, at 11:30 PM, Jeff Genender wrote: I tried to build the v1.1 of Geronimo tag and I noticed that when I went to do a m:co of openejb, it is giving me the openejb branch instead of the 2.1 tag. Sure enough, upon perusal of the tagged root maven.xml, its pulling the openejb branch and not the tag. I am assuming this is an oversight and it should pull the tag orf openejb, not the branch. Do we need this fixed so we can do a build of our svn tagged 1.1? Yes, I noticed this yesterday, also. The build works if you don't run m:co (the openejb 2.1 dependencies). So, I don't think we need to rush to fix this. Instead we can wait to fix in the normal 1.1.1 release cycle, which I think should be soon (in July). Clearly something that needs to be in a release process checklist. At release time is one of the rare moments where we don't have a snapshot dependency on OpenEJB. Why wouldn't we just disable the m:co? I still believe there is value getting the state of OpenEJB at tagged level and accessing it with m:co. Here is an example... I am trying to research some classloading issues regarding OpenEJB and Geronimo 1.1. It behooves me to have source level access to both OpenEJB and Geronimo for the state of the Geronimo 1.1 release so I can accurately debug the problem. It would be nice to have the m:co checkout the tagged version of OpenEJB since we are not really supposed to have any snapshots in there. -David
Re: [heads up] moved test cases from assembly to core...
Yeah.. I've also felt that if we did have tests in the assembly module, they should be testing things like.. unzip that assembly and verify that the default configuration works in that assembly. Also that the examples work in the assembly. etc. etc. Stuff related to testing the packaging. Perhaps even tests that make sure the we have READMEs and NOTICE files. Regards, Hiram On 7/7/06, James Strachan <[EMAIL PROTECTED]> wrote: On 7/7/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: > Sounds fine to me. Its always kinda bugged me that you'd have to wait for an entire assembly to build to know if you'd broken something in activemq-core :) Plus it was much easier doing this than figuring out why the tests were not running in the assembly module :) > On 7/7/06, James Strachan <[EMAIL PROTECTED]> wrote: > > > > We had a bunch of test cases in the assembly module that were not > > being executed in the m2 build for some reason; its also for legacy > > reasons they were there, they are better suited to being closer to the > > actual code they test so I've just moved them to the activemq-core > > project. > > > > So don't panic if you do a svn update; there's not loads more (slow) > > tests been added :) they've just been moved about a bit :) > > > > -- > > > > James > > --- > > http://radio.weblogs.com/0112098/ > > > > > > -- > Regards, > Hiram > > Blog: http://hiramchirino.com > > -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com
Re: [heads up] moved test cases from assembly to core...
On 7/7/06, Hiram Chirino <[EMAIL PROTECTED]> wrote: Sounds fine to me. Its always kinda bugged me that you'd have to wait for an entire assembly to build to know if you'd broken something in activemq-core :) Plus it was much easier doing this than figuring out why the tests were not running in the assembly module :) On 7/7/06, James Strachan <[EMAIL PROTECTED]> wrote: > > We had a bunch of test cases in the assembly module that were not > being executed in the m2 build for some reason; its also for legacy > reasons they were there, they are better suited to being closer to the > actual code they test so I've just moved them to the activemq-core > project. > > So don't panic if you do a svn update; there's not loads more (slow) > tests been added :) they've just been moved about a bit :) > > -- > > James > --- > http://radio.weblogs.com/0112098/ > -- Regards, Hiram Blog: http://hiramchirino.com -- James --- http://radio.weblogs.com/0112098/
Re: [heads up] moved test cases from assembly to core...
Sounds fine to me. On 7/7/06, James Strachan <[EMAIL PROTECTED]> wrote: We had a bunch of test cases in the assembly module that were not being executed in the m2 build for some reason; its also for legacy reasons they were there, they are better suited to being closer to the actual code they test so I've just moved them to the activemq-core project. So don't panic if you do a svn update; there's not loads more (slow) tests been added :) they've just been moved about a bit :) -- James --- http://radio.weblogs.com/0112098/ -- Regards, Hiram Blog: http://hiramchirino.com
Re: Message Filtering
Hi Stephs On 7/7/06, stephans <[EMAIL PROTECTED]> wrote: Hi folks, i am currently writing my master thesis on improving filter performance in publish/subscribe environments. Interesting! :) Can anyone of you outline how filtering is done in activemq, i.e. if you are using the counting algorithm or more advanced approaches like building a matching tree from subscriptions like mentioned in the paper by aguilera/strom or something like that? I would appreciate any answers from you. The code for the filtering is all here BTW... http://incubator.apache.org/activemq/maven/activemq-core/xref/org/apache/activemq/filter/package-summary.html for topic wildcards like A.B.C or A.B.* or A.> and so forth we use a DestinationMap which is a matching tree of the path names... http://incubator.apache.org/activemq/maven/activemq-core/xref/org/apache/activemq/filter/DestinationMap.html but for selectors (arbitrary SQL 92 predicates on the message which the variables usually refer to headers) are implemented typically by just evaluating a usual predicate tree, per consumer right now. The only tricky area is that often consumers pull messages when they have spare buffers; so an optimised filter engine with some kind of predicate tree would have to work in a pull rather than push mode maybe. e.g. we could evaluate all the filters when a message comes in & remember which consumer match. Or what we do right now is only evaluate a filter when there is a consumer who is attempting to fill its buffer of available messages. So maybe something in between the two? -- James --- http://radio.weblogs.com/0112098/
Re: Message Filtering
HI Stephs, We do a have some initial work do optimizing selectors for when many selectors are being used against the same destination. All the selector evaluation logic is in the org.apache.activemq.filter package. We did some initial experiments with a MultiExpressionEvaluator which allowed caching results of common expressions in multiple expression trees. ActiveMQ we using a different threading model at the time that was created.. It needs to get update so that it works with the simpler threading model we have now. Basically before we evaluate a message against a set of selectors, a MessageEvaluationContext is created so that results of the expression evaluations can be cached there. After all the selectors are evaluated, the context is cleared. So... we need more help in this area to make our selector more efficient.. Are you volunteering? On 7/7/06, stephans <[EMAIL PROTECTED]> wrote: Hi folks, i am currently writing my master thesis on improving filter performance in publish/subscribe environments. Can anyone of you outline how filtering is done in activemq, i.e. if you are using the counting algorithm or more advanced approaches like building a matching tree from subscriptions like mentioned in the paper by aguilera/strom or something like that? I would appreciate any answers from you. Greetings, Stephs -- View this message in context: http://www.nabble.com/Message-Filtering-tf1905917.html#a5215793 Sent from the ActiveMQ - Dev forum at Nabble.com. -- Regards, Hiram Blog: http://hiramchirino.com
Re: Tag 1.1 issue?
David Blevins wrote: > > On Jul 7, 2006, at 6:32 AM, Kevan Miller wrote: > >> >> On Jul 6, 2006, at 11:30 PM, Jeff Genender wrote: >> >>> I tried to build the v1.1 of Geronimo tag and I noticed that when I went >>> to do a m:co of openejb, it is giving me the openejb branch instead of >>> the 2.1 tag. Sure enough, upon perusal of the tagged root maven.xml, >>> its pulling the openejb branch and not the tag. >>> >>> I am assuming this is an oversight and it should pull the tag orf >>> openejb, not the branch. Do we need this fixed so we can do a build of >>> our svn tagged 1.1? >> >> Yes, I noticed this yesterday, also. The build works if you don't run >> m:co (the openejb 2.1 dependencies). So, I don't think we need to rush >> to fix this. Instead we can wait to fix in the normal 1.1.1 release >> cycle, which I think should be soon (in July). >> >> Clearly something that needs to be in a release process checklist. > > At release time is one of the rare moments where we don't have a > snapshot dependency on OpenEJB. Why wouldn't we just disable the m:co? > I still believe there is value getting the state of OpenEJB at tagged level and accessing it with m:co. Here is an example... I am trying to research some classloading issues regarding OpenEJB and Geronimo 1.1. It behooves me to have source level access to both OpenEJB and Geronimo for the state of the Geronimo 1.1 release so I can accurately debug the problem. It would be nice to have the m:co checkout the tagged version of OpenEJB since we are not really supposed to have any snapshots in there. > -David > >
Re: Help: Mapping to Apache Directory project's new groupId:artifactId
If we don't use the in our assembly descriptor to copy
the modules from the local repo to geronimo repo, then we won't see
this problem of an invalid pom. Since installing the car will install
almost all of the modules into the geronimo repository for us, we can
skip for now. Moreover, I have learnt that using the
to copy all modules into G repo was only a convenience
feature. It is not actually needed for the server to start.
So for now, we don't have to worry about moving to the latest apache
directory version. It doesn't affect our m2 migration work. But
eventually we will have to contend this issue and then we'll have to
map those 4 artifacts to their latest equivalents.
Thanx
Prasad
On 7/7/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote:
Here's another idea. We could just fix the pom for
directory-protocols:ldap-protocol:0.9.2 and publish it to one of our
repos. This will be a quick fix and we could get on with our assembly
work. But we will be staying at whatever versions of the Apache
directory artifacts that we had in 1.1
I guess eventually we'll have to move to the latest version of Apache
directory in our 1.2.
Cheers
Prasad
On 7/6/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote:
> Alex, Enrique,
>
> The assembly of G in m2 is failing because we can't find valid poms
> for Apache directory artifacts. Our module geronimo-directory depends
> on apache directory artifacts. The Apache directory artifacts now have
> moved under the groupId "org.apache.directory"
> http://www.ibiblio.org/maven2/org/apache/directory/
>
> I have begun changing geronimo/directory/pom.xml to refelct the new
> groupId:artifactId of the Apache directory artifacts.
>
> After those changes, the java code in geronimo-directory module has to
> be changed to reflect the new package names in the dependencies.
>
> Below, you'll see an excerpt of the geronimo/directory/pom.xml listing
> the directory dependencies. I think I was able to map most of the
> dependencies to the new groupId:artifactId. Please see comments inline
> and verify those.
>
> I wasn't able to do so for the first 4 dependencies. Any help there
> would be appreciated.
>
>
>
> directory-asn1
> asn1-codec
> ${asn1Version}
>
>
>
> directory-asn1
> asn1-ber
> ${asn1Version}
>
>
>
> directory-asn1
> asn1-der
> ${asn1Version}
>
>
>
> directory-shared
> apache-ldapber-provider
> ${apachedsVersion}
>
>
>
>
> org.apache.directory.server
> apacheds-core
> ${apachedsVersion}
>
>
>
> org.apache.directory.server
>
> apacheds-core-shared
> ${apachedsVersion}
>
>
>
> org.apache.directory.shared
>
> shared-ldap
> ${apachedsVersion}
>
>
>
> org.apache.directory.mina
>
> mina-core
> ${minaVersion}
>
>
>
> org.apache.directory.server
>
> apacheds-kerberos-shared
> ${kerberosCommonVersion}
>
>
>
> org.apache.directory.server
>
> apacheds-protocol-kerberos
> ${kerberosProtocolVersion}
>
>
>
> org.apache.directory.server
>
> apacheds-protocol-ldap
> ${ldapProtocolVersion}
>
>
Re: Tag 1.1 issue?
On Jul 7, 2006, at 6:32 AM, Kevan Miller wrote: On Jul 6, 2006, at 11:30 PM, Jeff Genender wrote: I tried to build the v1.1 of Geronimo tag and I noticed that when I went to do a m:co of openejb, it is giving me the openejb branch instead of the 2.1 tag. Sure enough, upon perusal of the tagged root maven.xml, its pulling the openejb branch and not the tag. I am assuming this is an oversight and it should pull the tag orf openejb, not the branch. Do we need this fixed so we can do a build of our svn tagged 1.1? Yes, I noticed this yesterday, also. The build works if you don't run m:co (the openejb 2.1 dependencies). So, I don't think we need to rush to fix this. Instead we can wait to fix in the normal 1.1.1 release cycle, which I think should be soon (in July). Clearly something that needs to be in a release process checklist. At release time is one of the rare moments where we don't have a snapshot dependency on OpenEJB. Why wouldn't we just disable the m:co? -David
Re: FYI: Planning to upgrade to Derby 10.1.3 for the Geronimo 1.1.1 release (GERONIMO-2155)
Is there more to it that just changing the dependency versions? --jason On Jul 7, 2006, at 6:25 AM, Kevan Miller wrote: On Jul 6, 2006, at 11:04 PM, John Sisson wrote: In the "Derby library does not have line number debug information" mail thread [1] a few weeks ago I asked whether people wanted to upgrade to the Derby 10.1.3 maintenance release [2]. David Jencks was the only person who mentioned it should go in the 1.1.1 release but did not hear any objections from others. If anyone disagrees with this plan, please speak up before I start looking into this next week. John [1] http://www.mail-archive.com/dev@geronimo.apache.org/msg25051.html [2] http://mail-archives.apache.org/mod_mbox/db-derby-user/ 200607.mbox/% [EMAIL PROTECTED] IMO, it fixes/improves our ability to diagnose derby-related problems. So, sounds good to me. Upgrading such a core dependency does imply that we must run all compliance tests on 1.1.1. Something I think we all expect to do anyway... I don't anticipate any problems. However, if we see many problems related to this change, we may want to consider reverting... I'd rather see an early 1.1.1 rather than a delayed 1.1.1 with derby line numbers... --kevan
Re: Geronimo Tooling 1.1 Release Plans
Sachin, I just checked out the RC3 and it looks GREAT!! I love the fact that using the Eclipse plugin I can create a web project, deploy it to Geronimo, debug/update my JSP and see the changes reflected immediately (and I mean *immediately*) via a simple app republish, and then export my application as a Geronimo plugin using the admin console launched within Eclipse. This makes it so easy to create, debug, and export applications. Nice work!! I would feel remiss if I didn't provide at least a couple of suggestions, so I would say that it would be nice if you could export Geronimo plugins directly from the navigator without having to launch the admin console. Maybe this could be modeled after Eclipse's own plugin development features. Also, longer term it would be cool if I could create a Geronimo based portal server using, say, Jetspeed or Liferay in Eclipse and deploy portlets to it. I'm interested in helping out if you like these ideas. Best wishes, Paul On 7/7/06, Sachin Patel <[EMAIL PROTECTED]> wrote: So to close out the 1.1 eclipse tooling release here is what I'm planning to do... RC3 is currently available to pull down and test. I still need to do some sniff testing on the update-site distribution and making sure existing 1.0 plugin users can update directly to 1.1. (Since plugins where completely renamed in 1.1.1 I'm hoping eclipse knows how to handle this correctly and disables old plugins not in the latest feature.) After I create the release notes I plan to call a vote within the next 24-48 hours. Looking ahead to 1.1.1 I'm hoping there will not be any incompatible changes in 1.1.1 and so the 1.1 jars I'm repackaging in the eclipse- plugin will work for deployments to 1.1.1. Also the eclipse PDE builder has a feature that supports generating qualified builds that TLPs are now exploiting so projects can provide updates at a much more frequent and granular level. I plan to implement a similar feature in the eclipse plugin m2 build that will allow similar capability. This should help us get to a model where we can have frequent maintenance releases with minimum work for the developer to put out these releases. (i.e simply commit fixes, build, and the generated plugins versions will have generated qualifiers appended to them that can simply pushed to the update site). -sachin
why may2006 branch and trunk for site
Why do we have a branch and trunk for the website? Is the may2006 branch dead? If so can we move it out to a tags/may2006 dir? -sachin
Re: openejb itests?
Hi Bill,
No. I applied the patch against an existing copy of the trunk tree and
local repo. Let me apply this against the latest tree (the one that
has Jason's big patch). I'll also clean out the local repo. I'll let
you know shortly.
Cheers
Prasad
On 7/7/06, Bill Dudney <[EMAIL PROTECTED]> wrote:
Hi Prasad,
Perhaps I'm missing another patch or something?
The top level pom (geronimo/pom.xml) sets the src directory to 'src/java'.
The deployment plugin has its src in the standard m2 place of
'src/main/java'. Thus nothing gets compiled. I reset the src directory to
'src/main/java' and I get many compile errors.
I applied the patch (and only that patch) to a fresh clean check out of
geronimo Rev 419886 (head of trunk).
I must be missing something if you are able to get a clean compile.
TTFN,
Bill Dudney
MyFaces - http://myfaces.apache.org
Cayenne - http://incubator.apache.org/projects/cayenne.html
On Jul 6, 2006, at 8:04 PM, Prasad Kashyap wrote:
Oh I forgot to mention.
Check the *.log files in the top level module and individual modules.
If I remember right, you can run the mvn site:site command to generate
an HTML page of the results.
Cheers
Prasad
On 7/6/06, Bill Dudney <[EMAIL PROTECTED]> wrote:
Hi Prasad,
Thanks, - I guess I was hoping that it was something smaller :-)
I had to;
1) install the jetty version but changed version to 1.1 and updated
itests/pom.xml to reflect 1.1. instead of 1.1-SNAPSHOT
2) install the tomcat version but changed version to 1.1 and updated
itests/pom.xml to reflect 1.1. instead of 1.1-SNAPSHOT
3) enable the utils
3) delete the explicit mention of version from the maven-site-plugin in
teardown-tests.pom.xml
4) add junit as a dependency otherwise the mvn failed unless
-Dmaven.test.skip=true was specified
5) run mvn
Although the build succeeds, nothing appears to happen (see attached log)
From what I can tell the geronimo-deployment-plugin is not being built
correctly, none of the src's are being compiled and placed into the jar
file. I poked around but the reason escapes me...
TTFN,
Bill Dudney
MyFaces - http://myfaces.apache.org
Cayenne - http://incubator.apache.org/projects/cayenne.html
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO] Geronimo Integration Tests
[INFO] Geronimo :: itests :: system
[INFO] Geronimo :: itests :: webcontainer
[INFO] Geronimo :: itests :: teardown
[INFO]
[INFO] Building Geronimo Integration Tests
[INFO]task-segment: [install]
[INFO]
[INFO] [site:attach-descriptor]
[INFO] [dependency:unpack {execution: unpack}]
[INFO] Configured Artifact:
org.apache.geronimo.distributions:geronimo-jetty-j2ee:null:1.1:zip
[INFO] geronimo-jetty-j2ee-1.1.zip already unpacked.
Downloading:
http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom
[WARNING] Unable to get resource from repository Maven snapshots
(http://cvs.apache.org/maven-snapshot-repository)
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-tomcat-j2ee/1.1/geronimo-tomcat-j2ee-1.1.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
Downloading:
http://cvs.apache.org/maven-snapshot-repository/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom
[WARNING] Unable to get resource from repository Maven snapshots
(http://cvs.apache.org/maven-snapshot-repository)
Downloading:
http://repo1.maven.org/maven2/org/apache/geronimo/distributions/geronimo-jetty-j2ee/1.1/geronimo-jetty-j2ee-1.1.pom
[WARNING] Unable to get resource from repository central
(http://repo1.maven.org/maven2)
[INFO] [antrun:run {execution: prepare}]
[INFO] Executing tasks
[delete] Deleting 1 files from
/private/tmp/foo/sandbox/itests/target/logs
[touch] Creating
/private/tmp/foo/sandbox/itests/target/logs/results.log
[INFO] Executed tasks
[INFO] [install:install]
[INFO] Installing /private/tmp/foo/sandbox/itests/pom.xml
to
/Users/bdudney/.m2/repository/org/apache/geronimo/itests/geronimo-itests-parent/1.0/geronimo-itests-parent-1.0.pom
[INFO]
[INFO] Building Geronimo :: itests :: system
[INFO]task-segment: [install]
[INFO]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Nothing to compile - all classes are up to date
[INFO] [surefire:test]
[INFO] No tests to run.
[INFO] [jar:jar]
[WARNING] JAR will be empty - no content was marked for inc
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On 7/7/06, David Jencks <[EMAIL PROTECTED]> wrote: I think this will have an extremely debilitating and discouraging effect on everyone involved: no one can commit their own code. Yes, it doesn't sound very entertaining. I'll have to think about it again. "No code ownership" is fine, but IMO everyone likes to commit their own work and say to themselves "I did it". You're right again. What I meant was to ensure that a commit won't break others' daily work only because not everything's been committed. It's not that rarely when we couldn't build Geronimo from a fresh checkout. The other effect is that it makes the change known to more than a very few people which increases changes to fix it in case of troubles. I think it will also tend to give the PMC members even more work to do, which they already don't have time for, and is likely to widen the divide between committers and PMC members. It will also be IMO rather confusing: despite review by 3 PMC members I expect the changes will still be best understood by their author, and if the author is NEVER the committer, it will be nearly impossible to find out who was responsible. That's what I thought we want to avoid, i.e. that a change is best understood by its author. That's what makes that some areas are not handled very well and only when Dave J. is involved a fix might be prepared. Re more work for PMCers, it's not quite true - we've already got more work than it's necessary before RTC and only PMCers' votes are binding so we have to do it anyway. When one claims a change has been tested and +1'ed eventually, it means that the process of applying the change has already been done so the additional step would be to execute 'svn ci'. What additional work are we talking about - svn ci? Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Created: (GERONIMO-2170) Tagged versions of Geronimo should not include people.apache.org/repository in their list of maven repositories
Tagged versions of Geronimo should not include people.apache.org/repository in their list of maven repositories --- Key: GERONIMO-2170 URL: http://issues.apache.org/jira/browse/GERONIMO-2170 Project: Geronimo Type: Bug Security: public (Regular issues) Components: buildsystem Versions: 1.1.1 Reporter: Kevan Miller Fix For: 1.1.1 Geronimo 1.1.0 includes people.apache.org/repository in its list of maven repo's. This repository is liable to be relocated in the future and is not used to hold "released" version of packages. A tagged version of geronimo should not be dependent on any resources in this repository. 1.1.1 should not use this repository (and therefore will not be dependent on any resources in the repository). The release checklist should be updated to insure that this mistake is not repeated 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
[jira] Created: (GERONIMO-2169) Once tagged, the m:co goal of tags/1.1.1 should checkout the corresponding tagged version of OpenEJB (not a branch)
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 Type: Bug Security: public (Regular issues) Components: buildsystem Versions: 1.1.1 Reporter: Kevan Miller 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: [RTC] Vote on GERONIMO-2161 - restart 1
On 7/7/06, Jeff Genender <[EMAIL PROTECTED]> wrote: Hey Jacek, BTW, I apologize about the blessing of the final 3 +1s within the 18 hours period. I did not mean to go against your statement. I just recalled an email about 3 +1s allowed it to happen and there was no need to wait...that a -1 could be waged at anytime in the future. If I stepped over the line here, then my complete apologies. I think I may be trying to feel my way through this as well...and I may bump into a wall every now and then. It was my fault and am very glad you've stepped in and help me to understand my mistake. Thanks, Jeff! (I have never thought I'd be so happy after having been pointed out I was wrong ;-)) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On 7/7/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote: On 7/7/06, David Jencks <[EMAIL PROTECTED]> wrote: > My point of view is that while there might be a minimum time needed > in total for a vote, there is no need to wait after the 3rd +1 as > long as that minumum time since the start of the vote has elapsed. > This vote has been going on with additions for 5 days now with no > technical objections, although jason has enhanced the patch in > several ways. Anyone with the slightest concerns about this patch > has had more than adequate time to object, and they continue to be > able to object till the heat death of the universe. I disagree. If it's required new voting, it has to end at the 24-hour period finish. In other scenarios, you're right (and that's why I wrote about the 18-hour time period since Matt begun the vote 6 hours ago). I don't know why I claimed the 24-hour period was required. I appologize for it, Dave. I'm really, really sorry and appreciate your patience. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On 7/7/06, Kevan Miller <[EMAIL PROTECTED]> wrote: I'd rather not troll back through the postings, but I certainly recall that the same guidelines -- there wasn't a minimum time period for an RTC vote. Once you have 3 +1's you would be able to commit and there can still be a -1 at any time (hopefully with some statute of limitation) that will force the commit to be reverted. I think this process works. I'd also expect that a -1 would be preceded by a healthy discussion berore the -1... Yes, you're right. I was mistaken. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Tag 1.1 issue?
On Jul 6, 2006, at 11:30 PM, Jeff Genender wrote: I tried to build the v1.1 of Geronimo tag and I noticed that when I went to do a m:co of openejb, it is giving me the openejb branch instead of the 2.1 tag. Sure enough, upon perusal of the tagged root maven.xml, its pulling the openejb branch and not the tag. I am assuming this is an oversight and it should pull the tag orf openejb, not the branch. Do we need this fixed so we can do a build of our svn tagged 1.1? Yes, I noticed this yesterday, also. The build works if you don't run m:co (the openejb 2.1 dependencies). So, I don't think we need to rush to fix this. Instead we can wait to fix in the normal 1.1.1 release cycle, which I think should be soon (in July). Clearly something that needs to be in a release process checklist. I also noticed that the tagged 1.1.0 is using people.apache.org/ repository. A tagged release should not be dependent on anything in that repository. Removing the repo, will bring up another issue, some of our dependencies only reside in people.apache.org. Namely, 1) commons-modeler-20060524.jar and 2) maven-itest-plugin-1.0.jar These dependencies need to be moved to a more permanent location or removed. --kevan
Re: FYI: Planning to upgrade to Derby 10.1.3 for the Geronimo 1.1.1 release (GERONIMO-2155)
On Jul 6, 2006, at 11:04 PM, John Sisson wrote: In the "Derby library does not have line number debug information" mail thread [1] a few weeks ago I asked whether people wanted to upgrade to the Derby 10.1.3 maintenance release [2]. David Jencks was the only person who mentioned it should go in the 1.1.1 release but did not hear any objections from others. If anyone disagrees with this plan, please speak up before I start looking into this next week. John [1] http://www.mail-archive.com/dev@geronimo.apache.org/msg25051.html [2] http://mail-archives.apache.org/mod_mbox/db-derby-user/ 200607.mbox/% [EMAIL PROTECTED] IMO, it fixes/improves our ability to diagnose derby-related problems. So, sounds good to me. Upgrading such a core dependency does imply that we must run all compliance tests on 1.1.1. Something I think we all expect to do anyway... I don't anticipate any problems. However, if we see many problems related to this change, we may want to consider reverting... I'd rather see an early 1.1.1 rather than a delayed 1.1.1 with derby line numbers... --kevan
Geronimo Tooling 1.1 Release Plans
So to close out the 1.1 eclipse tooling release here is what I'm planning to do... RC3 is currently available to pull down and test. I still need to do some sniff testing on the update-site distribution and making sure existing 1.0 plugin users can update directly to 1.1. (Since plugins where completely renamed in 1.1.1 I'm hoping eclipse knows how to handle this correctly and disables old plugins not in the latest feature.) After I create the release notes I plan to call a vote within the next 24-48 hours. Looking ahead to 1.1.1 I'm hoping there will not be any incompatible changes in 1.1.1 and so the 1.1 jars I'm repackaging in the eclipse- plugin will work for deployments to 1.1.1. Also the eclipse PDE builder has a feature that supports generating qualified builds that TLPs are now exploiting so projects can provide updates at a much more frequent and granular level. I plan to implement a similar feature in the eclipse plugin m2 build that will allow similar capability. This should help us get to a model where we can have frequent maintenance releases with minimum work for the developer to put out these releases. (i.e simply commit fixes, build, and the generated plugins versions will have generated qualifiers appended to them that can simply pushed to the update site). -sachin
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On Jul 7, 2006, at 8:40 AM, Jeff Genender wrote: Hey Jacek, BTW, I apologize about the blessing of the final 3 +1s within the 18 hours period. I did not mean to go against your statement. I just recalled an email about 3 +1s allowed it to happen and there was no need to wait...that a -1 could be waged at anytime in the future. If I stepped over the line here, then my complete apologies. I think I may be trying to feel my way through this as well...and I may bump into a wall every now and then. I'd rather not troll back through the postings, but I certainly recall that the same guidelines -- there wasn't a minimum time period for an RTC vote. Once you have 3 +1's you would be able to commit and there can still be a -1 at any time (hopefully with some statute of limitation) that will force the commit to be reverted. I think this process works. I'd also expect that a -1 would be preceded by a healthy discussion berore the -1... --kevan Jeff Jacek Laskowski wrote: On 7/7/06, Jason Dillon <[EMAIL PROTECTED]> wrote: This is applied. :-) Took longer than expected because I happened to switch to a terminal that was set to use JDK 1.5 and I did not realize it... until a few hours later after I was pulling my hair out wondering why the patch god hates me so much. It's because it needs a solution as I think you won't be alone in your pain of applying patches/changes that are incompatible with the unix patch command. I think it would be much better if the person who makes a change is not the one who commits it to trunk, but the last PMCer who voted for it. And a branch the change is built from is established. The solution has such a good effect that the person who works on changes don't have to worry about the commit date until it's rejected when (s)he or anyone else will fix it and a vote starts over (with 24-hour time period). Another good effect is that knowing the revisions a change that's being voted, one can continue his/her work without worrying about disrupting the vote process as the revisions are still in the branch. Phew, I do like the idea! ;-) WDYT? --jason Jacek
Re: Errors while using Geronimo Eclipse Plugin RC2
Thats what I like to hear :) On Jul 7, 2006, at 8:40 AM, Shiva Kumar H R wrote: :) After using WTP 1.5 & Eclipse 3.2, the dialog size problem disappeared. Also, tried launching Geronimo Console from within Eclipse using 1.1 RC3 plugin and it works. - Shiva On 7/6/06, Sachin Patel <[EMAIL PROTECTED]> wrote: As far as the UI problem of the dialog size, can you open a JIRA and attach the screen shot to it. Also since you're the SWT/JFace expert :) if I point you to the code, would you be able to provide a quick fix? Thanks. On Jul 6, 2006, at 10:08 AM, Sachin Patel wrote: > > On Jul 6, 2006, at 8:28 AM, Shiva Kumar H R wrote: > >> Hi Sachin, >> I tried using WTP 1.5 and Eclipse 3.2. The problems mentioned >> earlier disappear and I am able to start/stop the server >> successfully. >> >> However after the server gets started, when I right click on the >> server, I see that "Launch Geronimo Console" is disabled. Isn't >> this a bug? Shall I open a JIRA for the same? > > Yes, I noticed this as well, please open a JIRA. > >> >> I also observed that the ".log" file in my "eclipse\workspace >> \.metadata" directory has the following messages logged. Do you >> suspect any problem here? > > No this is ok and just a warning. I can't remove the duplicate > extensions because they are being inserted automatically by EMF > during the build. > >> - >> - >> !SESSION 2006-07-06 17:50: 17.529 >> --- >> eclipse.buildId=M20060629-1905 >> java.version=1.4.2_08 >> java.vendor=Sun Microsystems Inc. >> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US >> Command-line arguments: -os win32 -ws win32 -arch x86 -clean >> >> !ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524 >> !MESSAGE Both 'org.apache.geronimo.deployment.model' and >> 'org.apache.geronimo.v11.deployment.model' register an extension >> parser for 'deployment' >> >> !ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524 >> !MESSAGE Both ' org.apache.geronimo.deployment.model' and >> 'org.apache.geronimo.v11.deployment.model' register an extension >> parser for 'naming' >> >> !ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50: 41.534 >> !MESSAGE Both 'org.apache.geronimo.deployment.model' and >> 'org.apache.geronimo.v11.deployment.model' register an extension >> parser for 'web' >> - >> - >> >> - Shiva Kumar >> >> On 7/5/06, Sachin Patel <[EMAIL PROTECTED]> wrote: Can you retry >> using the callisto release (WTP 1.5, and Eclipse 3.2)? >> This is what the plugin is built on and supports. >> >> On Jul 5, 2006, at 9:05 AM, Shiva Kumar H R wrote: >> >> > Hi, >> > I am using http://people.apache.org/dist/geronimo/eclipse/ unstable/ >> > g-eclipse-plugin-1.1-RC2.zip with Eclipse 3.1.2 and WTP 1.0.2 >> > (build wtp-sdk-R-1.0.2-200604200208). >> > >> > 1) While defining a New Server, during this dialog "New Apache >> > Geronimo v1.1 Runtime: Please enter the directory where Geronimo is >> > currently installed or where you would like it to be installed." as >> > shown in attachment " 1.GIF", once I specify the "Application >> > Server Installation Directory", the upper portion of the Dialog >> > gets reduced in size leaving me unable to see the message/info >> > there, as shown in attachment "2.GIF ". Although this doesn't stop >> > me from defining a new server, I miss out on the information which >> > was displayed during that dialog. >> > >> > 2) After defining the server (I have the following server >> > installed: Geronimo 1.1 with Jetty with Sun JDK 1.4.2_08), when I >> > try to start the server, server does get started with the below >> > messages in "Console" view: >> > >> - >> - >> > - >> > ... >> > 18:22:49,519 DEBUG [GBeanSingleReference] Waiting to start >> geronimo/ >> > remote-deploy-jetty/1.1/car? >> J2EEApplication=null,WebModule=geronimo/ >> > remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=jsp because no >> > targets are running for reference JettyServletRegistration matching >> > the patterns geronimo/remote-deploy-jetty/1.1/car? >> > J2EEApplication=null,j2eeType=WebModule,name=geronimo/remote- >> deploy- >> > jetty/1.1/car >> > 18:22:49,649 DEBUG [GBeanSingleReference] Waiting to start >> geronimo/ >> > remote-deploy-jetty/1.1/car? >> J2EEApplication=null,WebModule=geronimo/ >> > remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=file-upload >> > because no targets are running for reference Previous matching the >> > patterns geronimo/remote-deploy-jetty/1.1/car? >> > J2EEApplication=null,WebModule=geronimo/remote-deploy-jetty/1.1/ >> > car,j2eeType=Servlet,name=404-error >> > Geronimo star
Re: Thoughts on restructuring
Cool idea :) P On 7/7/06, James Strachan <[EMAIL PROTECTED]> wrote: On 7/7/06, Philip Dodds <[EMAIL PROTECTED]> wrote: > Yeah - actually we might want to do something like : > > * container > * core tooling (just currently the jbi-maven-plugin) > * components > * archetypes > * other tooling like web applications, portal stuff, high end tools, > eclipse tooling etc > > Since the archetypes are sort out outside of the tooling world and I can see > there being quite a few archetypes. Agreed. We might get clever one day and auto-generate some instances from the artifacts and try deploy them in servicemix as an integration test. -- James --- http://radio.weblogs.com/0112098/
Re: Thoughts on restructuring
On 7/7/06, Philip Dodds <[EMAIL PROTECTED]> wrote: Yeah - actually we might want to do something like : * container * core tooling (just currently the jbi-maven-plugin) * components * archetypes * other tooling like web applications, portal stuff, high end tools, eclipse tooling etc Since the archetypes are sort out outside of the tooling world and I can see there being quite a few archetypes. Agreed. We might get clever one day and auto-generate some instances from the artifacts and try deploy them in servicemix as an integration test. -- James --- http://radio.weblogs.com/0112098/
Re: Errors while using Geronimo Eclipse Plugin RC2
:) After using WTP 1.5 & Eclipse 3.2, the dialog size problem disappeared. Also, tried launching Geronimo Console from within Eclipse using 1.1 RC3 plugin and it works.- Shiva On 7/6/06, Sachin Patel <[EMAIL PROTECTED]> wrote: As far as the UI problem of the dialog size, can you open a JIRA andattach the screen shot to it. Also since you're the SWT/JFaceexpert :) if I point you to the code, would you be able to provide aquick fix? Thanks.On Jul 6, 2006, at 10:08 AM, Sachin Patel wrote:>> On Jul 6, 2006, at 8:28 AM, Shiva Kumar H R wrote:>>> Hi Sachin,>> I tried using WTP 1.5 and Eclipse 3.2. The problems mentioned >> earlier disappear and I am able to start/stop the server>> successfully. However after the server gets started, when I right click on the>> server, I see that "Launch Geronimo Console" is disabled. Isn't >> this a bug? Shall I open a JIRA for the same?>> Yes, I noticed this as well, please open a JIRA.> I also observed that the ".log" file in my "eclipse\workspace >> \.metadata" directory has the following messages logged. Do you>> suspect any problem here?>> No this is ok and just a warning. I can't remove the duplicate> extensions because they are being inserted automatically by EMF > during the build.>>> ->> ->> !SESSION 2006-07-06 17:50: 17.529 >> --->> eclipse.buildId=M20060629-1905>> java.version=1.4.2_08>> java.vendor=Sun Microsystems Inc.>> BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US >> Command-line arguments: -os win32 -ws win32 -arch x86 -clean !ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524>> !MESSAGE Both 'org.apache.geronimo.deployment.model' and >> 'org.apache.geronimo.v11.deployment.model' register an extension>> parser for 'deployment' !ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50:41.524>> !MESSAGE Both ' org.apache.geronimo.deployment.model' and>> 'org.apache.geronimo.v11.deployment.model' register an extension>> parser for 'naming' !ENTRY org.eclipse.emf.ecore 2 0 2006-07-06 17:50: 41.534>> !MESSAGE Both 'org.apache.geronimo.deployment.model' and>> 'org.apache.geronimo.v11.deployment.model' register an extension>> parser for 'web'>> - >> - - Shiva Kumar On 7/5/06, Sachin Patel <[EMAIL PROTECTED]> wrote: Can you retry >> using the callisto release (WTP 1.5, and Eclipse 3.2)?>> This is what the plugin is built on and supports. On Jul 5, 2006, at 9:05 AM, Shiva Kumar H R wrote: > Hi, >> > I am using http://people.apache.org/dist/geronimo/eclipse/unstable/>> > g-eclipse-plugin-1.1-RC2.zip with Eclipse 3.1.2 and WTP 1.0.2>> > (build wtp-sdk-R-1.0.2-200604200208).>> >>> > 1) While defining a New Server, during this dialog "New Apache>> > Geronimo v1.1 Runtime: Please enter the directory where Geronimo is >> > currently installed or where you would like it to be installed." as>> > shown in attachment " 1.GIF", once I specify the "Application>> > Server Installation Directory", the upper portion of the Dialog >> > gets reduced in size leaving me unable to see the message/info>> > there, as shown in attachment "2.GIF ". Although this doesn't stop>> > me from defining a new server, I miss out on the information which >> > was displayed during that dialog.>> >>> > 2) After defining the server (I have the following server>> > installed: Geronimo 1.1 with Jetty with Sun JDK 1.4.2_08), when I >> > try to start the server, server does get started with the below>> > messages in "Console" view:>> >>> - >> ->> > ->> > ...>> > 18:22:49,519 DEBUG [GBeanSingleReference] Waiting to start>> geronimo/>> > remote-deploy-jetty/1.1/car? >> J2EEApplication=null,WebModule=geronimo/>> > remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=jsp because no>> > targets are running for reference JettyServletRegistration matching >> > the patterns geronimo/remote-deploy-jetty/1.1/car?>> > J2EEApplication=null,j2eeType=WebModule,name=geronimo/remote->> deploy->> > jetty/1.1/car>> > 18:22:49,649 DEBUG [GBeanSingleReference] Waiting to start >> geronimo/>> > remote-deploy-jetty/1.1/car?>> J2EEApplication=null,WebModule=geronimo/>> > remote-deploy-jetty/1.1/car,j2eeType=Servlet,name=file-upload>> > because no targets are running for reference Previous matching the >> > patterns geronimo/remote-deploy-jetty/1.1/car?>> > J2EEApplication=null,WebModule=geronimo/remote-deploy-jetty/1.1/>> > car,j2eeType=Servlet,name=404-error>> > Geronimo startup complete >> >>> ->> ->> > ->> >>> > However the "Servers" view still shows th
Re: [RTC] Vote on GERONIMO-2161 - restart 1
Hey Jacek, BTW, I apologize about the blessing of the final 3 +1s within the 18 hours period. I did not mean to go against your statement. I just recalled an email about 3 +1s allowed it to happen and there was no need to wait...that a -1 could be waged at anytime in the future. If I stepped over the line here, then my complete apologies. I think I may be trying to feel my way through this as well...and I may bump into a wall every now and then. Jeff Jacek Laskowski wrote: > On 7/7/06, Jason Dillon <[EMAIL PROTECTED]> wrote: >> This is applied. >> >> :-) >> >> Took longer than expected because I happened to switch to a terminal >> that was set to use JDK 1.5 and I did not realize it... until a few >> hours later after I was pulling my hair out wondering why the patch >> god hates me so much. > > It's because it needs a solution as I think you won't be alone in your > pain of applying patches/changes that are incompatible with the unix > patch command. > > I think it would be much better if the person who makes a change is > not the one who commits it to trunk, but the last PMCer who voted for > it. And a branch the change is built from is established. The solution > has such a good effect that the person who works on changes don't have > to worry about the commit date until it's rejected when (s)he or > anyone else will fix it and a vote starts over (with 24-hour time > period). Another good effect is that knowing the revisions a change > that's being voted, one can continue his/her work without worrying > about disrupting the vote process as the revisions are still in the > branch. Phew, I do like the idea! ;-) > > WDYT? > >> --jason > > Jacek >
Re: [jira] Updated: (GERONIMO-1737) Plugin migration to Maven 2: geronimo-assembly-plugin
Hooray Wonderful! Thanks Prasad and David Jencks! Cheers Anita --- "David Jencks (JIRA)" wrote: > [ http://issues.apache.org/jira/browse/GERONIMO-1737?page=all ] > > David Jencks updated GERONIMO-1737: > --- > > Attachment: m2-jetty-server.patch > > Using prasad's assembly plugin that I believe he is attaching to this > issue, and trunk as of rev 419642, I got a jetty server with 13 > modules to build using this patch, and it starts!. Many of the > changes such as fixing the openejb groupId may be duplicated in other > patches. > > > Plugin migration to Maven 2: geronimo-assembly-plugin > > - > > > > Key: GERONIMO-1737 > > URL: http://issues.apache.org/jira/browse/GERONIMO-1737 > > Project: Geronimo > > Type: Sub-task > > Security: public(Regular issues) > > Components: buildsystem > > Versions: 1.x > > Reporter: Jacek Laskowski > > Assignee: Prasad Kashyap > > Attachments: m2-jetty-server.patch > > > > It's a task to keep track of the progress of the plugin build > migration to Maven2 > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the > administrators: >http://issues.apache.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: >http://www.atlassian.com/software/jira > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Commented: (GERONIMO-2092) Modules migration to M2
[ http://issues.apache.org/jira/browse/GERONIMO-2092?page=comments#action_12419696 ] Anita Kulshreshtha commented on GERONIMO-2092: -- This test has been passing for last 2 weeks. The maven.test.skip=true in connector can also be removed. The tests are not failing anymore. One test is still failing in connector-builder (rev 418907) . > Modules migration to M2 > --- > > Key: GERONIMO-2092 > URL: http://issues.apache.org/jira/browse/GERONIMO-2092 > Project: Geronimo > Type: Improvement > Security: public(Regular issues) > Components: buildsystem > Versions: 1.2 > Environment: All > Reporter: Anita Kulshreshtha > Fix For: 1.2 > > The work done by Jacek Laskowski, Prasad Kashyap, Anita Kulshreshtha, > reghuram rajakumar vasanthakumari, > Anders Hessellund Jensen, and Andrew Steeley under GERONIMO-851 has been > committed to the new trunk. This issue is to > keep up with the changes to M1 build. -- 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-2168) NPE when deploying RAR
NPE when deploying RAR
--
Key: GERONIMO-2168
URL: http://issues.apache.org/jira/browse/GERONIMO-2168
Project: Geronimo
Type: Bug
Security: public (Regular issues)
Versions: 1.1
Environment: Solaris 9 (Sparc), Java 1.5.0_06 (also appears in 1.4.2_05)
Reporter: Tim Howe
Priority: Critical
I've been using Geronimo 1.0, and now 1.1, as the app server for the
development of a JCA connector for our proprietary EIS and generally
been very happy with it.
I've had no problem running servlets, deploying WARs, and the like.
However, I've run into a problem deploying a RAR that I built. I view
it as highly probably that there's a bug somewhere in my resource
adapter, but it seems to be triggering a bug in Geronimo, which appears
in both Java 1.4.2 and 1.5:
{quote}
{{23:52:38,091 ERROR [GBeanInstanceState] Error while starting; GBean is now in
the FAILED state:
abstractName="com.celebrityresorts/rcc/0/rar?J2EEApplication=null,JCAConnectionFactory=Celebrity%20Resorts%20RCC%20development%20instance,JCAResource=com.celebrityresorts/rcc/0/rar,ResourceAdapter=com.celebrityresorts/rcc/0/rar,ResourceAdapterModule=com.celebrityresorts/rcc/0/rar,j2eeType=JCAManagedConnectionFactory,name=Celebrity%20Resorts%20RCC%20development%20instance"
java.lang.NullPointerException
at java.io.PrintWriter.write(PrintWriter.java:401)
at java.io.PrintWriter.print(PrintWriter.java:546)
at java.io.PrintWriter.println(PrintWriter.java:683)
at java.lang.Throwable.printStackTrace(Throwable.java:510)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.printException(GBeanInstance.java:1047)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.createInstance(GBeanInstance.java:983)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:267)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.start(GBeanInstance.java:526)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.attemptFullStart(GBeanDependency.java:111)
at
org.apache.geronimo.gbean.runtime.GBeanDependency.addTarget(GBeanDependency.java:146)
at
org.apache.geronimo.gbean.runtime.GBeanDependency$1.running(GBeanDependency.java:120)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.fireRunningEvent(BasicLifecycleMonitor.java:173)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor.access$300(BasicLifecycleMonitor.java:41)
at
org.apache.geronimo.kernel.basic.BasicLifecycleMonitor$RawLifecycleBroadcaster.fireRunningEvent(BasicLifecycleMonitor.java:251)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.attemptFullStart(GBeanInstanceState.java:292)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.start(GBeanInstanceState.java:102)
at
org.apache.geronimo.gbean.runtime.GBeanInstanceState.startRecursive(GBeanInstanceState.java:124)
at
org.apache.geronimo.gbean.runtime.GBeanInstance.startRecursive(GBeanInstance.java:540)}}
{quote}
and so on. The only thing I can figure is that somehow the Exception
getting thrown is null, but I can't see how, as it seems to stem from
bq. {{throw new Exception("A reference has failed so construction can not
complete");}}
so I'm very confused. Of course it's also quite late for me and I may
be reading the stack trace wrong.
--
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: Help: Mapping to Apache Directory project's new groupId:artifactId
Here's another idea. We could just fix the pom for
directory-protocols:ldap-protocol:0.9.2 and publish it to one of our
repos. This will be a quick fix and we could get on with our assembly
work. But we will be staying at whatever versions of the Apache
directory artifacts that we had in 1.1
I guess eventually we'll have to move to the latest version of Apache
directory in our 1.2.
Cheers
Prasad
On 7/6/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote:
Alex, Enrique,
The assembly of G in m2 is failing because we can't find valid poms
for Apache directory artifacts. Our module geronimo-directory depends
on apache directory artifacts. The Apache directory artifacts now have
moved under the groupId "org.apache.directory"
http://www.ibiblio.org/maven2/org/apache/directory/
I have begun changing geronimo/directory/pom.xml to refelct the new
groupId:artifactId of the Apache directory artifacts.
After those changes, the java code in geronimo-directory module has to
be changed to reflect the new package names in the dependencies.
Below, you'll see an excerpt of the geronimo/directory/pom.xml listing
the directory dependencies. I think I was able to map most of the
dependencies to the new groupId:artifactId. Please see comments inline
and verify those.
I wasn't able to do so for the first 4 dependencies. Any help there
would be appreciated.
directory-asn1
asn1-codec
${asn1Version}
directory-asn1
asn1-ber
${asn1Version}
directory-asn1
asn1-der
${asn1Version}
directory-shared
apache-ldapber-provider
${apachedsVersion}
org.apache.directory.server
apacheds-core
${apachedsVersion}
org.apache.directory.server
apacheds-core-shared
${apachedsVersion}
org.apache.directory.shared
shared-ldap
${apachedsVersion}
org.apache.directory.mina
mina-core
${minaVersion}
org.apache.directory.server
apacheds-kerberos-shared
${kerberosCommonVersion}
org.apache.directory.server
apacheds-protocol-kerberos
${kerberosProtocolVersion}
org.apache.directory.server
apacheds-protocol-ldap
${ldapProtocolVersion}
Issues Closed: week of 07-07-2006
Project: Apache Geronimo Status: Resolved, Closed (5 items) Updated In Last: Week (7 days) ** Bug * [GERONIMO-2165] Javamail provider component needs dependency update to released 1.1 spec version for javamail 1.3.1 and activation. * [GERONIMO-592] Startup failure in Turkish language settings ** Improvement * [GERONIMO-2159] Corba Spec pom has inconsistent groupId * [GERONIMO-2135] Improve the ActiveMQ GBeans ** Task * [GERONIMO-2161] [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
[RTC] Vote restart on 2 javamail patches
These two patches have been sitting in [RTC] state for 2 weeks now with no activity. The only votes received so far have been non-binding ones. These changes are holding up other work, including trying to convince the James developers to convert to using the Geronimo javamail version. First issue, removing the javamail-transport module and replacing it with a dependency on the javamail-provider jar. http://issues.apache.org/jira/browse/GERONIMO-2147 NOTE: The above patch is another example of an area where svn diff and patch don't work well together. Applying this patch will prompt for a Reverse action on the patch. It doesn't matter how you reply, because after the patch applies, delete the javamail-transport module subdirectory, and this should build ok. Second issue, creating a new javamail 1.4 spec jar. http://issues.apache.org/jira/browse/GERONIMO-2148 Rick
Re: svn commit: r419764 - /geronimo/trunk/m2-plugins/pom.xml
On Jul 7, 2006, at 1:12 AM, Jacek Laskowski wrote: It is when one's doing some non-trivial changes without careful thinking how to sort out issues with testing/applying before they become painful when it comes to applying them to trunk, What exactly are you suggesting by this statement?! --jason
Re: [RTC] Vote on GERONIMO-2161 - restart 1
On Jul 6, 2006, at 11:54 PM, Jacek Laskowski wrote: On 7/7/06, Jason Dillon <[EMAIL PROTECTED]> wrote: This is applied. :-) Took longer than expected because I happened to switch to a terminal that was set to use JDK 1.5 and I did not realize it... until a few hours later after I was pulling my hair out wondering why the patch god hates me so much. It's because it needs a solution as I think you won't be alone in your pain of applying patches/changes that are incompatible with the unix patch command. I think it would be much better if the person who makes a change is not the one who commits it to trunk, but the last PMCer who voted for it. And a branch the change is built from is established. The solution has such a good effect that the person who works on changes don't have to worry about the commit date until it's rejected when (s)he or anyone else will fix it and a vote starts over (with 24-hour time period). Another good effect is that knowing the revisions a change that's being voted, one can continue his/her work without worrying about disrupting the vote process as the revisions are still in the branch. Phew, I do like the idea! ;-) WDYT? I think this will have an extremely debilitating and discouraging effect on everyone involved: no one can commit their own code. "No code ownership" is fine, but IMO everyone likes to commit their own work and say to themselves "I did it". I think it will also tend to give the PMC members even more work to do, which they already don't have time for, and is likely to widen the divide between committers and PMC members. It will also be IMO rather confusing: despite review by 3 PMC members I expect the changes will still be best understood by their author, and if the author is NEVER the committer, it will be nearly impossible to find out who was responsible. non-binding david jencks --jason Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Added confluence pages "Committing patches to the Subversion Repository" and "How to prepare and contribute patches"
On 7/7/06, John Sisson <[EMAIL PROTECTED]> wrote: I have added the page "Committing patches to the Subversion Repository" as a place to document the issues/recommendations involved in applying and committing patches. Excellent! Just thought about the very alike page! I'm going to write a step-by-step procedure on how to work collaboratively with branches before changes are applied to trunk and such a page will help greatly. Once it's done, I'll ask people for their approval. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: [RTC] Vote on GERONIMO-2161 - restart 1
I do not believe that your suggestion to have the final voter commit patches will improve collaboration. I see that by adding another layer of process only adds to the chances that the overall process will fail... and IMO taking too long is a failure. I am open to ideas about how to improve how we work with RTC, but I don't see that your suggestion would be beneficial enough to warrant the additional overhead to manage the process. --jason On Jul 7, 2006, at 1:00 AM, Jacek Laskowski wrote: On 7/7/06, Jason Dillon <[EMAIL PROTECTED]> wrote: -1 to this and any other way ways to slow down progress. We need to find more effective ways to work with RTC, not more ways to put up road blocks. -1 requires more than just a thought or doubt. I don't see how it could slow down a process more than it is now? What's wrong with it? I see only positives no negatives wrt the 'branch' plan. Quoting your words (slightly changed): our committer base is too low to compete in the market and any way to improve it is worth to consider. To be honest, I'm going to -1 any other change that doesn't apply gently and can be tested on a fresh, clean local Geronimo sources copy. It will cost us more time to cut better changes and me to help with their preparation and testing, but will do it if necessary - in the name of improving our collaboration. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: svn commit: r419764 - /geronimo/trunk/m2-plugins/pom.xml
On 7/7/06, Jason Dillon <[EMAIL PROTECTED]> wrote: This is an unfortunate reality that occurs when delaying major changes for a significant period. I disagree, Jason. Quite a contrary. It is when one's doing some non-trivial changes without careful thinking how to sort out issues with testing/applying before they become painful when it comes to applying them to trunk, i.e. the problems testers had were dismissed and noone really knew how the changes were made but the author. It's unnacceptable and am happy to read your comment as supporting the opinion ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[jira] Updated: (GERONIMO-2125) Classpath entries in the web app archive META-INF/MANIFEST.MF are not added to the wep app class path
[ http://issues.apache.org/jira/browse/GERONIMO-2125?page=all ] Mario Ruebsam updated GERONIMO-2125: Environment: 1.1 release (was: 1.1-rc1) Priority: Blocker (was: Major) since it was only a major problem for me which I could work around it is a blocker for people with mixed web and ejb applications > Classpath entries in the web app archive META-INF/MANIFEST.MF are not added > to the wep app class path > - > > Key: GERONIMO-2125 > URL: http://issues.apache.org/jira/browse/GERONIMO-2125 > Project: Geronimo > Type: Bug > Security: public(Regular issues) > Components: deployment > Versions: 1.1 > Environment: 1.1 release > Reporter: Mario Ruebsam > Priority: Blocker > > A working EAR for Geronimo 1.0 with this structure: > app.ear/ > app.jar > cpa.jar > found.jar > webclient.war > The util JARs are referenced from the webclient.war/META-INF/MANIFEST.MF > Class-Path: app.jar cpa.jar found.jar > Deployment of this EAR in G 1.1-rc1 result in ClassNotFoundExceptions because > of the missing classes in the JARs which are not found. > Putting the JARs into the webclient.war/WEB-INF/lib worked. -- 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] Vote on GERONIMO-2161 - restart 1
On 7/7/06, Jason Dillon <[EMAIL PROTECTED]> wrote: -1 to this and any other way ways to slow down progress. We need to find more effective ways to work with RTC, not more ways to put up road blocks. -1 requires more than just a thought or doubt. I don't see how it could slow down a process more than it is now? What's wrong with it? I see only positives no negatives wrt the 'branch' plan. Quoting your words (slightly changed): our committer base is too low to compete in the market and any way to improve it is worth to consider. To be honest, I'm going to -1 any other change that doesn't apply gently and can be tested on a fresh, clean local Geronimo sources copy. It will cost us more time to cut better changes and me to help with their preparation and testing, but will do it if necessary - in the name of improving our collaboration. Jacek -- Jacek Laskowski http://www.laskowski.net.pl
Re: Geronimo v1.1.1 release
On 7/7/06, Alan D. Cabrera <[EMAIL PROTECTED]> wrote: When did we want to push this out the door? I see a lot of work scheduled for this micro release. I think that we should time box this puppy for a freeze on 7/21 and for a release on 7/28. Any issues that haven't been picked up by Monday, with firm commitments to getting the fixes done before the freeze, would get pulled off and, maybe, scheduled for 1.1.2 or 1.2.0. It will be nice to get a nice rhythm on the releases. Thoughts? +1 While I don't know how much work is to be done, it's worth to try out anyway. Who's a release manager/coordinator? Alan? Congrats! ;-) Jacek -- Jacek Laskowski http://www.laskowski.net.pl
[heads up] moved test cases from assembly to core...
We had a bunch of test cases in the assembly module that were not being executed in the m2 build for some reason; its also for legacy reasons they were there, they are better suited to being closer to the actual code they test so I've just moved them to the activemq-core project. So don't panic if you do a svn update; there's not loads more (slow) tests been added :) they've just been moved about a bit :) -- James --- http://radio.weblogs.com/0112098/
Geronimo v1.1.1 release
When did we want to push this out the door? I see a lot of work scheduled for this micro release. I think that we should time box this puppy for a freeze on 7/21 and for a release on 7/28. Any issues that haven't been picked up by Monday, with firm commitments to getting the fixes done before the freeze, would get pulled off and, maybe, scheduled for 1.1.2 or 1.2.0. It will be nice to get a nice rhythm on the releases. Thoughts? Regards, Alan
Re: FYI: Planning to upgrade to Derby 10.1.3 for the Geronimo 1.1.1 release (GERONIMO-2155)
Jason Dillon wrote: Seems reasonable to me. This will also go into trunk? Definitely :-) Regards, John --jason On Jul 6, 2006, at 8:04 PM, John Sisson wrote: In the "Derby library does not have line number debug information" mail thread [1] a few weeks ago I asked whether people wanted to upgrade to the Derby 10.1.3 maintenance release [2]. David Jencks was the only person who mentioned it should go in the 1.1.1 release but did not hear any objections from others. If anyone disagrees with this plan, please speak up before I start looking into this next week. John [1] http://www.mail-archive.com/dev@geronimo.apache.org/msg25051.html [2] http://mail-archives.apache.org/mod_mbox/db-derby-user/200607.mbox/[EMAIL PROTECTED]
Re: [RTC] Vote on GERONIMO-2161 - restart 1
I think it would be much better if the person who makes a change is not the one who commits it to trunk, but the last PMCer who voted for it. And a branch the change is built from is established. The solution has such a good effect that the person who works on changes don't have to worry about the commit date until it's rejected when (s)he or anyone else will fix it and a vote starts over (with 24-hour time period). Another good effect is that knowing the revisions a change that's being voted, one can continue his/her work without worrying about disrupting the vote process as the revisions are still in the branch. Phew, I do like the idea! ;-) WDYT? IMO... way to much process. -1 to this and any other way ways to slow down progress. We need to find more effective ways to work with RTC, not more ways to put up road blocks. --jason
