Wrong snapshot

[Lars Heuer]

Hi Jerome,

 delivers the wrong snapshot. When
someone tries to download
 a
"restlet-1.2-snapshot" is delivered. According to the changes.txt the
snapshot was created at 2009-05-16.

Best regards,
Lars

-- 
Semagia


--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2371459

Timeline for Restlet M4?

[Lars Heuer]

Hi Jérôme & co.,

Do you have an idea when the remaining bugs [1] are resolved? In a
project I tried to support Restlet 1.x and 2.x but recently I switched
over to Restlet 2.0M3 due to API incompatibilities.

Now I've got the request if it wouldn't be better to switch back to
Restlet 1.x. :)

I could use the 2.0 SVN snapshots, but an official release would
provide a better impression.

It would be great if you can provide a rough time line so I can
estimate if I should switch back to 1.x or support both Restlet
versions or wait for the next milestone.

[1]


Thanks in advance,
Lars
-- 
http://www.semagia.com

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2367063

Re: Google AppEngine and Restlet

[Lars Heuer]

Hi Jérôme,

> When using third-party libraries with GAE SDK, you have to be
> careful because those libraries are not verified against the
> available Java classes (white list). Therefore, it will work locally
> but break at deployment time!

Are you sure? I understood the purpose of the SDK that it emulates the
Google service completely. So, if a lib uses classes not available at
the Google server, your application won't work (locally).

Best regards,
Lars
-- 
http://www.semagia.com

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1631135

Re: Google AppEngine and Restlet

[Lars Heuer]

[...]
> Just out of curiosity: Has someone tried Google AppEngine [1] together
> with Restlet (Servlet connector)?

I ran a few toy applications against the Google AppEngine SDK and
discovered no problems so far.

Best regards,
Lars
-- 
http://www.semagia.com

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1628383

Restlet 1.2 -- Filter

[Lars Heuer]

Hi all,

I ran against a problem with the 1.2 Filter. The filter does not let
me specify that 'next' is a ServerResource.

I propose to change Filter as follows:

- Add method "setNext(Class targetClass)"
  or "setNext(Class targetClass)"
- Remove "setNext(Class targetClass)"
- Add a constructor that takes either Class or Classhttp://www.semagia.com

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1628327

Re: Comments against Restlet 1.2M2

[Lars Heuer]

Hi all,

[...]
> Some comments against that release:
[...]

I like to add another point: Rename ServerResource#isExists to
isExisting(). "isExists" hurts me. ;) It would make sense to rename
setExists(boolean) as well.

Best regards,
Lars
-- 
http://www.semagia.com

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1617653

Google AppEngine and Restlet

[Lars Heuer]

Hi all,

Just out of curiosity: Has someone tried Google AppEngine [1] together
with Restlet (Servlet connector)?

[1]


Best regards,
Lars
-- 
http://www.semagia.com

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1601014

Re: Annotations and Restlet's future

[Lars Heuer]

Hi Rémi,

> Will annotations in restlet the "advertised" way of creating restlet
> application ?

I moved to Restlet 1.2 M2/snapshot without using annotations. I found
no reason why these annotations will help me. Everything works fine
without annotations and I think/hope Restlet won't force us to use
them in the near future.


Best regards,
Lars
-- 
http://www.semagia.com

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1600565

Comments against Restlet 1.2M2

[Lars Heuer]

Hi all,

First of all, I love the RepresentationInfo. :) Thanks for adding
this. :)

Some comments against that release:
- I wonder how to create a RepresentationInfo since it is abstract;
  for the time being I created my own RepresentationInfo class derived
  from the abstract class.
- Wouldn't it make sense to add a constructor
  RepresentationInfo(Variant variant, Date modificationDate)
  This constructor would add all information available from the
  variant (i.e. MediaType, Language etc.) to the RepresentationInfo
  plus the modification time.
- Previously I used Resource(Context, Request, Response) in my derived
  Resource classes. This constructor is not available anymore in
  ServerResource. Not a big problem, though, even I have had to make
  my properties non-final, which is also not a big problem since
  Resources are not meant to be thread-safe.
- Related to the above mentioned point, I allowed that my derived
  Resources throw an exception in the constructor. This was very
  convenient since Restlet automatically issued an error status. While
  moving my initialisation stuff to the ServerResource.init() method I
  recognised that init() does not allow to throw an exception, so I
  have to wrap my initialisation code in a try / catch block.
  I wonder if UniformResource#init() shouldn't be changed to

protected void init() throws ResourceException;

  (or maybe Exception instead of ResourceException?)

  If an exception was thrown, Restlet 1.2 could handle it like Restlet
  1.1 handled exceptions thrown by the constructor.

Best regards,
Lars
-- 
http://www.semagia.com

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1518119

Re: Restlet 1.1.1 released

[Lars Heuer]

Hi Jérôme,

[...]
> Download links:
> http://www.restlet.org/downloads/1.1/restlet-1.1.1.exe
> http://www.restlet.org/downloads/1.1/restlet-1.1.1.zip

I wonder if it has been discussed before, but imo it would be nice if
the Restlet libs would have the version number encoded in the name,
like several extension have already (reflecting the version of the
underlying lib).

I.e.:
 org.restlet-1.1.1.jar
 com.noelios.restlet-1.1.1.jar


Best regards,
Lars
-- 
http://www.semagia.com

Re: Restlet 1.1: Rationale behind deprecation of Variant#setModificationDate

[Lars Heuer]

Hi Jerome,

[...]
> I think there is room for optimization but this would lead to some
> significant refactoring. Let's have a look at this for Restlet 2.0:

> "Optimize conditional handling"
> http://restlet.tigris.org/issues/show_bug.cgi?id=633

Thanks, for the time being I'll handle that use case internally. BTW
it might be nice if the big "Resource#handleGet()" method can be
divided into smaller chunks of code. That would enable developers to
"hook" into the process chain.

Best regards,
Lars
-- 
http://www.semagia.com

Re: Restlet 1.1: Rationale behind deprecation of Variant#setModificationDate

[Lars Heuer]

Hi Jérôme,

[...]
> The change was made because the Variant class is only needed for the purpose 
> of
> content negotiation. Also, the "expirationDate", "modificationDate", "tag" 
> and "size"
> properties can be costly to retrieve (some I/O needed) so it seemed better to 
> not imply that they should be provided to simply list the available variants.
>

I understand.

But taking i.e. the Bookmark example (chapter 7): In the
BookmarksResource  all available Bookmarks are retrieved from the user
object. All that code wouldn't be executed if the BookmarksResource
can determinate in the constructor the last modification time and add
it to the available variants.

Maybe my use case isn't popular enough, but in my application I know
very early the last modification time (in the constructor of my
Resource). And similar to the BookmarksResource I pull more
information once represent(Variant) is invoked.

So I wondered why the Variant's properties where removed. But if I
understood you correctly, the list of Variants were never used for
condition checking?
For some reason I assumed that the engine uses the Variants to check
conditions, if possible. If the necessary information are not
available as Variant properties, the engine processes the request as
usual and checks the conditions against the Representation.
That process would perfectly meet my use case.

> In most cases, the simple instantiation of a Representation subclass isn't 
> costly as long as you don't preload/preprocessing/parse stuff in the 
> constructor.

Yes, I wasn't clear in my request; I meant the represent(Variant)
method, not the construction of a Representation subclass.

Best regards,
Lars
-- 
Semagia

Re: Restlet 1.1: Rationale behind deprecation of Variant#setModificationDate

[Lars Heuer]

Hi again,

> I tried to find out why Variant#setModificationDate(Date) and several
> other methods
> are deprecated. I wasn't able to find a rationale for it.
> Maybe someone can explain it?

I found the revision dtd. 2007-07-21 10:27:14-0700:


Unfortunately the log does not specify the reason.

Best regards,
Lars
-- 
Semagia

Restlet 1.1: Rationale behind deprecation of Variant#setModificationDate

[Lars Heuer]

Hi all,

I tried to find out why Variant#setModificationDate(Date) and several
other methods
are deprecated. I wasn't able to find a rationale for it.
Maybe someone can explain it?

Variants are very cheap while Representations are more expensive. I
think it is a
Good Thing if a client can be satisfied with a 304 (not modified)
status without
creating an expensive Representation.

Best regards,
Lars

-- 
Semagia

Re: GroovyRestlet, a simple DSL for constructing Restlet application easily

[Lars Heuer]

Hi Jerome,

> This is excellent and will remind to some long Restlet users an experience
> that was made on "fluent builders" early in API design. Lars are you around?

:)

Nice project keke! :)

Best regards,
Lars
-- 
http://www.semagia.com

RESTClient

[Lars Heuer]

Hi all,

Got this today via Freshmeat:

RESTClient is a Java platform client application to test RESTful
webservices. 

Best regards,
Lars
-- 
http://www.semagia.com

Another RESTful Java project: Restfulbeans

[Lars Heuer]

Hi all,

Today, this project was announced at Freshmeat

https://restfulbeans.dev.java.net/

Freshmeat description:

  RestfulBeans is a high level API for sharing objects between a
  server and a Java-based client. The underlying protocol is designed
  to expose the data consumed by a rich client to the search engines.
  The key properties of the protocol are compliance with the HTTP spec
  and REST principles, and XML representation for Java Beans with
  object references represented as XLink (to allow search engines to
  walk through the object tree). A key API property is the ability to
  work with remote objects as if they were local. An application using
  RestfulBeans is automatically capable of supplying users with URLs
  for any “content item” it deals with.

Best regards,
Lars
-- 
http://www.semagia.com

Re: mina

[Lars Heuer]

Hi Jerome,

> We indeed have this dependency on AsyncWeb, but they seems to be working on
> updating it for MINA 1.0:

BTW: Today MINA 0.8.4 was released. This is a bug-fix release and the
should be the last 0.8-branch release.
Maybe you like to update MINA with the last version (I haven't tested
it with AsyncWeb connector but I think the move from 0.8.0 to 0.8.2
isn't huge).

"""
Apache MINA 0.8.4 has been released.  It fixes an issue that
SocketIoProcessor throws a CancelledKeyException.  Apache MINA team has
decided not to support 0.8 branch anymore, and this release is the last
release in the 0.8 branch.  Please upgrade to MINA 1.0 to utilize more
advanced features and better API.

Distributions are available at:

http://www.apache.org/dyn/closer.cgi/mina/0.8.4/

Some mirrors might not have the tarballs yet and return 404 error. 
Please
try our backup site if you are having such a problem.
"""

Best regards,
Lars
-- 
http://www.semagia.com

Re: name conflicts

[Lars Heuer]

Hi Jerome,

> Here is a list of potential conflicts:
[...]
> IMHO, we should just try to live with this. It is for example not very
[...]

+1

Best regards,
Lars
-- 
http://www.semagia.com

Re: name conflicts

[Lars Heuer]

Hi Dave,

[...]
>> However, I'm willing to consider renaming if we have name conflicts with
>> core JDK classes (ie. in packages java.*). Does it sounds fair enough?

> Yes, but I do understand the problem.
> Not nice, but a possibility might be to prefix?
> E.g. Container => RContainer (restlet container) instead of 
> java.awt.Container.

Oh, no, please don't. We have namespaces in Java (the package names), that
should be enough.

Best regards,
Lars
-- 
http://www.semagia.com

Re: mina

[Lars Heuer]

Hi Jerome,

> We indeed have this dependency on AsyncWeb, but they seems to be working on
> updating it for MINA 1.0:

Yes, I am watching the AsyncWeb project but I suspect that the move
will happen soon since Dave is busy with other things. Once they have
moved I can try to adapt the AsyncWeb connector (if the AsnyncWeb API
has changed).

Best regards,
Lars
-- 
http://www.semagia.com

Re: mina

[Lars Heuer]

Hi Piyush,

> Any plans to upgrade to the latest mina release (1.0 released in
> October)?

Since AsyncWeb still uses Mina 0.8 and Mina 1.0 contains compatibility
breaks, we have to wait for AsyncWeb (or write our own HTTP server).

Best regards,
Lars
-- 
http://www.semagia.com

Re: NRE HttpServerCall

[Lars Heuer]

[...]
> While thinking about it, I wonder if we need the Input/Outputstream at
> all.
> Why do we not work with Channels / ByteBuffers only?

Naaahh... forget it, keep both! :)

Best regards,
Lars
-- 
http://www.semagia.com

Re: NRE HttpServerCall

[Lars Heuer]

[...]
> the method first checks for an ResponseStream and if the stream is
> null it checks for an ResponseChannel (line 224).
[...]
> Shouldn't that be done the other way around? The channel should be
> preferred.


While thinking about it, I wonder if we need the Input/Outputstream at
all.
Why do we not work with Channels / ByteBuffers only?
A Representation may utilize the

  java.nio.Channels

class and use the

  Channels.newChannel(InputStream in)
and
  Channels.newChannel(OutputStream out)

to convert Input/OutputStreams into channels.

Best regards,
Lars
-- 
http://www.semagia.com

NRE HttpServerCall

[Lars Heuer]

Hi,

In

  HttpServerCall.sendResponse

the method first checks for an ResponseStream and if the stream is
null it checks for an ResponseChannel (line 224).

[...]
 if (getResponseStream() != null)
 {
entity.write(getResponseStream());
 }
 else if (getResponseChannel() != null)
 {
entity.write(getResponseChannel());
 }
[...]

Shouldn't that be done the other way around? The channel should be
preferred.
  
Best regards,
Lars
-- 
http://www.semagia.com

Re: Eclipse plugin?

[Lars Heuer]

Hi Jerome,

> This another way to use the Restlet plugins in Eclipse. I think it should be
> only recommended for people contributing code to the Restlet project or
> requiring constant access to the source code of the project. 
[...]

Ok. :) Sorry. Thanks for explaining the thoughts behind the "Plugin"
idea to Justin and me. :) I never saw it in that light. I usually use
a few jars in a "lib" folder and add them to the build path.

Best regards,
Lars
-- 
http://www.semagia.com

Re: Eclipse plugin?

[Lars Heuer]

Hi Justin,

> The restlet/lib/readme.txt says to drop the contents 
> of the directory into the Eclipse plugin directory.  I 
> did that but didn't notice any change once I started 
> Eclipse back up.  Is there something more I should 
> be doing?
[...]

The plugins are not meant to enhance Eclipse. You can use them to
import the Restlet project into your Eclipse workspace
(File -> Import).

Best regards,
Lars
-- 
http://www.semagia.com

b19: Wrapper(Req|Resp|Res)

[Lars Heuer]

Hi Jerome,

I saw, you've reintroduced the Wrapper classes. Before I change my
code: Will they stay in the future releases?

Best regards,
Lars
-- 
http://www.semagia.com

b19 - Application

[Lars Heuer]

Hi Jerome,

You've requested a feedback for the new Application feature.
Unfortunally I am unable to give feedback before next Monday. Sorry. I
am busy with aligning one of my projects to b19 but I didn't enter
the 'higher' Application level, yet. :/

Best regards,
Lars
-- 
http://www.semagia.com

b19 Wrapper (was: Re: b19 - Resource)

[Lars Heuer]

Hi Jerome,

> I've readded the default constructor to Resource (in SVN). I need a way to
[...]

Merci :)

> The need for wrapper when further to many other classes as it's the
> mechanism used to separate the API classes from the implementation classes.

So, we need the wrapper classes for the Restlet / Noelios engine? If
they are needed for the latter, why don't we remove them from
org.restlet and put them into the noelios.impl package?

> It was becoming too cumbersome to maintain all those wrappers (and create
> new ones), Javadocs duplication and making sure no method wrapper code was
> missing.

I was writing this while your e-mail popped up:

I wonder if we need the 'decoratable' behaviour in the mentioned
classes. If we don't like to have a few more classes (the Wrapper*
classes), we should remove the 'decoratable' feature from the
Resource, Restlet, Request... . While I am using the decorated classes
a lot in my Restlet projects, I think that modern IDEs like Eclipse
provide enough support to write a class that delegates methods
calls to a 'wrapped' class.

IMO this approach is much cleaner than the "getWrapped*" calls in
every method.

Other thoughts?

Best regards,
Lars
-- 
http://www.semagia.com

Re: b19 - Resource

[Lars Heuer]

Hi Chris,

[...]
> I'm not sure what the 'wrappedResource' is either, but I
> haven't investigated much into that. Just getting into updating my
[...]

Jerome has unified the 'plain' Resource with the WrapperResource (from
b18).

Personal note: Not sure if I like the unification of the Decorator
pattern with the 'normal' classes (this affects also Restlet, Request,
Repsonse, ...).

Best regards,
Lars
-- 
http://www.semagia.com

Re: b19 - Entity

[Lars Heuer]

[...]
> But acc. to HTTP/1.1 contains an Entity the *header* and an optional
> *body*. But in Restlet this is not the case: "getEntity" returns the
> *body* of the Entity.

Well, not really, the Representation carries values that belong to
the header, but not all. I think another (neutral) term avoids
confusion. I.e. the "Allow" header is one of the "standard" Entity
headers acc. to HTTP/1.1, but it is not possible to set / get this
header from the value returned by "getEntity". Beside that other
headers are allowed as Entity headers, but this is also not supported
by the Representation.

Best regards,
Lars
-- 
http://www.semagia.com

b19 - Resource

[Lars Heuer]

Hi Jerome,

For me it is not obvious why a Resource now must be constructed with a
Logger instance. Can you explain this change a bit?

And because the Logger may be initialized lazily in the "getLogger"
method: Why does the Resource not provide a default constructor?

Best regards,
Lars
-- 
http://www.semagia.com

b19 - Entity

[Lars Heuer]

Hi Jerome,

The b19 (to be) contains a API change "getInput()" -> "getEntity". So
far, so good.
But acc. to HTTP/1.1 contains an Entity the *header* and an optional
*body*. But in Restlet this is not the case: "getEntity" returns the
*body* of the Entity.

Best regards,
Lars
-- 
http://www.semagia.com

Re: Breaking Call into Request and Response (Was: Allow Header)

[Lars Heuer]

Hi Jerome,

[...]
> Testing over the week-end is very welcome as I'll try to finish/release on
> Monday if possible.

Last night I converted two projects to the new Request/Response style
and everything works as expected.

Best regards,
Lars
-- 
http://www.semagia.com

Re: Allow Header

[Lars Heuer]

[...]
> Because it is more a "server thing", I don't know if the
> call.getAllowedMethods() makes sense. The idea with the additional

Arrg, sorry, I am thinking too server-centric. It makes sense on the
client side of course. :)

Best regards,
Lars
-- 
http://www.semagia.com

Re: Allow Header

[Lars Heuer]

Hi Jerome,

[...]
> Here is the battle plan:
>  - add a method to Call: getAllowedMethods() : List
>  - add a method to Resource: 
> * allowGet()   : boolean (false by default)
> * allowPost()  : boolean (false by default)
> * allowPut()   : boolean (false by default)
> * allowDelete(): boolean (false by default)
> * getAllowedMethods() : List

> The default implementation of Resource.getAllowedMethods() would test all
> the can*() methods and create the matching result list.

Because it is more a "server thing", I don't know if the
call.getAllowedMethods() makes sense. The idea with the additional
methods on "Resource" sounds good.

Do you have a timeline for it? Will it be in b19?

For the time being I'll comment out the respective line in
HttpServerConverter to set my Allow header

Best regards,
Lars
-- 
http://www.semagia.com

Re: Allow Header

[Lars Heuer]

Hi Jerome,

> Only non-standard headers can be added via the special attribute. The
> "Allow" header is supported at the API level by the
> Call.getClient().getAccepted*() methods.

Thanks, that was one of the places where I looked, but I cannot find a
way how to set, i.e.

   Allow: GET, PUT, OPTIONS

Hints?
   
Best regards,
Lars
-- 
http://www.semagia.com

Allow Header

[Lars Heuer]

Hi all,

How can I set the HTTP header "Allow"? If I use the new
call.getAttributes(...) method Restlet tells me, that I cannot set the
"Allow" header.

Best regards,
Lars
-- 
http://www.semagia.com

Re: Method

[Lars Heuer]

Hi Jerome,

[...]
> We predefined the standard HTTP and WebDAV methods, but nothing in REST or
> HTTP prevents the user from creating new ones if needed. If we think about
> the mapping of other protocols to the API which may also require new
> methods. 

You're absolutly right. Sorry for this not well thought silly
suggestion. :)

Best regards,
Lars
-- 
http://www.semagia.com

Re: Method

[Lars Heuer]

Hi Jerome,

> These properties are in fact in the super Metadata class, and used for
> example with Status instances to display error pages with meaningful
> descriptions and hyperlinks. 

Yes, I know and for Status it makes sense.

I think Method should not be derived from Metadata because it doen't
adds a value IMO.

To avoid confusion if the Method can be compared by identity or not,
we should convert Method (back?) to an Enum. Enums can always be
compared by identity, so it limits confusion if Method is comparable
by identity or not.

Best regards,
Lars
-- 
http://www.semagia.com

Re: Method

[Lars Heuer]

Hi Jerome,

> In the current state, the "description" (from Metadata super class) and the
> "uri" property could be customized for the same method.

Okay, I overlooked that. :/

>  Therefore, unless we
> remove those properties or forbid their setting, it won't be possible to
> compare simple object reference for equality.

I see. I wonder if the properties are useful for the Methods.
Comparing by identity is not s important, but who actually uses
Method.getDescription() or Method.getURI()?

Best regards,
Lars
-- 
http://www.semagia.com

Method

[Lars Heuer]

Hi all,

Now that we have the static method

Method.valueOf(String)

I wonder if it makes sense to make the Method constructors private. I
think it's unlikely that someone wants to create a non-standard
Method.
If the constructors are private we can compare Method instances by
reference which should be a lot faster than the equals(Object) method.

Thoughts?

Best regards,
Lars
-- 
http://www.semagia.com

Re: b19 - Call converters

[Lars Heuer]

[...]
>> If we need to attract some servlet developers later-on maybe it is 
>> wise to have a method like getParameter()  this will help in 
>> transition from servlets to restlets. 

... and you can use a WrapperCall if you want additional methods. You
can implement shortcuts etc. in your WrapperCall instance.

Best regards,
Lars
-- 
http://www.semagia.com

Re: b19 - Call converters

[Lars Heuer]

Hi Jerome,

> I was really worried about this issue that you raised, so I'm glad that you
> like the solution! I hope that you don't mind about the "org.restlet" prefix
> change.

Go ahead! :)

Best regards,
Lars
-- 
http://www.semagia.com

Re: b19 - Call converters

[Lars Heuer]

Hi Jerome,

Just a short note that I really like the solution. I aligned my
implementation to it. It is very flexible and does not force the user
to depend on a particular Restlet engine.

Thanks for the work :)

Best regards,
Lars
-- 
http://www.semagia.com

Re: b19 - Call converters

[Lars Heuer]

Hi Piyush,

[...]
> Could we somehow do the same with parameters of the query string?

> /a/b/c?key1=value1&key2=value2

> org.restlet.reference.params.key1
> org.restlet.reference.params.key2

Why do you think this adds a value?

Best regards,
Lars
-- 
http://www.semagia.com

Re: b19 - Call converters

[Lars Heuer]

Hi Jerome,

> Actually, I'm thinking about "restlet.http.requestHeaders". This is a bit
> longer but clearly applies to calls based on the HTTP protocol. Any
> objection?

Nope, good idea. :)

Best regards,
Lars
-- 
http://www.semagia.com

Re: b19 - Call converters

[Lars Heuer]

Hi Jerome,

[..]
> should specify that all names starting with "org.restlet" are reserved by
> the framework. Then I should rename "requestHeaders" to
> "org.restlet.requestHeaders" or maybe just "restlet.requestHeaders". Of

+1 for restlet.requestHeaders

Best regards,
Lars
-- 
http://www.semagia.com

Re: b19 - Call converters

[Lars Heuer]

Hi Jerome,

Sorry for my late reply. :)

> I think you will be happy to know that I've found a simpler solution. Now,
> the HTTP server|client connectors systematically pass the list of
> request|response headers as an attribute in the call's attributes map.

Looks promising. The only thing I like to bring to your attention: I
thought that the "attributes" property of the Call is an
user-controlled Map. The user can do whatever she wants to do with it.
Now Restlet invades this user space. Since I am not using the
"attributes" property yet, it's no problem for me. But the users
should be aware of this Restlet behaviour. I'm not sure if this
intrusion legitimates another Call attribute that is controlled by
Restlet.

Thanks for your work. :)

Best regards,
Lars
-- 
http://www.semagia.com

Re: b19 - Call converters

[Lars Heuer]

Hi Jerome,

[...]
> the value of some of them (probably in the case of non-standard HTTP
> headers?) in your Restlets, then you need to *push* them to the uniform Call
> instance. This is what the sample converter code demonstrates.

Yes. But I cannot give my restlet to another developer and it just
works. She has to change her implementation just because I want to
read headers.
As long as I work in my microcosmos everything works fine but nobody
outside my microcosmos can use my Restlet and my utilities without
changing the implementation.

[...]
> Your current approach is *pulling* headers from the call, which I want to
> discourage because it needs some protocol/connector specific handling within
> the uniform Call and Restlets.

I understand your concerns and everything you write is right. I liked
the releases until b18, because releases < b18 provided the uniform
call but if an user really really wants / has to escape from the
uniform Call outside to the underlying technology it was possible.

[...]
> I already know about the X-Forwarded-For header scenario explained by John
> D. Mitchell, but I would be very interested to know more about your own
> scenarios, requiring you to manipulate raw HTTP headers. Anyway, call
> converters should cover your needs, indeed with some refactoring on your
> side. Let me know if I missed something.

I get (and set) for example something like this (source: [TMIP]):

  GET /internet/web//browser/bn`s HTTP/1.1
  Host: server1.farm.example.org
  X-TMIP-Accept-Scope: uc, en, de, *
  Accepts: text/xml

But how do I get "X-TMIP-Accept-Scope" *without* modifying the uniform
call (side effects)?

Are my requirement too specific? ;)

[TMIP]


Best regards,
Lars
-- 
http://www.semagia.com

Re: b19 - Call converters

[Lars Heuer]

Hi again,

one follow-up:

((HttpServerRestletCall) call).getConnectorCall().getRequestHeaders()

only works with "unwrapped" calls. That's why I suggested to make

 WrapperCall#getWrappedCall()

"public".

If it is public I could do something like this:

   if (call instanceof WrapperCall) {
   Call unwrappedCall = call.getWrappedCall();
   doSomthing(((HttpServerRestletCall) unwrappedCall)
   .getConnectorCall()
  .getRequestHeaders());
   }

Since getWrappedCall() is not public I have to derive every MyCall
instance from MyWrapperCall where the modifier is "public". Arrrg. :/

Would it do any harm to make getWrappedCall() public? It would be
easier to write utilities that work with either Call or WrapperCall
instances without the need to derive from a custom MyWrapperCall
class.

Best regards,
Lars
-- 
http://www.semagia.com

b19 - Call converters

[Lars Heuer]

Hi Jerome & Co.,

Here an excerpt of a class I use nearly for all projects where Restlet
is involved:

public class Headers {
/**
 * Constructor that wraps a [EMAIL PROTECTED] 
org.restlet.data.ParameterList}.
 *
 * @param paramList The parameter list instance to wrap.
 */
private Headers(ParameterList paramList) {
_paramList = paramList;
}

/**
 * Returns a header instance that is bound to the request headers.
 *
 * @param call The [EMAIL PROTECTED] org.restlet.Call} instance to retrieve 
the 
 *  request headers from.
 * @return A headers instance that is initialized with the request headers.
 */
public static Headers fromRequest(Call call) {
//FIXME: Does not work with WrapperCall cf. 
http://restlet.tigris.org/issues/show_bug.cgi?id=158
return new Headers(((HttpServerRestletCall) 
call).getConnectorCall().getRequestHeaders());
}

[...]
}


I looked into the example and source code of the new call converters
but they don't help me here, right?

In an arbitrary Restlet I use it like:

   Headers headers = Headers.fromRequest(call);
   if (headers.get("X-bla-bla") == null) {
  // do something
   }
   else {
  // do something
  headers.add("X-blub-blub", "FooBar");
   }

I just want the headers, nothing more, nothing less. :)

Best regards,
Lars
-- 
http://www.semagia.com

Re: What happened to ConnectorCall???

[Lars Heuer]

Hi Mikkel,

[HTTP Headers]
>> This seems to work fine for server calls, but how about client calls?

I've added a ticket
http://restlet.tigris.org/issues/show_bug.cgi?id=159

Feel free to provide more information / additional thoughts.

Best regards,
Lars
-- 
http://www.semagia.com

Re: FileRepresentation buffers large files

[Lars Heuer]

Hi Mikkel,

As you might know Jérôme is away (I think he'll be back next week).

> When I try to send large files from a GenericClient I often run into an
> OutOfMemoryError.
> Apparently the ByteUtils.write(InputStream, OutputStream) method wraps a
> BufferedOutputStream around the OutputStream (why?)

The support for large files in HttpUrlConnection is a bit weak. But I
think it was enhanced in Java 5.

Maybe this bug report helps you
  http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5026745

If I am not mistaken, [HttpClient] supports uploading large files;
maybe you can look into the source code what they are doing.

[HttpClient] http://jakarta.apache.org/commons/httpclient/

Best regards,
Lars
-- 
http://www.semagia.com

Re: What happened to ConnectorCall???

[Lars Heuer]

Hi Mikkel,

> Hi Lars, thanks for the tip!

> This seems to work fine for server calls, but how about client calls?

Reg. HTTP headers see my other mail, but for query parameters you can
still use

  call.getResourceRef().getQuery()

or
  Form form = call.getInputAsForm();   // The method name is
   // missleading, it works
   // for the query part
   // as well
  
without the need to convert it into a connector-specific call.

Best regards,
Lars
-- 
http://www.semagia.com

Re: What happened to ConnectorCall???

[Lars Heuer]

[...]
> Jérôme wants to provide call converters that make it possible to
> convert a org.restlet.Call into the particular Call implementation but
> this isn't done yet.

C.f. http://restlet.tigris.org/issues/show_bug.cgi?id=145

Best regards,
Lars
-- 
http://www.semagia.com

Re: What happened to ConnectorCall???

[Lars Heuer]

Hi Mikkel,

> This seems to work fine for server calls, but how about client calls?

Good question. :) No idea.

I looked into

   com.noelios.restlet.ext.net.HttpClient.handle(Call call)

but it seems that the HttpClient ignores custom HTTP Header values.
It only sets i.e. user agent, encoding etc.

I don't use client calls (yet), maybe others can answer that?

Best regards,
Lars
-- 
http://www.semagia.com

Re: What happened to ConnectorCall???

[Lars Heuer]

Hi Mikkel,

> It seems that the ConnectorCall class has been removed from the API in the
> latest release (1.0-beta18)

Jérôme wants to provide call converters that make it possible to
convert a org.restlet.Call into the particular Call implementation but
this isn't done yet.

> What is then the new procedure for manipulating HTTP headers and obtaining the
> requestUri?

You can cast the Call to HttpServerRestletCall and then work with the
HttpCall interface.

  HttpCall httpCall = ((HttpServerRestletCall) call).getConnectorCall();

  ParameterList headers = httpCall.getRequestHeaders();


BTW: IMO com.noelios.restlet.connector.HttpCall should be moved into
org.restlet.connector to stay independent from the NRE.
  
Best regards,
Lars
-- 
http://www.semagia.com

Re: Converting a DomRepresentation to StringRepresentation

[Lars Heuer]

Hi Sean,

> I have an application that contains a filter that converts incoming XML into a
> DomRepresenation so that it can be manipulated later as a document. Then, on 
> the
> return, a document comes to the afterHandler() and I want to transform that 
> into
> XML to return to the client. How do I easily get the write() output from the
> DomRepresentation into a StringRepresentation? 

There is no need to convert the DomRepresentation into the
StringRepresentation. Just call:

 call.setOutput(domRepresentation);

Restlet handles the transformation for you.

Best regards,
Lars
-- 
http://www.semagia.com

Re: API design review

[Lars Heuer]

Hi Piyush,

> I agree with the very first comment to the message posted on
> theserverside.com. But I also agree Chris's comment

Yes, I think it would be a good idea to wait until we know what people
do with Restlet. Maybe the final classes should be postponed till v1.1
or something like that. The decision about final classes shouldn't be
a showstopper for 1.0.

Best regards,
Lars
-- 
http://www.semagia.com

Re: API design review

[Lars Heuer]

Hi Jerome,

[...]
>  - Make all classes, except those intended to be subclasses, as final. Which
> ones?
>  - Make classes whose instances don't need to be modified as immutable
> (members are final).

Be careful.

Cf. Michael Feathers: It's time to deprecate final




Best regards,
Lars
-- 
http://www.semagia.com

Re: silly sample app available

[Lars Heuer]

Hi Jerome,

[...]
> Nice. BTW, we also have someone (Thierry Boileau) working on a writable
> DirectoryHandler. This should be part of beta 19. It will be our own little
> WebDAV implementation based on a file system.

Very cool. That is something I really like to have. :) Looking forward
to test it (*hint* ;) )


Best regards,
Lars
-- 
http://www.semagia.com

Re: [OT] A kind of standard XML format for e-mails

[Lars Heuer]

Hi Jerome,

[...]
> There is indeed a hole here. The Internet Mail Consortium (IMC), started
> some work on a Next Generation of email as well as an XML message format,
> but nothing concrete came out so far and the groups are inactive.

Too bad.

> Paul Prescod did an interesting proposal for a RESTful email system but
> doesn't address the message format part too much:
> http://www.prescod.net/rest/restmail/

Yes, I read it but as you've pointed out, he doesn't address the XML
format. :(

> That's why I came up with my own little format :-) I'd like to improve this
> extension in the future and maybe provide a complete email system based on

Interessting. I'll work on it a bit (I need it for a project); not on
the e-mail system, but on an XML format that fits my needs (retrieval
from POP and IMAP). Maybe we can merge our efforts in the future.

> Restlets. I've enter a report to keep track of this, feel free to add
> comments/ideas:
> http://restlet.tigris.org/issues/show_bug.cgi?id=138

Thanks. :)

Best regards,
Lars
-- 
http://www.semagia.com

Re: JSR and updated road map

[Lars Heuer]

Hi Jerome,

[Restlet 2.0 for JSR]
> What do you think?

I love it :)

Best regards,
Lars
-- 
http://www.semagia.com

Re: Router behaviour

[Lars Heuer]

Hi all,

Just a quick note, that everything works as expected with b17.

Best regards,
Lars
-- 
http://www.semagia.com

Re: JSR and updated road map

[Lars Heuer]

Hi Jerome,

[...]
> So, I was convinced to start the process ASAP instead of waiting until
> 2007Q2. This also means that the 1.0 final release will be delayed and will
[...]

I hope that the development is not stalled because of the JSR approval
process.

Best regards,
Lars
-- 
http://www.semagia.com

Re: Router behaviour

[Lars Heuer]

Hi Jerome,

> I've just added this change to PatternScorer in SVN:
>  - Improved the logging of PatternScorer's logic. 
>Adjust your logging properties to see the traces (FINE and FINER levels).

Thanks.

I'll try the SVN version and maybe provide a test case. I am
overloaded with other things so I wasn't able to to track this issue
down. I'll provide more information asap.

Best regards,
Lars
-- 
http://www.semagia.com

Re: Router behaviour

[Lars Heuer]

Hi Jerome,

[...]
> Lars, do you still have issues with the router behavior?

Yes, as far as I know. :)

I didn't find the time to debug and / or try with the latest SVN. As
far as I can see you didn't change anything at the Router / Scorer
code, so I expect that the trouble is still there. :)

Best regards,
Lars
-- 
http://www.semagia.com

Re: Router behaviour

[Lars Heuer]

Hi,

Maybe an interesting additional fact:

This still works:

  .attachRouter("/somePath")
 .attach("$", new MyRestlet()).back()
 .attach("/blabla", new BlaBlaRestlet()).back()
 .attach("/blubblub", new BlubBlubRestlet()).back()
 // [...]


Only if the Router is attached to a Filter (f.k.a. Chainlet) without
an initial path, the "$" does not work.
 

Best regards,
Lars
-- 
http://www.semagia.com

Router behaviour

[Lars Heuer]

Hi all,

I've discovered a strange Router behaviour while switching from b14 to
b15/b16:

With b14 this code worked (using StructureBuilder, sorry):

 // [...]
 .attachRouter()
.attach("$", new MyRestlet()).back()
.attach("/blabla", new BlaBlaRestlet()).back()
.attach("/blubblub", new BlubBlubRestlet()).back()
// [...]


It costs me the better part of last evening to discover that the

   attachRouter().attach("$", ...)

does not work anymore.

Now I've to use
 // [...]
 .attachRouter()
.attach("[^/]*", new MyRestlet()).back()
.attach("/blabla", new BlaBlaRestlet()).back()
.attach("/blubblub", new BlubBlubRestlet()).back()
// [...]

(I am not sure if I've used [^/]* or [^/]+, but I believe the first)

Can anybody imagine why the more intuitive "$" does not work anymore?
I am using the DefaultBuilder(Component owner) constructor, default
mode.

Best regards,
Lars
-- 
http://www.semagia.com

Re: RFC - Release plan preparation

[Lars Heuer]

Hi all,

[...]
> I'd like it too, but I'm unsure about the feasibility for 1.0, especially
> for the quality level required in order to have them as default connectors.
> Also, we are dependent on the Mina project which hasn't reached 1.0 yet.
[...]

If we get the HTTP client / server connector ready it should be
included into 1.0. But Jérôme is right to mark the Mina-based
connector(s) with a big caution warning.
Mina is currently moving slowly to 0.9 so I suspect that we'll have a
stable Mina 1.0 when Restlet is going to be released.

Best regards,
Lars
-- 
http://www.semagia.com

Re: DirectoryHandler - Strange problems

[Lars Heuer]

Hi Jerome,

> FYI, I've checked in SVN some fixes to prevent this kind of NPE exceptions.
> We still have to figure out what is the cause of the behavior you're
> observing.

It is still a mystery for me but the reported exceptions are gone
without changing a single line of code (using b16 now).

Best regards,
Lars
-- 
http://www.semagia.com

Re: Hierarchical Path Components without contextMatches?

[Lars Heuer]

Hi Evan,

[...]
>> To store the user name you could also rely on call attributes:
>>   call.getAttributes().put("user", userName);

> Okay, perfect. I'll start using this instead of subclasses, as I don't
> need any custom logic in the call.

I don't want to beat a dead horse, only add a note that it might be
worthful to use a subclass of Call even if you do not add any extra
logic to it.
For all projects I am using my own Call impl. The Call.attributes are
is 'just' a Map. For two projects I just added a
   IContext Call.getContext()
method. In the context I am storing some values. I.e. for your example
you can implement your own IContext interface with
void setUser(String);
String getUser();

Using it:
String theUser = call.getContext().getUser();

And you don't have to do casts. If you need more values, just enhance
the IContext.

Using an own Call implementation might be an overkill sometimes, I
only wanted to advert the possibilities a subclass of Call can offer.
:)

Best regards,
Lars
-- 
http://www.semagia.com

Re: Expected refactoring

[Lars Heuer]

Hi Jerome,

[...]
> 1) Add a concept of Restlet Application and refactor the RestletServer and
> RestletContainer classes accordingly. A RestletApplication should be similar
[...]

It would be great if the Restlet(Container|Application) could be a
base for a OSGi RestletService. OSGi has already defined a HttpService
but it would be nice to have a dedicated Restlet service (is already
mentioned in the issue list, I think).
I don't know yet which service we would like to have. Either a
RestletApplicationService or a RestletContainerService. The first can
be used to register a RestletApplication or the latter to obtain a
container that is used to register Restlets.


Best regards,
Lars
-- 
http://www.semagia.com

DirectoryHandler - Strange problems

[Lars Heuer]

Hi all,

Is someone using the DirectoryHandler of beta15?

I've encountered strange problems:
1. It seems that the DirectoryHandler slows the app down more than the
   'old' DirectoryRestlet
2. Sometimes I get an exception from the ContextClient that the
   protocol is not supported. But this does not appear regulary only
   sometimes.

I am using the AsyncWeb and Simple connector with file system
directories.

I'd like to know if someone has similiar problems. Sorry for the vague
description, I'll provide more once I've analyzed it further.

Best regards,
Lars
-- 
http://www.semagia.com

Re: Name changes

[Lars Heuer]

Hi Jerome,

Would it be possible to release b15 as bug-fix release for b14 (with a
working DirectoryRestlet) and postpone the name changes to b16?
Or is it too much work?

I'll comment the other things in more detail later. :)

Best regards,
Lars
-- 
http://www.semagia.com

Re: Having a difficult time deploying RootContainer on Apache

[Lars Heuer]

Hi Bill,

[...]
> children Restlets (see design in thread below) I need to attach the
> same TranslationRestlet to all the children/leaves/Restlets -- to

Why are you not using a chainlet instead of a Restlet for the
TranslationRestlet?

I can think of the following solution:

  [rootContainer]
|
+--- [TranslationChainlet] <---> [rootMaplet]
   |
   + [...]
   |
   + [...]


Your TranslationChainlet should look like this

public class TranslationChainlet extends AbstractChainlet {

   // [...]

   public void handle(Call call) {

  // Normal call handling, just dispatching
  // the call to to the target (here the rootMaplet)
  super.handle(call);

  // Translate the input created by another
  // Restlet and set the translated output as new
  // output
  
  call.setOutput(transform(call.getOutput()));
  
   }

   private Representation transform(Representation rep) {

   // Do something with the output

   return translatedRepresentation;
   }

}

Hope it helps :)

Best regards,
Lars
-- 
http://www.semagia.com

Re: Restlet or Jetty issue: null logging

[Lars Heuer]

[...]
> Jetty uses its own logger facade. Either it logs via
> System.out.println or via http://slf4j.org/
> But I have no idea how to configure Jetty that it uses slf4j with
> Restlet. One of the slf4j jars in the classpath is not enough.

Acc. to
http://jetty.mortbay.org/jetty6/jetty-util/org/mortbay/log/Log.html
it should be enough to have one of the slf4j jars in the classpath.

Strange, I am using slf4j but the Jetty spits the msgs to my console.
Maybe it works if the Jetty connector does not run inside Eclipse.

Best regards,
Lars
-- 
http://www.semagia.com

Re: Restlet or Jetty issue: null logging

[Lars Heuer]

Hi John,

[...]
> When I start up, I getting a weird "INFO" message logged by Jetty:
> :INFO:  Logging to STDERR via org.mortbay.log.StdErrLog
> :INFO:  null null
> :INFO:  Started SelectChannelConnector @ 0.0.0.0:9080

> Is this a known problem?  No errors being reported in the Restlet logs
> or in my logs.

Jetty uses its own logger facade. Either it logs via
System.out.println or via http://slf4j.org/
But I have no idea how to configure Jetty that it uses slf4j with
Restlet. One of the slf4j jars in the classpath is not enough.

Best regards,
Lars
-- 
http://www.semagia.com

Re: Forms and the list of values

[Lars Heuer]

Hi John,

[...]
> Is there a reason this limitation was added?  Wouldn't it be better to
> change getValues() to e.g., getValuesString() and add a ParameterList
> getValues (name) method?

If you only need read-only access to the provided parameters I can
offer an alternative that also capable to read parameters from GET and
POST/PUT the same time (if I remember right, this was also a
requirement you have). If you want I can send you the code. It uses
String[] arrays and offers less functionality than the
Form/ParameterList classes but for my purposes it just fits. :)

Best regards,
Lars
-- 
http://www.semagia.com

Re: XForms, Restlet/Tomcat Integration

[Lars Heuer]

Hi Andrew,

[...]
> And to add to my own failings, another popular variation on this is to
> have "/policy$" as the final pattern, but the maplet before hand using
> "/users/", so that the full pattern needing to be matched is
> "/users//policy"

Note, that beside the already mentioned points, the order of the
attachments matters.

1.
  "users"
  "users/policy"
  -> "users" will be matched first, even if the URI is
  http://host.org/users/policy

2.
  "users/policy"
  "users"
  -> "users/policy" will be matched if the URI is
  http://host.org/users/policy


With the dollar you can prevent the 1st use case:
  "users$"
  "users/policy"
  -> "users" will NOT be matched if the URI is
  http://host.org/users/policy is because "$" tells the processor,
  that the URI MUST end with "users"

  
Best regards,
Lars
-- 
http://www.semagia.com

Re: Proposal for Call

[Lars Heuer]

Hi Jerome,

[...]
> I'm planning to add a ParameterList class, subclass of List, that
> will contain an additional add(String name, String value) method and
> probably additional helper methods. At least we'll be consistent with the
> current style, and the usage of the ParameterList class name should limit
> the risk of people assuming it is unmodifiable.

Maybe we should move this topic to its own (mail) thread and hope to
get some more input / opinions from the Restlet users? I am
interested to get some experience feedback with the modifiable
collections approach.

Best regards,
Lars
-- 
http://www.semagia.com

Re: Proposal for Call

[Lars Heuer]

Hi Jérôme,

>> Just for the record: I am (in contrast to some Restlet delelopers here
>> ;) ) not a big fan of modifiable lists (and collections in general).

> Understood :-) I know that this is not a classic style for Java APIs.

Right. IMO some (most?) of the Java users looking the first time at
Restlet will assume that the collections are unmodifiable because of
their experience with other Java libs / conventions.
Once Restlet has gained some popularity, questions will pop up like
"How do I modify the collection Y?" because they assume
getCollectionY() returns an unmodifiable collection.

Anyway, Restlet does not follow its own convention "modifiable
collections" consequently. I.e. Form has addParameter(String, String),
ConnectorCall has add(Request|Response)Header(String, String) etc. IMO
mixing up the styles spreads even more confusion.

Don't get me wrong, I am not trying to bash Restlet, I like it and I
know it's in beta stage. :)

[...]
> I hope I'll be able to change your mind ;-)

Time will tell... ;)

Best regards,
Lars
-- 
http://www.semagia.com

Re: Proposal for Call

[Lars Heuer]

Hi Jerome,

[...]
> This map of attributes is mainly for the Restlet application developer, so
> we don't need to check any constraint on allowed names/values. 

> If really needed, an implementation of the Call interface could always
> provide a custom implementation of Map interface instead of
> TreeMap. IMHO, we don't need to touch this.

Hmm.. ok.

Just for the record: I am (in contrast to some Restlet delelopers here
;) ) not a big fan of modifiable lists (and collections in general).
IMO it is untypical to return collections that are modifiable. And it
leaves room for failures and gives control away.
Actually, the modifiable collections everywhere is something I don't
like about Restlet.

Best regards,
Lars
-- 
http://www.semagia.com

Re: Fwd: Proposal for Call

[Lars Heuer]

Hi,

[...]
>void putAttribute(String, Object);
>void removeAttribute(String);
>Object getAttribute(String);
[...]

getAttribute(String) can be omitted since the user can still call

getAttributes().get(String)

Best regards,
Lars
-- 
http://www.semagia.com

Fwd: Proposal for Call

[Lars Heuer]

Didn't make it into the list

===8<==Original message text===

Hi,

Another proposal / suggestion:
Add

   void putAttribute(String, Object);
   void removeAttribute(String);
   Object getAttribute(String);

to the Call interface.

IMO returning a modifiable Map is not a good idea since the developer
has no control over allowed names / values.
Adding the mentioned methods make it possible for checking allowed
values, for null etc. In addition the developer should expect an
unmodifiable Map from the getAttributes() method.

I don't think that adding these methods will pollute the Call
interface, but enhance the possibilities.

Best regards,
Lars
-- 
http://www.semagia.com

===8<===End of original message text===

Re: Proposal for ConnectorCall

[Lars Heuer]

Hi again,

[...]
> it would be nice to add two methods to the ConnectorCall

> setRequestHeader(String name, String value);
> setResponseHeader(String name, String value);
[...]

Additionally I like to remove the

List getRequestHeaders();
List getResponseHeaders();

methods.
Is anybody using them?

They only complicate the implementation of an ConnectorCall because
the implementator has to convert the headers from the Restlet model to
the native model and back. If we remove the
get(Request|Response)Headers methods an implementator can directly
modify the native model in the

   add(Request|Response)Header

method.

If someone uses the get(Request|Response)Headers methods to get an
overview which headers are set I propose to replace the methods with

   List get(Request|Response)HeaderNames();

Such a method is easier to implement than the List
equivalents and does not require the Restlet model / native model
translations.

Best regards,
Lars
-- 
http://www.semagia.com

Proposal for ConnectorCall

[Lars Heuer]

Hi all,

Me, myself and I ;) think that it would be nice to add two methods to
the ConnectorCall

setRequestHeader(String name, String value);
setResponseHeader(String name, String value);

Sideeffect: If an existing name/value pair exists it is overridden by
the specified name/value pair.

The user can archive something similiar with the currently provided
methods but I think it would simplify things if we add the above
mentioned methods.

Best regards,
Lars
-- 
http://www.semagia.com

Re: Form constructor

[Lars Heuer]

Hi John,

> Hmm... But there can be query parameters *and* form input on a post (or put).

Interessting argument. It seems that this use case is not handled by
the current Form class at all. But it is valid argument against adding
my suggested constructor. :)

Best regards,
Lars
-- 
http://www.semagia.com

Form constructor

[Lars Heuer]

Hi Jérôme & co.,

For one project I am using my own class that parses the parameters for
me. It shares some similarities with the Form class. While working
with my class I had the idea that the Form class should have another
constructor that takes a Call as argument.

I.e.:
 public Form(Call call) {
if (call.getMethod().equals(Methods.POST)) {
   Factory.getInstance().parsePost(this, call.getInput());
}
else if (call.getMethod().equals(Methods.GET) {
 Factory.getInstance().parseQuery(this,
  call.getQuery());
}
else {
 throw new UnsupportedOperationException("...");
}
 }

In the restlet instances the user can always call

   Form form = new Form(call);

regardless of the concrete HTTP method.

Best regards,
Lars
-- 
http://semagia.com

Re: Compiling with JDK1.4

[Lars Heuer]

Hi Jody,

> Next question for the day! The program I am writing will not run under 1.4
> environments due to it being compiled on my box under 1.5. I reinstalled 1.4
[...]

I've successfully created a JDK 1.4 Restlet distribution with
Retroweaver.
I hope that the necessary changes will become part of the
build.xml in the SVN.
With Retroweaver you can still develop with Java 1.5 using Iterable,
Enum, Generics etc. and then "enhance" the compiled classes with
Retroweaver spefific replacements. The necessary runtime lib (for Java
1.4) is very small (abt. 7kB).

Best regards,
Lars
-- 
http://semagia.com

Re: Generics at Restlet

[Lars Heuer]

Hi Jerome,

[...]
>  4) Use a base *Restlet class in your application that will do the cast once

That's the way I've solved it with the current Restlet release.

[...]
> What do you think? 

I think I'll sleep a night over that issue or even better try
something out. I'll come back later on this issue.

Thanks for your work. :)

Best regards,
Lars
-- 
http://semagia.com

Re: Generics at Restlet

[Lars Heuer]

Hi,

[...]
> public abstract class AbstractRestlet
> implements Restlet {

[...]
> Does this solution help? Or do several classes depend on
> AbstractRestlet?

Even if a bunch of classes depend on AbstractRestlet it should work.
As long as they are just using the handle(Call call) method they are
not forced to cast or something like that.
Only if a derived class uses the comfortable handle(Get|Put|..)
methods they should use a type.
As long as I am not missing something important here, I think that
everything else should work as before.

Best regards,
Lars
-- 
http://semagia.com

Re: Generics at Restlet

[Lars Heuer]

Hi Jerome,

[...]
> One issue I'm having is that the Restlet interface is implemented by many
> classes (connectors, components, etc.). The changes suggested trigger a
> cascade of other changes in order to prevent warnings like:

> "Type safety: The method handle(Call) belongs to the raw type Restlet.
> References to generic type 
>  Restlet should be parameterized "

Okay, another try. I think the Restlet is too much.

How about this:

// Leave Restlet as it is
public interface Restlet {
   public void handle(Call call);

   // ...
}


public abstract class AbstractRestlet
implements Restlet {

  @SuppressWarnings("unchecked")
   public void handle(Call call) {
  if (call.getMethod.equals(...)) {
 handleGet((T) call);
  }
  // ...
   }

   public void handleGet(T call) {
  // ...
   }
}

Does this solution help? Or do several classes depend on
AbstractRestlet?

Best regards,
Lars
-- 
http://semagia.com

Generics at Restlet

[Lars Heuer]

Hi Jerome and all,

Background:
I've two implementations where I need a custom Call. That is not
a problem since there is the WrapperCall that makes it easy to
implement. But at the Restlet#handle(Call call) method I've to do the
cast to my Call implementation.

Solution:

 public interface Restlet {
public void handle(T call);

// 
 }

 public abstract AbstractRestlet
 implements Restlet {

public void handleGet(T call) {
   // ...
}

// ...
}


Now I can use MyCall and Java will do the casts for me. :)

What do you think?

BTW: http://www.restlet.org/ does not respond (time out).

Best regards,
Lars
-- 
http://semagia.com

CompressChainlet issue

[Lars Heuer]

Hi Jerome,

I discovered that the CompressChainlet compresses the output even if
the accepted-encoding header is empty. Actually I've not tested this
scenario at the beginning of this week.
I am not sure who is responsible for the failure (the compress
chainlet or the preferences).
I'll investigate it further if I find some time.

I seems that more JUnit tests would be a good idea. Are all test cases
in the SVN? Or do you have more?

Best regards,
Lars
-- 
http://semagia.com

Re: Fluent API and StructureBuilder

[Lars Heuer]

Hi Jerome,

[...]
>> What I do not understand: How does the toMaplet() method help for code
>> completion? If you return a specialized Maplet here (that keeps a
>> reference to the builder) the code assistent would assume that only
>> "attach(String, Restlet)" and "attach(String, Class)" are allowed.
> The toMaplet() would return a MapletBuilder instance actually :-) therefore
> the code assistant will be able to propose the correct methods.

Ah! :) Cool! :)

[...]
>> The builder can to the
>> cast transparently (see StructureBuilder). I like the DWIM (Do What I
>> Mean) approach more than the DWIS (Do What I Say) approach. :)
> I'm indeed trying to take advantage of compile-time error detection and code
> completion here.
> The only drawback is the need to specify casting when doing up() or root()
> calls. 

Fine, fine. :) It seems to be a good mix-in. Now I understand it
better. The user can either use the generic attach* methods and the
builder will to the cast transparently or the user can take the
advantage of specialized builders and will be assisted. :)

Best regards,
Lars
-- 
http://semagia.com

Re: Fluent API and StructureBuilder

[Lars Heuer]

Hi Yuri,

> Interesting...

> The approach I was taking was to use Java itself as the stack by using a
> "new XXX()" to create/"push" a new entry to the "stack".
>  .attach("/a", new Maplet()
> .attach("/b", new Maplet())
> .attach("/c", 
> new Restlet()
> )
> )
> )

Yep, I thought about the same approach but it has the disadvantage
that you cannot easily comment out a section and you have to keep
track about the braces (or the IDE does it).
I am very happy that I could do the following:

  builder
 .attach(SomeChainlet())
   .attach(Someother)

And if I don't need a chainlet or maplet I can easily comment it out
without breaking the flow.
   
  builder
// .attach(SomeChainlet())
   .attach(Someother)


   
[...]
> Each ")" above would correspond to the .back(1) in Lars solution, I
> guess. The generic back(?) seems more flexible and I would interested in
> knowing what kind of scenarios does it enable.

I use it just to save some .back().back() chains if I've to jump to a
higher level. It is build in because I am lazy. ;)

Best regards,
Lars
-- 
http://semagia.com

Re: Fluent API and StructureBuilder

[Lars Heuer]

Hi Jerome,

[...]
> The attach*() methods will move the focus to the attached/created node.
> Other methods will keep the focus on the current node.
> The up() and root() will change the focus in the tree of builder nodes.
> The to*() methods will allow the cast the builder to the best type (maybe
> upMaplet() and rootComponent() are even better?).

As long as the generic attach methods are also provided I like the
proposal. :)

What I do not understand: How does the toMaplet() method help for code
completion? If you return a specialized Maplet here (that keeps a
reference to the builder) the code assistent would assume that only
"attach(String, Restlet)" and "attach(String, Class)" are allowed.

I the "to*" methods are not for code completion I'd leave them out.
Why should the user be forced to do the cast? The builder can to the
cast transparently (see StructureBuilder). I like the DWIM (Do What I
Mean) approach more than the DWIS (Do What I Say) approach. :)

Or do I miss something here?


Best regards,
Lars
-- 
http://semagia.com