Re: Update to the wiki for the ActiveMQ CPP library
BTW the code looks great too :) On 7/7/06, James Strachan [EMAIL PROTECTED] wrote: On 7/6/06, Mittler, Nathan [EMAIL PROTECTED] wrote: FYI, I've added a page to the wiki for ActiveMQ CPP: http://www.activemq.org/site/activemq-cpp-client.html Also updated the Integration C++ link on the navigation pane to reference this page instead of CMS and I updated the C Integration page to add a link to this page as well. Great stuff Nate! Documentation rocks :) -- James --- http://radio.weblogs.com/0112098/ -- James --- http://radio.weblogs.com/0112098/
Problem for Persistence in openwire-cpp API
Hi James.Strachan, I am working on openwire-cpp ( for ActiveMQ-4.0) code on SuSe(Linux machine-i686-suse-linux, version 2.6.13-15.8-default), I am using journalLogFiles for the persistence. I am able to maintain the persistence by using the openwire-cpp API, but with a problem. In the case when the receiver is down and sender has sent messages. the restarted receiver does not get to receive the pending messages untill sender sends a new message. The receiver then receives all the pending message with this new message. What is going on? I am not getting this. Is this the openwire-cpp API fault Or I am doing something wrong(missing something). Thanks in advance Regards Arashad Ahamad
Message Filtering
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.
Re: Update to the wiki for the ActiveMQ CPP library
Great stuff Tim, keep up the good work :) On 7/7/06, Bish, Tim [EMAIL PROTECTED] wrote: Just a small note: I'm continuing to work on the C++ API, I've already done some refactoring on the CMS interfaces to make them more JMS like. Mostly that involved renaming some enumerations. So the next submittal will break anyone who is currently using them, but it's an easy fix. I've also done a bunch of code cleanup and expanded the Java DOC comments on many of the classes. Documentation is always a good thing. This weekend I intend to run the whole package through a code analyzer to check for leaks. Once I finish that I think we will be ready to submit a new drop for rev 0.0.2 just to so that we get the changes to the CMS interfaces in quickly After that I will move onto working on parsing params from the destinations names so we can support setting options from the destinations. Plus there's a lot of other good stuff to come. - Timothy A. Bish Sensis Corporation [EMAIL PROTECTED] - -Original Message- From: Mittler, Nathan [mailto:[EMAIL PROTECTED] Sent: Friday, July 07, 2006 9:12 AM To: activemq-dev@geronimo.apache.org Subject: RE: Update to the wiki for the ActiveMQ CPP library Thanks James! :) -Original Message- From: James Strachan [mailto:[EMAIL PROTECTED] Sent: Friday, July 07, 2006 2:00 AM To: activemq-dev@geronimo.apache.org Subject: Re: Update to the wiki for the ActiveMQ CPP library BTW the code looks great too :) On 7/7/06, James Strachan [EMAIL PROTECTED] wrote: On 7/6/06, Mittler, Nathan [EMAIL PROTECTED] wrote: FYI, I've added a page to the wiki for ActiveMQ CPP: http://www.activemq.org/site/activemq-cpp-client.html Also updated the Integration C++ link on the navigation pane to reference this page instead of CMS and I updated the C Integration page to add a link to this page as well. Great stuff Nate! Documentation rocks :) -- James --- http://radio.weblogs.com/0112098/ -- James --- http://radio.weblogs.com/0112098/ -- James --- http://radio.weblogs.com/0112098/
Re: [heads up] moved test cases from assembly to core...
Agreed. It'd be great to have tests of the generated assembly and more importantly - test that the examples actually work. On 7/7/06, Hiram Chirino [EMAIL PROTECTED] wrote: 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 -- James --- http://radio.weblogs.com/0112098/
Re: Thoughts on restructuring
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. P On 7/7/06, James Strachan [EMAIL PROTECTED] wrote: I agree with all of that; some refactoring of the build would be a good thing. Using a common version number is a good thing too. Just a thought; I wonder if we should split the tooling into 'maven tooling' which will often be a core dependency on component's builds - with other tooling (like eclipse tooling or servicemix-web or servicemix-console and so forth). Otherwise we might get circular dependencies. e.g. things like servicemix-web or portals and the like will probably be dependent on almost everything in the servicemix project - so we probably need some tooling stuff built last - not before the components. e.g. build order something like... * container * core tooling (mostly just maven plugins I think?) * components * other tooling like web applications, portal stuff, high end tools, eclipse tooling etc so maybe the order is: container, maven plugins, components, tools? On 7/7/06, Philip Dodds [EMAIL PROTECTED] wrote: I have been wondering about the possible restructuring of the ServiceMix code tree and build to enable cleaner separation, smaller/quicker builds, and the ability to separate out releases. The idea has been bounced around a bit on IRC and I wanted to put it out there for peoples thoughts. The basic idea is to break the current single build into three discreet projects, these would be : ServiceMix JBI Container ServiceMix Components ServiceMix Tooling The first would be purely the JBI Container with no Service Engines or Components and no tooling (it would also not require any ServiceMix tooling to build. Thus it would consist of the following projects: servicemix-core servicemix-jbi servicemix-services This would be packaged with the assembly to create a pure JBI server without any components. The second would be the JBI Maven 2 Tooling that is available, this would also include the archetypes that we are currently putting in place. These are all currently Maven2 plugins and have a dependency on the ServiceMix Core Container and therefore should be built second. It would consist of the following projects: jbi-maven-plugin servicemix-binding-component servicemix-http-consumer-service-unit servicemix-http-provider-service-unit servicemix-jms-consumer-service-unit servicemix-jms-provider-service-unit servicemix-jsr181-wsdl-first-service-unit servicemix-service-assembly servicemix-service-engine servicemix-service-unit servicemix-shared-library The final project would be the ServiceMix JBI Components/Shared Libraries which is dependent on both the Core and the Tooling, this would contain: servicemix-beanflow servicemix-bpe servicemix-components servicemix-common servicemix-eip servicemix-http servicemix-jms servicemix-jsr181 servicemix-lwcontainer servicemix-sca servicemix-soap servicemix-wsn2005 The projects that would be left that need consideration would be : servicemix-web servicemix-console Also I would like to bring up the idea of updating the Tooling versions so that they are in sync with the Core and Components (ie 3.0-incubating-SNAPSHOT). Currently we have a situation where we often hold both the ServiceMix version and the tooling version though I would think it would be easier to make them the same version. Philip -- James --- http://radio.weblogs.com/0112098/
[jira] Created: (SM-483) Code snippets missing from soem static HTML pages
Code snippets missing from soem static HTML pages -- Key: SM-483 URL: https://issues.apache.org/activemq/browse/SM-483 Project: ServiceMix Type: Bug Reporter: Bruce Snyder Assigned to: Hiram Chirino I've run across a couple of pages where code snippets are missing from the static HTML pages but are present in the wiki pages. I'm assuming that this is maybe due to some issue with the wiki -- html export plugin, but I'm no expert. Here are a couple pages where code snippets are missing: http://www.servicemix.org/site/saaj.html http://servicemix.org/site/pojo-support.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://issues.apache.org/activemq/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (GERONIMO-2161) [RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
[ http://issues.apache.org/jira/browse/GERONIMO-2161?page=all ]
Jason Dillon closed GERONIMO-2161:
--
Resolution: Fixed
Applied.
Thanks to everyone who helped.
[RTC] Remove Geronimo modules from dependencyManagement in root pom.xml
---
Key: GERONIMO-2161
URL: http://issues.apache.org/jira/browse/GERONIMO-2161
Project: Geronimo
Type: Task
Security: public(Regular issues)
Components: buildsystem
Reporter: Jason Dillon
Assignee: Jason Dillon
Fix For: 1.2
Attachments: GERONIMO-2161-configs-v1.1.sub.patch, GERONIMO-2161-v1.patch,
GERONIMO-2161-v2.patch, GERONIMO-2161-v3.patch, GERONIMO-2161-v4.patch,
GERONIMO-2161-v5.patch
As I have mentioned before, I believe we should remove the Geronimo modules
that are currently listed in the root pom.xml:
This reduces the configuration of the pom by *~500 lines*.
Modules that reference these as dependencies will need their pom's adjusted
to include version${pom.version}/version and typecar/type for the
configs. But in many places version already exists with the
${geronimoVersion} property... which kinda negates the purpose of the
dependencyManagement section anyways.
I believe that it is more work to keep track of every module in the root pom
than it is to specify the additonal elements (mostly just
version${pom.version}/version) in child poms. There is no additional
maintenance, as the new elements never need to be changed.
Net effect if this change is less configuration to maintain and thus a less
brittle build that can adapt to change easier.
Specifically these should be removed:
{code:xml}
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdge-activemq-rar/artifactId
version${geronimoVersion}/version
typerar/type
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-activation/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-client-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-common/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-connector-builder/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-converter/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-core/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-config/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-jsr88/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deploy-tool/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-deployment/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-derby/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-directory/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-javamail-transport/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-j2ee/artifactId
version${geronimoVersion}/version
/dependency
dependency
groupIdorg.apache.geronimo.modules/groupId
artifactIdgeronimo-j2ee-builder/artifactId
version${geronimoVersion}/version
/dependency
Re: FYI: Planning to upgrade to Derby 10.1.3 for the Geronimo 1.1.1 release (GERONIMO-2155)
Seems reasonable to me. This will also go into trunk? --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
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. --jason On Jul 6, 2006, at 4:54 PM, Jeff Genender wrote: Consider it blessed. ;-) Jason Dillon wrote: On Jul 6, 2006, at 4:23 PM, David Jencks 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. Commit it now. (non binding) I'd be more than happy to do so if someone from the PMC would bless that action. --jason
Re: [RTC] Vote on GERONIMO-2161 - restart 1
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 -- Jacek Laskowski http://www.laskowski.net.pl
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
[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/
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
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: 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
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: 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: 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
[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
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
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.
!-- unable to find a corresponding dependency in the new
groupdId:artifactId --
dependency
groupIddirectory-asn1/groupId
artifactIdasn1-codec/artifactId
version${asn1Version}/version
/dependency
dependency
groupIddirectory-asn1/groupId
artifactIdasn1-ber/artifactId
version${asn1Version}/version
/dependency
dependency
groupIddirectory-asn1/groupId
artifactIdasn1-der/artifactId
version${asn1Version}/version
/dependency
dependency
groupIddirectory-shared/groupId
artifactIdapache-ldapber-provider/artifactId
version${apachedsVersion}/version
/dependency
!-- mapped the following deps. Please verify ---
dependency
groupIdorg.apache.directory.server/groupId
artifactIdapacheds-core/artifactId
version${apachedsVersion}/version
/dependency
dependency
groupIdorg.apache.directory.server/groupId
!-- artifactIdapacheds-shared/artifactId --
artifactIdapacheds-core-shared/artifactId
version${apachedsVersion}/version
/dependency
dependency
groupIdorg.apache.directory.shared/groupId
!-- artifactIdldap-common/artifactId --
artifactIdshared-ldap/artifactId
version${apachedsVersion}/version
/dependency
dependency
groupIdorg.apache.directory.mina/groupId
!-- artifactIdmina/artifactId --
artifactIdmina-core/artifactId
version${minaVersion}/version
/dependency
dependency
groupIdorg.apache.directory.server/groupId
!-- artifactIdkerberos-common/artifactId --
artifactIdapacheds-kerberos-shared/artifactId
version${kerberosCommonVersion}/version
/dependency
dependency
groupIdorg.apache.directory.server/groupId
!-- artifactIdkerberos-protocol/artifactId --
artifactIdapacheds-protocol-kerberos/artifactId
version${kerberosProtocolVersion}/version
/dependency
dependency
groupIdorg.apache.directory.server/groupId
!-- artifactIdldap-protocol/artifactId --
artifactIdapacheds-protocol-ldap/artifactId
version${ldapProtocolVersion}/version
/dependency
[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
[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
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) dev@geronimo.apache.org 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
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: 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 (buildwtp-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 the server status as Starting.. as shown in attachment 3.GIF. And after a while, an Error message Timeout waiting for Apache Geronimo 1.1 to start. Server did not start after 24s. (as shown in attachment 4.GIF) gets thrown. The .log file in eclipse\workspace
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
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 startup complete - - - However the Servers view still shows the server status as Starting.. as shown in
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: 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: 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: [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: [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, 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
[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
[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
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
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
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: 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
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: 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: Help: Mapping to Apache Directory project's new groupId:artifactId
If we don't use the repository 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 repository for now. Moreover, I have learnt that using the
repository 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.
!-- unable to find a corresponding dependency in the new
groupdId:artifactId --
dependency
groupIddirectory-asn1/groupId
artifactIdasn1-codec/artifactId
version${asn1Version}/version
/dependency
dependency
groupIddirectory-asn1/groupId
artifactIdasn1-ber/artifactId
version${asn1Version}/version
/dependency
dependency
groupIddirectory-asn1/groupId
artifactIdasn1-der/artifactId
version${asn1Version}/version
/dependency
dependency
groupIddirectory-shared/groupId
artifactIdapache-ldapber-provider/artifactId
version${apachedsVersion}/version
/dependency
!-- mapped the following deps. Please verify ---
dependency
groupIdorg.apache.directory.server/groupId
artifactIdapacheds-core/artifactId
version${apachedsVersion}/version
/dependency
dependency
groupIdorg.apache.directory.server/groupId
!-- artifactIdapacheds-shared/artifactId --
artifactIdapacheds-core-shared/artifactId
version${apachedsVersion}/version
/dependency
dependency
groupIdorg.apache.directory.shared/groupId
!-- artifactIdldap-common/artifactId --
artifactIdshared-ldap/artifactId
version${apachedsVersion}/version
/dependency
dependency
groupIdorg.apache.directory.mina/groupId
!-- artifactIdmina/artifactId --
artifactIdmina-core/artifactId
version${minaVersion}/version
/dependency
dependency
groupIdorg.apache.directory.server/groupId
!-- artifactIdkerberos-common/artifactId --
artifactIdapacheds-kerberos-shared/artifactId
version${kerberosCommonVersion}/version
/dependency
dependency
groupIdorg.apache.directory.server/groupId
!-- artifactIdkerberos-protocol/artifactId --
artifactIdapacheds-protocol-kerberos/artifactId
version${kerberosProtocolVersion}/version
/dependency
dependency
groupIdorg.apache.directory.server/groupId
!-- artifactIdldap-protocol/artifactId --
artifactIdapacheds-protocol-ldap/artifactId
version${ldapProtocolVersion}/version
/dependency
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: 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: 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: [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: 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: 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: [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.
[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: 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
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?
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: 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
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.
[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-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] 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] 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
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] 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 message group 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 message group close message group and exit NOTE: The command close message group 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: [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
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
[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
[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] 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
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]
[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
[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] 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
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
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.
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
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
