Some background on prefetch...
http://incubator.apache.org/activemq/what-is-the-prefetch-limit-for.html
Is the Stomp client either accurately specifying auto-ack mode or
acknowledging the messages? Irrespective of the client used; if you
don't acknowledge the messages in the prefetch buffer, the
On Oct 19, 2006, at 11:19 PM, Jacek Laskowski wrote:
On 10/20/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Author: dain
Date: Thu Oct 19 15:44:24 2006
New Revision: 465917
...
+boolean containsEnv = false;
+for (Iterator iterator = map.entrySet().iterator();
iterator.ha
[
http://issues.apache.org/jira/browse/GERONIMO-2510?page=comments#action_12443759
]
Rick McGuire commented on GERONIMO-2510:
I believe his analysis is (mostly) correct. The specification for
javax.rmi.CORBA.Util.loadClass() has a fair
Dain Sundstrom wrote:
One problem I'm seeing in the tck has to do with the CORBA and RMI
delegates. When the java.rmi.Util class is loaded, it uses
Class.forName to load the UtilDelegate specified in a system
property. This is what yoko uses:
private static UtilDelegate delegate = null;
On my local image I added a new repo to the root pom.xml so that I could
pick up the Glassfish JSTL jar. What I discovered is that this resulted
in java.net getting placed before the apache repo in the search order
and therefore I'm picking up different jars (specs) from java.net (which
is b
You just need to put the standard repo in front of the new repo.
However, if there are conflicting jars, this is a real problem,
and it may be better to create a geronimo private repo, or
ask for jstl to be published on ibiblio (if released).
On 10/20/06, Joe Bohn <[EMAIL PROTECTED]> wrote:
On
I don't think the search order will solve your problem because the
different spec jars are being picked up as transitive dependencies. So
no matter what the search order, those aritfacts will be picked up
since they are listed explicitly as dependencies of your dependencies.
I believe you should
Guillaume Nodet wrote:
You just need to put the standard repo in front of the new repo.
However, if there are conflicting jars, this is a real problem,
and it may be better to create a geronimo private repo, or
ask for jstl to be published on ibiblio (if released).
Thanks for the response Gui
Thanks Prasad. I'm not yet sure if we are picking up *unnecessary jars*
(but it does look suspicious). It appears that we pick these up in our
current build. It's just a matter of where we get them from. I'd like
to first get things working by picking up just the jar that I need
(JSTL) fr
Hi All,In response to the following issue raised by David Jencks, I am thinking of changing the the implementation of Servlet and ServletStats (required by jsr77) for tomcat. The older implementation (GERONIMO-1035) will have 2 of each servlets! I am thinking of a ServletsHolder, which will be a co
I received a note from Carlos on the Maven team and it appears there
is an issue with a few artifacts that were released in 1.1 and
1.1.1. Here is the list of the poms in the Maven 1 repo.
'geronimo:geronimo-javamail-transport:jar:1.1.1'
- Missing 'siteDirectory': Both siteAddress and siteDi
Joe Bohn wrote:
Guillaume Nodet wrote:
You just need to put the standard repo in front of the new repo.
However, if there are conflicting jars, this is a real problem,
and it may be better to create a geronimo private repo, or
ask for jstl to be published on ibiblio (if released).
Thanks
Isn't the best way to just put the updated
files to the M1 repo at
http://people.apache.org/repo/m1-ibiblio-rsync-repository/
or send updated poms to Carlos ?
Personally, I'd prefer not having these poms at all
(speaking of all poms, not these in particular).
The dependencies are not good enough
[ http://issues.apache.org/jira/browse/DAYTRADER-14?page=all ]
Piyush Agarwal updated DAYTRADER-14:
Attachment: daytrader-14.patch.1019
Attaching the patch which will allow the creation of Daytrader database tables
from within Daytrader configuratio
The spec jars for G are picked up from o.a.g.specs groupId. The JSTL pom is a fake pom. Hence it should not download anything else. The best thing to do will be to move this jar to a different location (private repo?).thanksAnitaJoe Bohn <[EMAIL PROTECTED]> wrote:It appears that we pick these up i
Lightweight JmsReceiverComponent and servicemix-jms components gets
"javax.jms.IllegalStateException: Method setMessageListener not permitted
error" in WAS 6.1
-
The applications/console/console-standard has a dependency: javax.servlet jstl The pom for this at javax.servlet groupId is a real one. It is not necessary to download the other specs. You could try replacing this with : jstl
Hi All,
I included in the download page a link to the sample applications we have in
the cwiki, that is samples for each of the Geronimo releases.
The "Development" box on the left now also shows the "Geronimo JEE 5 Report
Card", a table showing our progress towards the JEE 5 implementation.
Ch
I posted earlier this week about a recent JUG I attended in Atlanta.
One of the comments I got was that our website didn't seem very
active. I stopped to take a look at it today trying to take the
perspective of a user or interested party and observed that our goals
are a bit dated. Here
Matt Hogstrom wrote:
> We are working on
> our next version of the server which is based on JEE 1.5. Some of our
Use "Java EE5" please. JEE 1.5 is a no-no.
Jeff
I can update them but that would mean they are no longer 1.1.1 but
should probably be 1.1.2. That is more a philosophical discussion.
I'm happy to update them but wasn't sure of the ramifications as we
would then have two different versions of the poms. I'm happy to
make them go away alth
Thanks...I now officially dub thee Jeff Magnusson Jr. :)
On Oct 20, 2006, at 3:45 PM, Jeff Genender wrote:
Matt Hogstrom wrote:
We are working on
our next version of the server which is based on JEE 1.5. Some of
our
Use "Java EE5" please. JEE 1.5 is a no-no.
Jeff
Matt Hogstrom
[EMAI
Matt Hogstrom wrote:
> Thanks...I now officially dub thee Jeff Magnusson Jr. :)
I don't mean to be a stickler...but when I used that term (JEE5) on the
spec commitee, I really got lashed, so I try to be politically correct ;-)
>
> On Oct 20, 2006, at 3:45 PM, Jeff Genender wrote:
>
>>
>>
>>
anita kulshreshtha wrote:
The applications/console/console-standard has a dependency:
javax.servlet
jstl
The pom for this at javax.servlet groupId is a real one. It is not
necessary to download the other specs. You could try replacing this with :
Matt Hogstrom wrote:
*** New swill ***
Welcome to the Apache Geronimo Project!
Our goal is to produce a server runtime framework that pulls together
the best Open Source alternatives to create runtimes that meet the
needs of developers and system administrators. Our most prominent
runti
Joe Bohn wrote:
> I agree with Jeff that we should use JEE 5.
No...*Java* EE5 ;-)
On 10/20/06, Matt Hogstrom <[EMAIL PROTECTED]> wrote:
I can update them but that would mean they are no longer 1.1.1 but
should probably be 1.1.2. That is more a philosophical discussion.
I'm happy to update them but wasn't sure of the ramifications as we
would then have two different versions o
Matt Hogstrom wrote:
*** New swill ***
Welcome to the Apache Geronimo Project!
Our goal is to produce a server runtime framework that pulls together
the best Open Source alternatives to create runtimes that meet the needs
of developers and system administrators. Our most prominent runtime i
On Oct 20, 2006, at 3:55 PM, Jeff Genender wrote:
I don't mean to be a stickler...but when I used that term (JEE5) on
the
spec commitee, I really got lashed, so I try to be politically
correct ;-)
Couldn't help myself...I'll make the update as we want to be good
citizens.
Matt Hogst
[
https://issues.apache.org/activemq/browse/AMQ-876?page=comments#action_37256 ]
Vadim Pesochinskiy commented on AMQ-876:
Hi Rob,
Yes looks like you got it. Thanks a lot.
> Kaha DB cannot locate queue data files
> --
Hi,
I am working on removing a dependence on sun.misc.UUEncoder
from the ant code base, and would like to "borrow" the method
UUEncoder.encodeLine(), so that we can roll our own UUEncoder.
Peter
[
https://issues.apache.org/activemq/browse/AMQ-861?page=comments#action_37257 ]
Vadim Pesochinskiy commented on AMQ-861:
this seems to work now, i.e. files are removed
> Kaha DB files are not removed
> -
>
>
WEB-INF/Classes is not visible during deployment
Key: GERONIMO-2511
URL: http://issues.apache.org/jira/browse/GERONIMO-2511
Project: Geronimo
Issue Type: Bug
Security Level: public (Regu
[ http://issues.apache.org/jira/browse/GERONIMO-2511?page=all ]
Dain Sundstrom closed GERONIMO-2511.
Resolution: Fixed
Changed the copy loop to keep a collection of libraries. Then moved the back
the code that installed the WEB-INF/classes to below
gcache client api's
---
Key: GERONIMO-2512
URL: http://issues.apache.org/jira/browse/GERONIMO-2512
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Reporter: Bill Dudney
apply from
[
http://issues.apache.org/jira/browse/GERONIMO-2503?page=comments#action_12443984
]
Dain Sundstrom commented on GERONIMO-2503:
--
This fix broke deployment of any war file that kept the Servlet implementation
classes in WEB-INF/classes.
Do you mean "borrow" from Geronimo? If so...go for it...ahh the
wonderful part of the Apache License allows you to do just that ;-)
Peter Reilly wrote:
> Hi,
> I am working on removing a dependence on sun.misc.UUEncoder
> from the ant code base, and would like to "borrow" the method
> UUEncoder.e
Bite me
Matt Hogstrom wrote:
Thanks...I now officially dub thee Jeff Magnusson Jr. :)
On Oct 20, 2006, at 3:45 PM, Jeff Genender wrote:
Matt Hogstrom wrote:
We are working on
our next version of the server which is based on JEE 1.5. Some of our
Use "Java EE5" please. JEE 1.5 is a no-no.
(he's right...)
Jeff Genender wrote:
Matt Hogstrom wrote:
Thanks...I now officially dub thee Jeff Magnusson Jr. :)
I don't mean to be a stickler...but when I used that term (JEE5) on the
spec commitee, I really got lashed, so I try to be politically correct ;-)
On Oct 20, 2006, at 3:45 PM
39 matches
Mail list logo
