I'm looking at commons-math for the first time, but I don't think the feature
can be implemented as requested in a manner that is suitably generic. On the
other hand, I think the same objective could be achieved a different way
without changing the base API at all. The key would be to generate
the sub-sample is reasonably large, I can sometimes estimate a few
> parameters such as total uniques. The sub-sampled data streams can be
> combined trivially so I now have a aggregatable approximation of
> non-aggregatable statistics. For descriptive quantiles this is generally
> jus
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
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.
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.
Ralph Goers wrote:
>I'm still at a loss as to how this conversation has devolved to this. This
>post was meant as an example as to why yet another project is switching away
>from Commons Logging.
You are right. I apologize for taking the discussion so far afield.
Ralph Goers wrote:
> What is next for Commons Logging? Is there any point in enhancing it to
> emulate SLF4J? Should it just stay more or less as it is while it slowly
> loses its customer base?
I think the most appropriate use case for Commons Logging always has been for
small components inten
Mark Thomas wrote:
> Ate Douma wrote:
> > When Pluto needs to "aggregate" the content of this TestPortlet, it
> > invokes it render(PortletRequest, PortletResponse) method using a
> > "cross-context" call from the Pluto web application to the "test" web
> > application.
> > The TestPortlet.render
Mark Thomas wrote:
> John Bollinger wrote:
>> See attached sample code for a class that would support this behavior.
>
> Your attachment didn't make it through. Could you post it in-line?
Sure:
/*
* Licensed to the Apache Software Foundation (ASF) under one or more
*
Ted Dunning wrote:
> My view is that once it is immutable it is immutable. Restoring mutability
> is done by making a new copy [...].
That position is stronger than you make it sound. Changing a supposedly
immutable object so that it is mutable would itself be a mutation. If it were
possible th
Ted Dunning wrote:
> On Fri, Apr 24, 2009 at 11:50 AM, John Bollinger wrote:
>
> > Ted Dunning wrote:
> > > My view is that once it is immutable it is immutable. Restoring
> > mutability
> > > is done by making a new copy [...].
> >
> > That positi
sebb wrote:
> OK, that makes sense.
>
> However, only objects that are immutable from construction are
> thread-safe without needing some kind of synchronisation.
>
> Passing it to a newly created thread would be OK (Thread.start() is
> synch.), but if it is passed to an existing thread some other
Hi Ate,
I'm glad your switch to SLF4J is doing what you need it to do, and I am in no
way trying to persuade you to change course there. I do think, however, that
the problem of classes loading required resources via the wrong ClassLoader
could easily manifest in webapp / portlet components ot
Jörg Schaible wrote:
> Maybe it's also time to think about more fine grained artifacts. With Maven
> the dependency management is no longer that worse. We could have
>
> collections-x.y.jar
> collections-functor-x.y.jar
>
> with the latter providing the stuff of collections depending on funct
James Carman wrote:
>On Mon, May 11, 2009 at 7:35 AM, Jörg Schaible wrote:
>> James Carman wrote at Montag, 11. Mai 2009 13:17:
>>
>>> On Mon, May 11, 2009 at 3:01 AM, Jörg Schaible
>>> wrote:
I think there is a basic agreement on this, but back now to functor. In
this case it means m
Stephen Colebourne wrote:
> The 'functors' in [collections] and [functor] are very different:
Thanks for clearing that up. It obviously moots my argument as it applies
to Collections / Functor, though I think the distinction between private
dependencies and public ones is still generally releva
ppier, but your code wouldn't be much safer (vs. only
implementations being serializable). These are warnings that you want to have,
or it least that you want to explicitly suppress.
John Bollinger
From: Ted Dunning
To: Commons Developers List
Sent: T
sure that's a
relevant concern in this case.
John
--
John Bollinger
thinma...@yahoo.com
Emmanuel Bourg wrote:
> In Commons CLI there are 3 parsers implementing the same interface, and soon
> another implementation will be added. There is an abstract test case with the
> test methods, and a concrete subclass for each parser. The concrete test case
> instantiates the parser and d
t (mis)use XML in a way that would be
broken if character references to characters outside the XML character set were
flagged as application errors; it would be considerate for StringEscapeUtils to
be compatible with such (mis)use.
Best Regards,
John
--
John Bollinger
thinma...@yahoo.com
have
completed on this, but as I said, I won't be available to start on that for
about
a month.
John
--
John Bollinger
thinma...@yahoo.com
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additi
21 matches
Mail list logo
