Hi Ralph,
Ralph Goers wrote at Mittwoch, 22. April 2009 05:19:
[snip]
> Does it really matter that you understand what they are trying to do?
> What should matter is what they are trying to do doesn't work properly
> and they couldn't find a work around.
Did anyone of them ask here and try to e
I can't compile commons-math any longer due to the below errors. It seems
that some 1.6 methods have creaped in. I have no problem upgrading to 1.6
if that is what is necessary, but I thought 1.5 was the targeted version.
[javac] symbol : method newInstance(java.lang.Class,int,int)
[j
On Apr 21, 2009, at 6:20 PM, Jochen Wiedmann wrote:
One more note: Ceki is, of course, aware of that. Quoting
http://www.slf4j.org/manual.html
For example, the slf4j-log12-1.5.6.jar binding is bound at compile
time to use log4j. In your
code, in addition to slf4j-api-1.5.6.jar, you simply dr
On Apr 21, 2009, at 7:47 PM, John Bollinger wrote:
Ralph Goers wrote:
I saw your update on PLUTO-553. I suggest you read the JSR 286
Portlet spec. Portlets can access resources using the
PortletContext's getResource method. This corresponds to the
portlet War's servlet context. In additio
On Apr 21, 2009, at 7:08 PM, John Bollinger wrote:
Ralph Goers wrote:
It is hard to classify something a "bug" when it is working
"corectly". The portlet spec requires that a portal container be a
webapp and that it be able to deploy and control portlets in the
manner in which Pluto is
Ralph Goers wrote:
> I saw your update on PLUTO-553. I suggest you read the JSR 286 Portlet spec.
> Portlets can access resources using the PortletContext's getResource method.
> This corresponds to the portlet War's servlet context. In addition, portlets
> also have access to the PortalContext.
I notice that there is a LICENSE file located at
https://svn.apache.org/repos/asf/commons/proper/daemon/trunk/src/native/nt/procrun/LICENSE.
It includes the below content which I believe should be removed, as procrun
does not use any MD5 functions. This license is inherited from APR project.
The re
Ralph Goers wrote:
> It is hard to classify something a "bug" when it is working "corectly". The
> portlet spec requires that a portal container be a webapp and that it be able
> to deploy and control portlets in the manner in which Pluto is doing it. That
> could hardly be considered a bug.
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=189874&projectId=161
Build statistics:
State: Failed
Previous State: Ok
Started at: Tue 21 Apr 2009 18:31:19 -0700
Finished at: Tue 21 Apr 2009 18:32:34 -0700
Total time: 1m 14s
Build Trigger: Schedule
Build Nu
One more note: Ceki is, of course, aware of that. Quoting
http://www.slf4j.org/manual.html
For example, the slf4j-log12-1.5.6.jar binding is bound at compile
time to use log4j. In your
code, in addition to slf4j-api-1.5.6.jar, you simply drop one and
only one binding of your
choice onto the
On Wed, Apr 22, 2009 at 2:57 AM, Ralph Goers wrote:
> I'm not sure what you mean by "SLF4J bindings will start to be part of any
> major or minor component" and I think I've seen you make that comment
> before. Can you provide an example of how you think that will occur?
Easy. Suggest that you d
On Apr 21, 2009, at 5:39 PM, Jochen Wiedmann wrote:
The thing is that there is something like a "common" ClassLoader in
Pluto (and, most possibly, in all Portlet servers).
But that is nothing special: We know that from Tomcat as well. (Of
course, the common ClassLoader isn't endorsed by the
On Wed, Apr 22, 2009 at 12:03 AM, John Bollinger wrote:
> I confess that I don't understand the portal environment very well, but if
> I'm following this correctly then
> PLUTO-553 is a symptom of a more fundamental issue: objects in a Pluto
> portlet cannot rely on the
> context classloader to
On Apr 21, 2009, at 3:03 PM, John Bollinger wrote:
I confess that I don't understand the portal environment very well,
but if I'm following this correctly then PLUTO-553 is a symptom of a
more fundamental issue: objects in a Pluto portlet cannot rely on
the context classloader to be the co
On Apr 21, 2009, at 3:03 PM, John Bollinger wrote:
I confess that I don't understand the portal environment very well,
but if I'm following this correctly then PLUTO-553 is a symptom of a
more fundamental issue: objects in a Pluto portlet cannot rely on
the context classloader to be the co
I know you can do that but doing this simply ruins pluggeability or?
paul
Le 21-avr.-09 à 23:22, Dennis Lundberg a écrit :
Yes, it most certainly can. It seems to be a common misconception what
the logging implementation cannot be predictably configured. Just
put a
commons-logging.properti
this is the type of comments I had heard several times about commons-
logging... classloader issue...
I never understood them, what you describe is a probably hypothesis.
paul
Le 22-avr.-09 à 00:03, John Bollinger a écrit :
I confess that I don't understand the portal environment very well,
I confess that I don't understand the portal environment very well, but if I'm
following this correctly then PLUTO-553 is a symptom of a more fundamental
issue: objects in a Pluto portlet cannot rely on the context classloader to be
the correct one from which to obtain resources. This arises be
Yes, it most certainly can. It seems to be a common misconception what
the logging implementation cannot be predictably configured. Just put a
commons-logging.properties file in your class path with the following
line in it:
org.apache.commons.logging.Log=org.apache.commons.logging.impl.Log4JLogge
Ah, that's more clear.
But again, it cannot be predictable and pluggeable, or?
paul
Le 21-avr.-09 à 22:27, Dennis Lundberg a écrit :
Sorry, I wasn't being clear. I was not talking about configuring the
*level* of logging, but rather the logging implementation being used.
smime.p7s
Descript
Sorry, I wasn't being clear. I was not talking about configuring the
*level* of logging, but rather the logging implementation being used.
Paul Libbrecht wrote:
> allow me to chim in,
>
> does it make sense to expect *predictable results* ?
> What you should always configure is the default loggin
allow me to chim in,
does it make sense to expect *predictable results* ?
What you should always configure is the default logging, and that's
done, traditionally, by making the normal threshold either info or
error in the programme, maybe that could be enhanced ("preferred-
level" ?).
Full
On Apr 21, 2009, at 11:59 AM, Dennis Lundberg wrote:
I'm not that experienced in writing portlets or how the portlet
container works. Can you please try to explain in more detail what the
problem is.
Commons Logging works great in a servlet container like Tomcat. Every
webapp can have their
Ralph Goers wrote:
>
> On Apr 21, 2009, at 11:09 AM, Jochen Wiedmann wrote:
>
>> On Tue, Apr 21, 2009 at 5:01 PM, sebb wrote:
>>
>>> Well, the SLF4J website specifically says it is not necessary to
>>> recompile:
>>>
>>> http://www.slf4j.org/manual.html#swapping
>>>
>>> i.e. SLF4J chooses the lo
On Apr 21, 2009, at 11:09 AM, Jochen Wiedmann wrote:
On Tue, Apr 21, 2009 at 5:01 PM, sebb wrote:
Well, the SLF4J website specifically says it is not necessary to
recompile:
http://www.slf4j.org/manual.html#swapping
i.e. SLF4J chooses the logging implementation based in which logging
imp
On Tue, Apr 21, 2009 at 5:01 PM, sebb wrote:
> Well, the SLF4J website specifically says it is not necessary to recompile:
>
> http://www.slf4j.org/manual.html#swapping
>
> i.e. SLF4J chooses the logging implementation based in which logging
> implementation it finds on the classpath; there must
On 21/04/2009, Jochen Wiedmann wrote:
> On Tue, Apr 21, 2009 at 3:30 PM, Ralph Goers
> wrote:
>
> > They both allow the implementation
> > to be chosen when you package your application - without recompliling
> > anything.
>
>
> The last time we had that discussion, this has been denied. If t
On Tue, Apr 21, 2009 at 3:30 PM, Ralph Goers wrote:
> They both allow the implementation
> to be chosen when you package your application - without recompliling
> anything.
The last time we had that discussion, this has been denied. If there
is new information, I'd like to listen.
Jochen
--
On Apr 20, 2009, at 11:41 PM, Jörg Schaible wrote:
Ralph Goers wrote at Dienstag, 21. April 2009 01:03:
FWIW - I subscribe to this list so I saw the message but have not
participated in the discussion.
Actually it would be nice if people would report problems in first
place.
This just
- "Bill Barker" a écrit :
> Apologies for forgetting that I sent this from my personal email, that
> I
> hadn't subscribed from yet. I'm slowly moving my Apache subscriptions
> here
> from my corporate email, but since I was using gmane for this list,
> hadn't
> gotten there yet :(.
>
>
John Bollinger wrote:
The same approach could certainly be applied for DescriptiveStatistics, but the
variable window complicates things: if a finite window is selected for the
aggregate statistics then they will be sensitive to the order in which values
are added to the contributing per-parti
31 matches
Mail list logo
