On 03/11/06, Vincent <[EMAIL PROTECTED]> wrote:
I agree the jdk logger is powerful, but so is log4j.
One perspective.
jdk logger has an XML output. Setting the append to true
such that each application run appends logging output to the
prior log, produces invalid XML, with multiple XML declara
Hi Vincent,
The principle of Restlet Extensions has been kept for FreeMarker, JSON and
Atom. However, the packages in this JAR have been merged into
org.restlet.jar. The NRE implementation had many irremovable dependencies to
it, creating a dependency cycle. I've done some refactoring to have thi
Honestly there are many ways you could solve this ... I would create
/accounts/search/less_than/1
/accounts/search/greater_than/1
/accounts/search/between/1/2
And then you could either have a generalised Serach restlet ... or you
could have restlets handling each search case indiv
My 2 cents: there was a JSR, 47 I think, apache was the only one who
voted No in the final ballot .. sometimes being more flexible isn't
good.. I'd vote for sticking with what comes with the JDK.. it reduces
the version-clashes (classloader issues) that I have seen so often
creep up when you try a
Hi all,
Log4j has been around for more time and has more features available:
http://wiki.apache.org/logging-log4j/Log4jvsJDKLogging. But the core logging
APIs are very similar and, as Piyush said, using log4j brings in new issues.
IMHO, we should try to extend the JDK's logger instead of replacin
Hi all,
Log4j has been around for more time and has more features available:
http://wiki.apache.org/logging-log4j/Log4jvsJDKLogging. But the core logging
APIs are very similar and, as Piyush said, using log4j brings in new issues.
IMHO, we should try to extend the JDK's logger instead of replacin
Dave your bug got me very curious ...
Found this
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4629315
Sadly.. it was reported way back in 2002 and it is still in
progress... !!! You could vote for this bug to be removed.. I just
hope it hasn't got lost a bit in all the other bugs .. so jus
There is an interesting evaluation note at the end:
"This bug can be fixed in Mustang update. Priority of this bug must be
increased because it has been selected
as "Five for fixing in August 2006"."
So there is hope, I've just voted for it :)
Best regards,
Jerome
> -Message d'origine-
On 03/11/06, Piyush Purang <[EMAIL PROTECTED]> wrote:
Dave your bug got me very curious ...
Found this
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4629315
Sadly.. it was reported way back in 2002 and it is still in
progress... !!! You could vote for this bug to be removed.. I just
hope i
Yeah! and that was a comment written in 2002 (If I can deduce that
correctly) .. that is some very specific planning.. divide and conquer
monthly :) But eh! august is long gone.. I would love to know what
were the other 5 and what happened to them?
I'm not going to argue for one over the other. Where I work we use log4j
exclusively and I never had the time to get the lowdown other than that log4j
supported a richer set of appenders and apparently made it easier to write your
own. When this thread started, I decided to do a search and I found
Hi Piyush,
> /accounts/search/less_than/1
> /accounts/search/greater_than/1
> /accounts/search/between/1/2
The issue I have with this approach is that it doesn't allow to mix several
search criteria (balance_less_than=2000&status=active).
I'd like to have:
1) /accounts/1234 ->
Hi Vincent,
Vincent yahoo.ca> writes:
>
> Hi Piyush,
>
> > /accounts/search/less_than/1
> > /accounts/search/greater_than/1
> > /accounts/search/between/1/2
>
> The issue I have with this approach is that it doesn't allow to mix several
> search criteria (balance_less_than=200
Sean,
> We had a similar issue and I think this is an area where the REST philosophy
> is somewhat stressed.
< [..]
> We decided to make a web service, use a POST and put the criteria in the
> XML. Then the URI could be /accounts/search which is pretty easy to
> deal with.
I'm not sure it stretc
Jerome,
> Agreed, let's reuse the safer "getValue() : String" method introduced in
> StringRepresentation and deprecate toString().
Thanks for making the change.
Why not go one steo further and have getValue cache the value?
private boolean cached = false;
private value = null;
publi
Is it an immutable that the getValue returns the same value for the
entire lifetime of the object? else we have the added problem of
invalidating the cached value etc...
what is interesting about your example code is that you use a boolean
and not a compare to null like
private value = null;
> Is it an immutable that the getValue returns the same value for the
> entire lifetime of the object?
I would tend to say 'yes'.
> else we have the added problem of
> invalidating the cached value etc...
Sure, if we have a setValue method (or any method that affects the value), it
should rese
On 11/3/06, Vincent <[EMAIL PROTECTED]> wrote:
[...]
private boolean cached = false;
private value = null;
private Object value = null;
private RuntimeException rte = null;
public String getValue()
{
if (!cached)
{
try
Hi Sean,
I think you nailed it.
That is exactly what I was hinting at (or atleast that was the
undercurrent) if teams want to use X framework for something they are
welcome to do it and frankly they will do it. But as a specification
you don't always have the leisure to accommodate all. And tryi
The problem with cache invalidation for muttable objects in a
multithreaded environment isn't straightforward .. I'll get back to
you on the exception scenario...
> The problem with cache invalidation for muttable objects in a
> multithreaded environment isn't straightforward
Why would two threads access the same request?
If it's the case, wouldn't we need to add proper synchronization to the
getStream method anyway?
public synchronized InputStre
> I believe this approach simply redirects
> JSR 47 logging into our log4j log and we write all our stuff into our logs
> too. That may not be ideal, nor may it be the reality. I'll get back...
>
> Sean
>
Yep. That's what we do. It looks like this in the application file:
java.util.logging.Logg
Jerome Louvel noelios.com> writes:
>
>
> Hi all,
>
> An intermediary snapshot is available:
> http://www.restlet.org/downloads/current.zip
>
> Best regards,
> Jerome Louvel
>
> ---
>
>
> [API breaking changes]
> - Moved Atom, FreeMarker and FileUpload extensions to
> org.restlet.ext.atom/
23 matches
Mail list logo
