[
https://issues.apache.org/activemq/browse/AMQ-768?page=comments#action_36454 ]
christy c commented on AMQ-768:
---
We're seeing a similiar problem, and wanted to see if this is the same issue.
We have two web apps in Tomcat 2.2.9 that use JMS connections
consumer.dispatchAsync defaults to false
Key: AMQ-770
URL: https://issues.apache.org/activemq/browse/AMQ-770
Project: ActiveMQ
Type: Bug
Components: JMS client
Versions: 4.0, 4.0.1
Reporter: Kevin Yaussy
I liked Hiram's blog today
http://hiramchirino.com/2006/06/amqp-interesting-start.html
it looks way too early to be able to implement this specification in a
JMS provider yet as there's no standard way to map JMS semantics to
AMQP yet - which would prevent JMS providers from interoperating
org.apache.activemq.broker.TransportConnection::stop should not attempt to send
a message over the connection.
--
Key: AMQ-771
URL:
[ https://issues.apache.org/activemq/browse/AMQ-608?page=all ]
Kevin Yaussy reopened AMQ-608:
--
Hiram,
Very sorry that I did not look at the 4.0.1 source until the last couple days.
I'd like to submit patches this time (I don't have svn, but I will
[ https://issues.apache.org/activemq/browse/AMQ-608?page=all ]
Kevin Yaussy updated AMQ-608:
-
Attachment: DemandForwardingBridgeSupport.patch
FailoverTransport.patch
InactivityMonitor.patch
Hope this is the way to attach the
[ https://issues.apache.org/activemq/browse/AMQ-608?page=all ]
Kevin Yaussy updated AMQ-608:
-
Attachment: InactivityMonitor.patch2
Change logging level of some DemandForwardingBridge log messages.
Build ships without activemq-web-4.0.jar
Key: AMQ-772
URL: https://issues.apache.org/activemq/browse/AMQ-772
Project: ActiveMQ
Type: Bug
Reporter: Matt Parker
Build ships without activemq-web-4.0.jar, so WAR generated
Build ships without incompatitable commons-logging and log4j
Key: AMQ-773
URL: https://issues.apache.org/activemq/browse/AMQ-773
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0.1
Can't deploy RAR on weblogic 9.1
Key: AMQ-774
URL: https://issues.apache.org/activemq/browse/AMQ-774
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0.1
Environment: BEA Weblogic 9.1
Reporter: Matt Parker
I don't quite understand what you are asking. Can you rephrase?
Regards,
Alan
Jason Dillon wrote:
Does this mean that the bulk of changes will be done on M.m branches
and only release + minor changes done on M.m.r branches?
--jason
On Jun 21, 2006, at 6:52 PM, David Blevins wrote:
We
When you use the maven release plugin, maven change the scm urlto point to the tag. I will revert it to trunk asap.Cheers,Guillaume NodetOn 6/22/06,
David Blevins [EMAIL PROTECTED] wrote:
On Jun 21, 2006, at 6:37 PM, Alan D. Cabrera wrote: IIUC, version specific informationhas snuck into elements
[ https://issues.apache.org/activemq/browse/SM-468?page=all ]
Guillaume Nodet resolved SM-468:
Fix Version: 3.0
Resolution: Fixed
Assign To: Guillaume Nodet
Author: gnodet
Date: Wed Jun 21 23:35:16 2006
New Revision: 416269
URL:
Ahh, ok. What about the other elements?
Regards,
Alan
Guillaume Nodet wrote:
When you use the maven release plugin, maven change the
scm url
to point to the tag. I will revert it to trunk asap.
Cheers,
Guillaume Nodet
On 6/22/06,
David Blevins [EMAIL PROTECTED]
wrote:
On Jun 21,
On Jun 21, 2006, at 10:53 PM, Alan D. Cabrera wrote:
David Blevins wrote:
The only thing done in a branches/x.y.z made from branches/x.y is
the release process itself.
I don't quite understand what this means. Sorry.
Referring to things like switching the version numbers, etc. The
The distribution repos ?Well, i wanted to publish the release in a private repo so that it can be voted,and then move to public repos.I will change them back to what they were.Cheers,Guillaume Nodet
On 6/22/06, Alan D. Cabrera [EMAIL PROTECTED] wrote:
Ahh, ok. What about the other
Okay, then +1
--jason
On Jun 21, 2006, at 10:19 PM, David Blevins wrote:
The only thing done in a branches/x.y.z made from branches/x.y is
the release process itself. When we agree we look good enough to
cut and run, we freeze, make the branch and put together a release
candidate. At
On 6/21/06, Jeff Genender [EMAIL PROTECTED] wrote:
Personal preference...but I think its better throwing an error. Is
obsoleting a settable option? I am not so sure I like obsoleting by
default...this could be ugly since it may be another app other than the
Welcome app that gets obsoleted.
+1 To Jason's comments with Hiram's comments...
I think we should do all development of 1.1.x in branches/1.1 (with
version 1.1.N-SNAPSHOT). But at the time we code freeze for a
release, I think we should svn copy branches/1.1 to branches/1.1.N and
finalize the version numbers there (to version
Guillaume,
The M2 binary doesn't have the optional libraries, is this intentional or a
build issue
thanks
Soumadeep
- Original Message -
From: Guillaume Nodet [EMAIL PROTECTED]
To: servicemix-users@geronimo.apache.org;
servicemix-dev@geronimo.apache.org
Sent: Tuesday, June 20, 2006
+1, but if we cut a release from the frozen branch, we need to note
the SVN version number or something so when we move it to tags we're
absolutely sure we didn't catch an extra commit in the tag. I'm also
fine with copying to tags, making the candidate from tags, and then
recreating the tag if
+1 (and we need to make sure this is added to the wiki so we can
remember it the next time a release is spun :-))
David Blevins wrote:
We had this whole conversation last week, lots of good discussion was
had. I'd prefer not to have to have it again. Here is my exact
understanding of our
+1 from me.
thanks
david jencks
--- Prasad Kashyap [EMAIL PROTECTED]
wrote:
I did a sniff test of the installed product and I
think we are good to go.
+1 from me.
I shall grill it some more tomorrow.
Cheers
Prasad
On 6/19/06, Hernan Cunico [EMAIL PROTECTED] wrote:
John
I replied on the other thread :) basically ActiveCluster
On 6/21/06, Komandur [EMAIL PROTECTED] wrote:
Hi,
Is any group membership protocol implemented as part of ActiveMQ ?
(I have seen references to ActiveCluster, and would like to know if AMQ
uses it for any of the configurations).
This patch addresses my major concerns. I consider it
a bug fix and thus not requiring further voting beyond
my previous +1, but in case anyone disagrees, I've
applied it and tested it to the best of my abilities
and vote +1.
thanks
david jencks
--- Gianny Damour (JIRA) dev@geronimo.apache.org
I think moving from branches to tags and back again is too disruptive. The reason it sits in its
own area in branches is so that it can be finalized and then copied once its done. If we have to
then we have to but this should be the rare exception that something is caught after the final vote
Thanks David, I tried to recap in the other thread and didn't receive any additional responses so
now that we have a branches/1.1.0 branches/1.1 and a branches/1.1.1 I don't think we quite nailed
it. Your summary is great and I concur.
Here is my + 1 and I'm happy to get the Wiki updated.
David Blevins wrote:
On Jun 21, 2006, at 10:53 PM, Alan D. Cabrera wrote:
David Blevins wrote:
The only thing done in a branches/x.y.z made from branches/x.y is
the release process itself.
I don't quite understand what this means. Sorry.
Referring to things like switching the version
+1 to David's recap and to Matts plans below.
John
Matt Hogstrom wrote:
Thanks David, I tried to recap in the other thread and didn't receive
any additional responses so now that we have a branches/1.1.0
branches/1.1 and a branches/1.1.1 I don't think we quite nailed it.
Your summary is
+1
Gianny
David Blevins wrote:
We had this whole conversation last week, lots of good discussion was
had. I'd prefer not to have to have it again. Here is my exact
understanding of our consensus and would like to put it to a vote to
avoid reinterpretation of that consensus in the future.
javamail providers component referencing non-released version of activation
specs.
--
Key: GERONIMO-2141
URL: http://issues.apache.org/jira/browse/GERONIMO-2141
Project: Geronimo
Type:
[ http://issues.apache.org/jira/browse/GERONIMO-2141?page=all ]
Rick McGuire resolved GERONIMO-2141:
Resolution: Fixed
Committed revision 416340.
Also fixed a copyright problem with a couple of the pom.xml files.
javamail providers
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-83?page=all ]
Sachin Patel resolved GERONIMODEVTOOLS-83:
--
Resolution: Cannot Reproduce
Actually I've seen random compile errors like this once in a blue moon. I
think this is some
+1 to david and alan's annotations.
Lets get it in the wiki!
thanks
david jencks
On Jun 22, 2006, at 4:06 AM, Alan D. Cabrera wrote:
+1
I think that we should mention that patches that go into
x.y.z also go into x.y and trunk
x.y also go into trunk
Last time we neglected to apply patches
EJB Refs to EJB in parent module often fail
---
Key: GERONIMO-2142
URL: http://issues.apache.org/jira/browse/GERONIMO-2142
Project: Geronimo
Type: Bug
Security: public (Regular issues)
Components: deployment, OpenEJB
Aaron Mulder wrote:
On 6/21/06, Jeff Genender [EMAIL PROTECTED] wrote:
Personal preference...but I think its better throwing an error. Is
obsoleting a settable option? I am not so sure I like obsoleting by
default...this could be ugly since it may be another app other than the
Welcome app
Thanks Matt this helps a lot. Sounds like
DirectoryInitializationGBean can get the job done, mainly due to the
fact that creating a database in derby is as easy as copying a
directory into var/derby. I'll look into this approach for the
initial rev of the liferay database pool plugin and think
On 6/22/06, Aaron Mulder [EMAIL PROTECTED] wrote:
+1 To Jason's comments with Hiram's comments...
I think we should do all development of 1.1.x in branches/1.1 (with
version 1.1.N-SNAPSHOT). But at the time we code freeze for a
release, I think we should svn copy branches/1.1 to branches/1.1.N
On 6/22/06, Matt Hogstrom [EMAIL PROTECTED] wrote:
Thanks David, I tried to recap in the other thread and didn't receive any
additional responses so
now that we have a branches/1.1.0 branches/1.1 and a branches/1.1.1 I don't
think we quite nailed
it. Your summary is great and I concur.
Here
I played around with j2ee-tomcat-server and came away with a good
first impression. I liked the 'usage' link on Database Pools and
Security Realms page. Here is my +1.
Thanks
Anita
P.S. - The copyright notice on console--welcome says :
Copyright © 1999-2005 Apache Software Foundation
All
Thanks for the suggestions Aaron. Comments inline.
On 6/21/06, Aaron Mulder [EMAIL PROTECTED] wrote:
There are two options you should be aware of for a plugin.
One is that you can declare a database pool dependency named
LiferayDatabase or whatever. Then provide a Derby database pool
plugin
+1
On 6/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
Here is my +1
Cheers,
Guillaume Nodet
On 6/20/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
I have uploaded binaries for the 3.0-M2-incubating release.
The repos and site are available at
I have just launched a deployment of a new version which fixes a few bugs.
Will start a new vote in a few hours.
Cheers,
Guillaume Nodet
On 6/22/06, James Strachan [EMAIL PROTECTED] wrote:
+1
On 6/21/06, Guillaume Nodet [EMAIL PROTECTED] wrote:
Here is my +1
Cheers,
Guillaume Nodet
On
Thanks for the helpful feedback Jeff. Comments inline.
On 6/21/06, Jeff Genender [EMAIL PROTECTED] wrote:
Paul McMahan wrote:
Liferay is an open source portal made available under the MIT license.
They provide a geronimo+liferay distribution from their website,
which is basically a zipped
ENCConfigBuilder blocks outside callers
---
Key: GERONIMO-2143
URL: http://issues.apache.org/jira/browse/GERONIMO-2143
Project: Geronimo
Type: Bug
Security: public (Regular issues)
Components: deployment, naming
GBean for handling initial database population
--
Key: GERONIMO-2144
URL: http://issues.apache.org/jira/browse/GERONIMO-2144
Project: Geronimo
Type: New Feature
Security: public (Regular issues)
Components:
On Jun 22, 2006, at 2:01 AM, Rick McGuire wrote:
+1 (and we need to make sure this is added to the wiki so we can
remember it the next time a release is spun :-))
Definitely, was waiting to see some +1s before doing that part.
Here it is:
Can you update the release procedure page?
http://geronimo.apache.org/xbean/release-procedure.html
-dain
On Jun 22, 2006, at 12:05 AM, Guillaume Nodet wrote:
The distribution repos ?
Well, i wanted to publish the release in a private repo so that it
can be voted,
and then move to public
I was not swayed by the arguments against letting people deploy Quartz
jobs as GBeans. However, I agree that it's not appropriate for every
case. When I document this plugin, I plan to list the use cases I'm
going for and the ones I'm not.
After a little experimentation, I've been able to
NPE in Maven1Repository
---
Key: GERONIMO-2145
URL: http://issues.apache.org/jira/browse/GERONIMO-2145
Project: Geronimo
Type: Bug
Security: public (Regular issues)
Components: kernel
Versions: 1.1
Reporter: Aaron Mulder
GBeanOverride ignores reference name when saving if artifact is not set
---
Key: GERONIMO-2146
URL: http://issues.apache.org/jira/browse/GERONIMO-2146
Project: Geronimo
Type: Bug
Security:
Aaron Mulder wrote:
I was not swayed by the arguments against letting people deploy Quartz
jobs as GBeans. However, I agree that it's not appropriate for every
case. When I document this plugin, I plan to list the use cases I'm
going for and the ones I'm not.
I don't think people had
[
http://issues.apache.org/jira/browse/GERONIMO-2116?page=comments#action_12417335
]
David Jencks commented on GERONIMO-2116:
The error I got before rebuilding the plugins was:
Embedded error: The -uriroot option must specify a pre-existing
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:
Then I think we're open for G-Business.
I love it... G-Business :-)
--jason
[ http://issues.apache.org/jira/browse/GERONIMO-2147?page=all ]
Rick McGuire updated GERONIMO-2147:
---
Attachment: notrans.diff
Changes to the config for removing the javamail-transport dependencies. Also
deletes the javamail-transport module.
Ok, on to the next phase of the javamail reorganization. This patch
http://issues.apache.org/jira/browse/GERONIMO-2147
is to remove the javamail-transport module and replace it with
references to the javamail-providers-1.3.1 jar file.
Rick
On Jun 22, 2006, at 3:17 AM, Matt Hogstrom wrote:
The remaining question is what to do with the branches that are out
there. I think we should whack what's out there (does not appear
that there has been any activity) branches/1.1 and branches/1.1.1.
When the vote is complete later today
Okay, here ya go:
http://cwiki.apache.org/confluence/display/GMOxKB
I did a few things...
First, I setup a geronimo team label, and labeled all of our spaces
(so from the dashboard you can see all of the G-related spaces
easily). New spaces for G should also get this label added (have
Autoexport is up:
http://cwiki.apache.org/GMOxKB/index.html
--jason
On Jun 22, 2006, at 12:17 PM, Jason Dillon wrote:
Okay, here ya go:
http://cwiki.apache.org/confluence/display/GMOxKB
I did a few things...
First, I setup a geronimo team label, and labeled all of our spaces
Hi Jason,
what is the long term plan for this space? could we ultimately move/merge the MoinMoin content there
once migrated?
There is this GMOxSBOX space (the SandBox) that we could remove and put the GMOxKB instead, see
cwiki.apache.org/geronimo
Let me know what you think?
Cheers!
Hernan
I think that the bulk of what is in http://wiki.apache.org/geronimo/
should move to http://cwiki.apache.org/geronimo/
I think that the KB space is really for stuff that does not fit well
into other spaces (like docNN or geronimo), or stuff that is FAQ-like.
It looks like the moin content
Jason Dillon wrote:
I think that the bulk of what is in http://wiki.apache.org/geronimo/
should move to http://cwiki.apache.org/geronimo/
I think that the KB space is really for stuff that does not fit well
into other spaces (like docNN or geronimo), or stuff that is FAQ-like.
That was
On Jun 22, 2006, at 1:23 PM, Jason Dillon wrote:
I also think that we could probably merge GMOxPMGT into the
geronimo space, but that is just a thought.
+1
-David
IMO, the important thing is to get the content into Confluence and
out of moin. Maybe start by adding them to the sandbox
I think that the bulk of what is in http://wiki.apache.org/
geronimo/ should move to http://cwiki.apache.org/geronimo/
I think that the KB space is really for stuff that does not fit
well into other spaces (like docNN or geronimo), or stuff that is
FAQ-like.
That was the original idea
This is awesome! I think this framework can really let us quickly
and easily grow the content.
On Jun 22, 2006, at 2:38 PM, Jason Dillon wrote:
I think that the bulk of what is in http://wiki.apache.org/
geronimo/ should move to http://cwiki.apache.org/geronimo/
I think that the KB space
[ https://issues.apache.org/activemq/browse/AMQ-528?page=all ]
will gunadi reopened AMQ-528:
-
Using:
-
backport-util-concurrent-2.1.jar
activemq-core-4.0.jar
activemq-ra-4.0.jar
jencks-all-1.1.3.jar
broker.xml:
---
?xml version=1.0
MessageAuthorizationPolicy doesn't work
---
Key: AMQ-775
URL: https://issues.apache.org/activemq/browse/AMQ-775
Project: ActiveMQ
Type: Bug
Components: Broker
Versions: 4.0
Environment: windows NT 2003 server
Update: injection of GBean references into the job works too. So it's
only EJB references that are problematic for these purposes in 1.1.
Thanks,
Aaron
On 6/22/06, Aaron Mulder [EMAIL PROTECTED] wrote:
I was not swayed by the arguments against letting people deploy Quartz
jobs as GBeans.
Being one of the dissenters I think your approach is fine. Please take into consideration that
there may be competing implementations so the name hopefully will provide a clue as to what the
plugin does.
Thanks for the heads up.
Cheers
Matt
Aaron Mulder wrote:
I was not swayed by the
Subject says it all. All projects moved over except XBean because
its root pom.xml has an incorrect scm url.
-David
[ http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-83?page=all ]
Donald Woods reopened GERONIMODEVTOOLS-83:
--
Tried building it at least 6 times tonight without any luck.
Tried building a clean checkout at least 3 times in a row.
Tried
Stack Traces upon Publishing Errors are difficult to read
-
Key: GERONIMODEVTOOLS-86
URL: http://issues.apache.org/jira/browse/GERONIMODEVTOOLS-86
Project: Geronimo-Devtools
Type: Improvement
Components:
Cool Jason. I like it. Can we please have to/fro links from the
http://cwiki.apache.org/geronimo site to the KB.
Thanx
Prasad
On 6/22/06, Jason Dillon [EMAIL PROTECTED] wrote:
Autoexport is up:
http://cwiki.apache.org/GMOxKB/index.html
--jason
On Jun 22, 2006, at 12:17 PM, Jason
Done.
--jason
On Jun 22, 2006, at 9:01 PM, Prasad Kashyap wrote:
Cool Jason. I like it. Can we please have to/fro links from the
http://cwiki.apache.org/geronimo site to the KB.
Thanx
Prasad
On 6/22/06, Jason Dillon [EMAIL PROTECTED] wrote:
Autoexport is up:
[
http://issues.apache.org/jira/browse/GERONIMO-2116?page=comments#action_12417408
]
Prasad Kashyap commented on GERONIMO-2116:
--
DJ, I didn't think you had to rebuild the jspc plugin. Jeff has applied my
patches to that plugin and had also
76 matches
Mail list logo
