resteasy-developers — The main list for RESTEasy developers to discuss project development

Re: [Resteasy-developers] [JBoss JIRA] Commented: (RESTEASY-81) @Context member variables in subresources are not injected (null)

[Bill B. <bb...@re...>]

Make it so, should be easy.

Martin Algesten wrote:
> But thinking about this, it makes me question this part of the spec.
> 
> "An implementation is only required to set the annotated field and  
> bean property values of instances created by the implementation  
> runtime. Objects returned by sub-resource locators (see section 3.4.1)  
> are expected to be initialized by their creator and field and bean  
> properties are not modified by the implementation runtime."
> 
> Why does the spec use an injection style way of initialisation in the  
> first place? I guess because it's kinda new, cool, and less to write.
> 
> public class OldStyleResource implements UriInfoAware {
> 
>   private UriInfo uriInfo;
> 
>   // Called by framework to give us uriInfo.
>   public void setUriInfo( UriInfo uriInfo ) {
>     this.uriInfo = uriInfo;
>   }
> 
>   public SubResource getSubResrouce() {...}
> 
> }
> 
> vs
> 
> public class ModernStyleResource {
> 
>   @Context
>   private UriInfo uriInfo;
> 
> }
> 
> But why doesn't the same logic apply to subresoures? The fact that  
> they've been instantiated by something else that in theory could pass  
> all the wanted references through doesn't seem to be adequate, what if  
> there's a whole heap of stuff to pass through? Doesn't the same  
> neatness logic apply?... I'm not saying that we should traverse the  
> whole object graph of the subresource and inject everywhere, just the  
> top level. if we're trying to do nice new ways of initialising why not  
> do it across the board?
> 
> M
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] [JBoss JIRA] Commented: (RESTEASY-81) @Context member variables in subresources are not injected (null)

[Martin A. <sp...@ma...>]

But thinking about this, it makes me question this part of the spec.

"An implementation is only required to set the annotated field and  
bean property values of instances created by the implementation  
runtime. Objects returned by sub-resource locators (see section 3.4.1)  
are expected to be initialized by their creator and field and bean  
properties are not modified by the implementation runtime."

Why does the spec use an injection style way of initialisation in the  
first place? I guess because it's kinda new, cool, and less to write.

public class OldStyleResource implements UriInfoAware {

  private UriInfo uriInfo;

  // Called by framework to give us uriInfo.
  public void setUriInfo( UriInfo uriInfo ) {
    this.uriInfo = uriInfo;
  }

  public SubResource getSubResrouce() {...}

}

vs

public class ModernStyleResource {

  @Context
  private UriInfo uriInfo;

}

But why doesn't the same logic apply to subresoures? The fact that  
they've been instantiated by something else that in theory could pass  
all the wanted references through doesn't seem to be adequate, what if  
there's a whole heap of stuff to pass through? Doesn't the same  
neatness logic apply?... I'm not saying that we should traverse the  
whole object graph of the subresource and inject everywhere, just the  
top level. if we're trying to do nice new ways of initialising why not  
do it across the board?

M

[Resteasy-developers] builder pattern madness?

[Martin A. <sp...@ma...>]

<gripe>

Is it just me not understanding the api, am I coding bad or is jaxrs a  
bit too happy about the builder patterns ?

It upsets my zen like coder state when I end up with nested builders.  
I'm quite sensitive that way:

   return  
Response.created(uriInfo.getRequestUriBuilder().path("{companyId}")
        .build(company.getCompanyId())).build();

Can I simplify this somehow - am I just being daft?

I think the main problem is that I need two builders inside each  
other, and it makes me wonder what the builders actually do for me.  
Sure I could break out the URI on to a separate line, but still.

How about throwing out the builders out and use something so dull and  
old fashioned as a constructor (*gasp*). Here's an API change proposal:

   return new Response(Response.Status.CREATED,
                       uriInfo.path("{companyId}",  
company.getCompanyId()));

</gripe>

Re: [Resteasy-developers] ResourceFactory

[Bill B. <bb...@re...>]

Ryan J. McDonough wrote:
> 
> On Jul 15, 2008, at 9:22 AM, Bill Burke wrote:
> 
>> I don't see why you need a change to Resteasy to do this when the 
>> JAX-RS spec allows you to return any arbitrary object from a 
>> subresource locator.  For example:
>>
>> @Path("/")
>> public class CustomerDatabase {
>>
>>   @Path("customers/{id}")
>>   public Object getCustomer() {
>>
>>       Customer cust = jpa.find(...);
>>       return cust;
>>   }
>> }
>>
>> public class Customer {
>>
>>   @GET
>>   public String get() {...}
>>
>>   @Path("/address")
>>   public String getAddress() {...}
>> }
>>
>> So
>>
>> GET /customers/1
>> GET /customer/1/address
>>
>> Would eventually route to Customer.
> 
> I've tried that, and it does not work. You can certainly get the Contact 
> entity, but any @Path annotations on the entity are not processed. We 
> don't have any unit tests which cover this sort of behavior, so it maybe 
> that we don't support this yet? (Or support this with EJB's?) I was also 
> taking a look at the Jersey "Bookmark" example app, and they have 
> created separate resource classes for child entities. Ideally, I don't 
> want to do this. You've got similar patterns being repeated and we've 
> got a lot of meta data on the entity that we can use. 
> 

You'll have to show me an example because I'm not sure exactly what you 
are doing here.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] ResourceFactory

[Martin A. <sp...@ma...>]

On 16 Jul 2008, at 14:28, Ryan J. McDonough wrote:

> My only problem with the resource-per-entity approach is that, for the
> most part, you're repeating very similar activities for different
> entities. To me, that doesn't feel right. Hibernate and JPA abstract
> the persistence details enough that it should be possible to build a
> layer around


True very true, the wrapper classes for my 10 or so entities look  
pretty much exactly the same. I've done what I can with generics - but  
it's still code duplication.

M

Re: [Resteasy-developers] ResourceFactory

[Ryan J. M. <ry...@da...>]

On Jul 16, 2008, at 6:06 AM, Christian Bauer wrote:

>
> On Jul 16, 2008, at 11:59 , Martin Algesten wrote:
>
>> I think it feels wrong to receive a Customer object in set() which
>> is supposed to be myself (sure I can copy the values over from one
>> to the other). Pulling the @PUT method up to the CustomerDatabase
>> class is a solution, but then I don't keep my operations together,
>> so that feels wrong too. In my own test implementations I've ended
>> up creating a wrapper resource around every entity which feels right
>> since I get a clean API separation from my domain model.

My only problem with the resource-per-entity approach is that, for the  
most part, you're repeating very similar activities for different  
entities. To me, that doesn't feel right. Hibernate and JPA abstract  
the persistence details enough that it should be possible to build a  
layer around

> Agree on that, I think it's the job of a CRUD framework like what Seam
> can offer. Even for simple applications I would not put resource
> annotations into my domain model. Or at least only annotations but no
> special methods.

+1. I absolutely don't want special methods, but something more  
transparent.

>
> One of the points I brought up is RESTEasy integration with the Seam
> built-in controllers/homes/queries:
>
> http://docs.jboss.com/seam/2.1.0.A1/reference/en/html/framework.html

This is probably closer to what I'm looking for, but I haven't taken a  
deep enough look into it. For now, I'll put this to rest and finish  
the example ;)

Ryan-

Re: [Resteasy-developers] ResourceFactory

[Christian B. <chr...@gm...>]

On Jul 16, 2008, at 11:59 , Martin Algesten wrote:

> I think it feels wrong to receive a Customer object in set() which  
> is supposed to be myself (sure I can copy the values over from one  
> to the other). Pulling the @PUT method up to the CustomerDatabase  
> class is a solution, but then I don't keep my operations together,  
> so that feels wrong too. In my own test implementations I've ended  
> up creating a wrapper resource around every entity which feels right  
> since I get a clean API separation from my domain model.

Agree on that, I think it's the job of a CRUD framework like what Seam  
can offer. Even for simple applications I would not put resource  
annotations into my domain model. Or at least only annotations but no  
special methods.

One of the points I brought up is RESTEasy integration with the Seam  
built-in controllers/homes/queries:

http://docs.jboss.com/seam/2.1.0.A1/reference/en/html/framework.html

Re: [Resteasy-developers] ResourceFactory

[Martin A. <sp...@ma...>]

On 16 Jul 2008, at 03:04, Ryan J. McDonough wrote:

>
> I've tried that, and it does not work. You can certainly get the  
> Contact entity, but any @Path annotations on the entity are not  
> processed. We don't have any unit tests which cover this sort of  
> behavior, so it maybe that we don't support this yet? (Or support  
> this with EJB's?) I was also taking a look at the Jersey "Bookmark"  
> example app, and they have created separate resource classes for  
> child entities. Ideally, I don't want to do this. You've got similar  
> patterns being repeated and we've got a lot of meta data on the  
> entity that we can use.
>

I don't see why @Path annotations wouldn't be processed, surely this  
is no different to a subresource subresource? Just to make sure that  
works I added a new test that does a nested subresource locator:

resteasy-jaxrs/src/test/java/org/jboss/resteasy/test/smoke/ 
TestSmoke.java

Whether or not it should be done I don't know - I'm a bit sceptical to  
mixing in the API into my domain model. Consider Bill's example with  
the tweak that we're working on object serialization using Yaml and  
add a @PUT to update:

@Path("/")
public class CustomerDatabase {

   @Path("customers/{id}")
   public Object getCustomer() {

       Customer cust = jpa.find(...);
       return cust;
   }
}

public class Customer {

   @GET
   @ProduceMime("text/x-yaml")
   public Customer get() {
     return this;
   }

   @PUT
   @ConsumeMime("text/x-yaml")
   public void set(Customer customer) {
     // this is my issue - what is "this", the received object or  
myself?
   }

   @Path("/address")
   public Address getAddress() {...}

}


I think it feels wrong to receive a Customer object in set() which is  
supposed to be myself (sure I can copy the values over from one to the  
other). Pulling the @PUT method up to the CustomerDatabase class is a  
solution, but then I don't keep my operations together, so that feels  
wrong too. In my own test implementations I've ended up creating a  
wrapper resource around every entity which feels right since I get a  
clean API separation from my domain model.

M

Re: [Resteasy-developers] ResourceFactory

[Ryan J. M. <ry...@da...>]

On Jul 15, 2008, at 9:22 AM, Bill Burke wrote:

> I don't see why you need a change to Resteasy to do this when the  
> JAX-RS spec allows you to return any arbitrary object from a  
> subresource locator.  For example:
>
> @Path("/")
> public class CustomerDatabase {
>
>   @Path("customers/{id}")
>   public Object getCustomer() {
>
>       Customer cust = jpa.find(...);
>       return cust;
>   }
> }
>
> public class Customer {
>
>   @GET
>   public String get() {...}
>
>   @Path("/address")
>   public String getAddress() {...}
> }
>
> So
>
> GET /customers/1
> GET /customer/1/address
>
> Would eventually route to Customer.

I've tried that, and it does not work. You can certainly get the  
Contact entity, but any @Path annotations on the entity are not  
processed. We don't have any unit tests which cover this sort of  
behavior, so it maybe that we don't support this yet? (Or support this  
with EJB's?) I was also taking a look at the Jersey "Bookmark" example  
app, and they have created separate resource classes for child  
entities. Ideally, I don't want to do this. You've got similar  
patterns being repeated and we've got a lot of meta data on the entity  
that we can use.

>
> ResourceFactory is used to instantiate an endpoint and also to  
> preprocess the class file looking for annotations and create Path  
> bindings in the registry.  I don't understand what you want to use  
> it for or the change you want.

Understood, and most likely ResourceFactory isn't the best choice.  
what I am looking at is take the case where a Contact has a one-to- 
many association with a EmailAddress entity. If you just annotate the  
entity as such:

@Entity
@Table(name = "contact")
public class Contact
{
    ...

    @GET
    @Path("/emailAddresses")
    public Set<EmailAddress> getEmailAddresses()
    {
       return emailAddresses;
    }

    @GET
    @Path("/emailAddresses/{emailAddressId}")
    public EmailAddress  
getEmailAddressById(@PathParam("emailAddressId") Long id) {
       for(EmailAddress emailAddress : this.emailAddresses) {
          if(id.equals(emailAddress.getId())) {
             return emailAddress;
          }
       }
       return null;
    }...

It'd work, but not the most efficient way of doing things. I'm  
probably thinking more in terms of Christian's 4th point on Seam  
integration and potentially free-associating a bit as well ;). But  
another thing to consider is that you may not always get back a  
concrete class as it could be a proxy. In which case, the proxy won't  
contain the annotation data and therefore won't work.

Ryan-


>
> Ryan J. McDonough wrote:
>> I've been working on an example (most of which I have committed)  
>> which uses EJB3 + JPA + Seam. The contact entity is an object graph  
>> with multiple child elements. Ideally what I'd like to be able to  
>> do is to have the Contact entity that is returned become a sub- 
>> resource. However, we don't have a ResourceFactory that can handle  
>> that. So I was thinking about an EntityResourceFactory, but I see  
>> some challenges:
>>    * Introducing JPA (or Hibernate) would create another dependency
>>    * The ResourceMethodRegistry does not dynamically load
>>      ResourceFactory instances. For example, if we could have a  
>> another
>>      project load a custom ResourceFactory, how is it located and how
>>      does it get utilized?
>>    * There doesn't appear to be a clear way of
>>       having ResourceMethodRegistry choose a particular  
>> ResourceFactory
>>      instance
>> I don't know if I'm missing anything, but I see this as an issue  
>> and something that the Seam folks might run into some issues?
>> Ryan-
>> ------------------------------------------------------------------------
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's  
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win  
>> great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in  
>> the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ------------------------------------------------------------------------
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
>
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com

Re: [Resteasy-developers] ResourceFactory

[Bill B. <bb...@re...>]

I don't see why you need a change to Resteasy to do this when the JAX-RS 
spec allows you to return any arbitrary object from a subresource 
locator.  For example:

@Path("/")
public class CustomerDatabase {

    @Path("customers/{id}")
    public Object getCustomer() {

        Customer cust = jpa.find(...);
        return cust;
    }
}

public class Customer {

    @GET
    public String get() {...}

    @Path("/address")
    public String getAddress() {...}
}

So

GET /customers/1
GET /customer/1/address

Would eventually route to Customer.

ResourceFactory is used to instantiate an endpoint and also to 
preprocess the class file looking for annotations and create Path 
bindings in the registry.  I don't understand what you want to use it 
for or the change you want.


Ryan J. McDonough wrote:
> I've been working on an example (most of which I have committed) which 
> uses EJB3 + JPA + Seam. The contact entity is an object graph with 
> multiple child elements. Ideally what I'd like to be able to do is to 
> have the Contact entity that is returned become a sub-resource. However, 
> we don't have a ResourceFactory that can handle that. So I was thinking 
> about an EntityResourceFactory, but I see some challenges:
> 
>     * Introducing JPA (or Hibernate) would create another dependency
>     * The ResourceMethodRegistry does not dynamically load
>       ResourceFactory instances. For example, if we could have a another
>       project load a custom ResourceFactory, how is it located and how
>       does it get utilized?
>     * There doesn't appear to be a clear way of
>        having ResourceMethodRegistry choose a particular ResourceFactory
>       instance
> 
> 
> I don't know if I'm missing anything, but I see this as an issue and 
> something that the Seam folks might run into some issues?
> 
> Ryan-
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Resteasy-developers] ResourceFactory

[Ryan J. M. <ry...@da...>]

I've been working on an example (most of which I have committed) which  
uses EJB3 + JPA + Seam. The contact entity is an object graph with  
multiple child elements. Ideally what I'd like to be able to do is to  
have the Contact entity that is returned become a sub-resource.  
However, we don't have a ResourceFactory that can handle that. So I  
was thinking about an EntityResourceFactory, but I see some challenges:

Introducing JPA (or Hibernate) would create another dependency
The ResourceMethodRegistry does not dynamically load ResourceFactory  
instances. For example, if we could have a another project load a  
custom ResourceFactory, how is it located and how does it get utilized?
There doesn't appear to be a clear way of  having  
ResourceMethodRegistry choose a particular ResourceFactory instance

I don't know if I'm missing anything, but I see this as an issue and  
something that the Seam folks might run into some issues?

Ryan-

Re: [Resteasy-developers] Seam and RESTEasy integration

[Bill B. <bb...@re...>]

Christian Bauer wrote:
> On Jul 14, 2008, at 14:47 , Bill Burke wrote:
> 
>> The Dispatcher is driven off of UriInfo.  So, you need to build your  
>> own since it is specific to Seam.  Look in HttpServletDispatcher to  
>> see how it builds it, its pretty easy and the methods are already  
>> there.
> 
> OK, I'll try that.
> 
>> FYI, you should be working off of trunk as we've have recently  
>> changed packaged names (to org.jboss.resteasy) and are refactoring  
>> continuously.  You will also want to take advantage of our  
>> interceptor model when we get it in.
> 
> Well let's keep integration for releases, we can't refactor every day  
> to follow your nightly snapshots. Just open a JIRA issue on Seam when  
> you have a new release and you think that the integration needs to be  
> updated.
> 
> We most likely won't need your interceptors and I'm not sure you  
> should even have them in RESTEasy. KISS and if people want a resource  
> programming model that supports interception they should use Seam (or  
> EJB3, or Spring, or whatever other container).
> 

I originally thought this myself, but there are a decent amount of use 
cases that require them.

I'm doing asynch stuff as well as Cache-Control annotations and 
server-side caching.  All of which require interception at certain (and 
different) points of request processing that Seam can't provide for me.

Asynch requires interception before request unmarshalling. Server-side 
caching requires interception before and after marshalling requests. 
Cache-Control annotations require knowledge of the HTTP method being 
invoked.  Also, users may want to re-use JAX-RS annotations within their 
interceptors, for instance, for their own security protocol.



-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] Seam and RESTEasy integration

[Christian B. <chr...@gm...>]

On Jul 14, 2008, at 14:47 , Bill Burke wrote:

> The Dispatcher is driven off of UriInfo.  So, you need to build your  
> own since it is specific to Seam.  Look in HttpServletDispatcher to  
> see how it builds it, its pretty easy and the methods are already  
> there.

OK, I'll try that.

> FYI, you should be working off of trunk as we've have recently  
> changed packaged names (to org.jboss.resteasy) and are refactoring  
> continuously.  You will also want to take advantage of our  
> interceptor model when we get it in.

Well let's keep integration for releases, we can't refactor every day  
to follow your nightly snapshots. Just open a JIRA issue on Seam when  
you have a new release and you think that the integration needs to be  
updated.

We most likely won't need your interceptors and I'm not sure you  
should even have them in RESTEasy. KISS and if people want a resource  
programming model that supports interception they should use Seam (or  
EJB3, or Spring, or whatever other container).

Re: [Resteasy-developers] Seam and RESTEasy integration

[Bill B. <bb...@re...>]

Christian Bauer wrote:
> On Jul 13, 2008, at 19:36 , Ryan J. McDonough wrote:
> 
>>> 2. You can put @Name on your @Provider class. It has to be
>>> ScopeType.APPLICATION or ScopeType.STATELESS. For the STATELESS
>>> providers I need an extension to RESTEasy. I need to tell RESTEasy  
>>> how
>>> it should look up an instance of a Provider from Seam at runtime.
>>> Right now you guys only support setProvider(clazz) and
>>> setProviderInstance(o) at bootstrap. I need
>>> setProviderLookup(anImplementationOfALookupInterface) or something
>>> similar.
>> Can you open a JIRA issue on that and assign it me?
> 
> http://jira.jboss.com/jira/browse/RESTEASY-79
> 
> I need one other thing, maybe you have that as an API already:
> 
> When a request hits the SeamResourceServlet, the mapped path  
> (configurable in Seam though) is:
> 
> /seam/resource/rest/<whatever>
> 
> Unfortunately, that means you have to use this in your resources:
> 
> @Path("/seam/resource/rest/catalog/item/123")
> 
> It would be much nicer if users could skip the /seam/resource/rest  
> part of the path. I could use HttpServletRequestWrapper before passing  
> the call to dispatcher.invoke() and override all methods that return  
> the path. It would be much better if we could tell RESTEasy to map  
> @Path with a customizable base.
> 

The Dispatcher is driven off of UriInfo.  So, you need to build your own 
since it is specific to Seam.  Look in HttpServletDispatcher to see how 
it builds it, its pretty easy and the methods are already there.

FYI, you should be working off of trunk as we've have recently changed 
packaged names (to org.jboss.resteasy) and are refactoring continuously. 
  You will also want to take advantage of our interceptor model when we 
get it in.

Do you want SVN access? Just send me your sf.net id privately and I'll 
give it to you.


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] yaml support added

[Bill B. <bb...@re...>]

You rock!  Thanks!

Documentation?

Martin Algesten wrote:
> 
> New provider added YamlProvider - it adds support for mime types 
> text/yaml, text/x-yaml and application/x-yaml. There doesn't seem to be 
> a definite mime type that should be used, but yaml.org uses text/x-yaml 
> - the others I picked up from other sites.
> 
> This plugin only gets activated if we detect the library jyaml 
> (org.ho.yaml.Yaml)
> 
> M
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

[Resteasy-developers] yaml support added

[Martin A. <sp...@ma...>]

New provider added YamlProvider - it adds support for mime types text/ 
yaml, text/x-yaml and application/x-yaml. There doesn't seem to be a  
definite mime type that should be used, but yaml.org uses text/x-yaml  
- the others I picked up from other sites.

This plugin only gets activated if we detect the library jyaml  
(org.ho.yaml.Yaml)

M

Re: [Resteasy-developers] Seam and RESTEasy integration

[Christian B. <chr...@gm...>]

On Jul 13, 2008, at 19:36 , Ryan J. McDonough wrote:

>> 2. You can put @Name on your @Provider class. It has to be
>> ScopeType.APPLICATION or ScopeType.STATELESS. For the STATELESS
>> providers I need an extension to RESTEasy. I need to tell RESTEasy  
>> how
>> it should look up an instance of a Provider from Seam at runtime.
>> Right now you guys only support setProvider(clazz) and
>> setProviderInstance(o) at bootstrap. I need
>> setProviderLookup(anImplementationOfALookupInterface) or something
>> similar.
>
> Can you open a JIRA issue on that and assign it me?

http://jira.jboss.com/jira/browse/RESTEASY-79

I need one other thing, maybe you have that as an API already:

When a request hits the SeamResourceServlet, the mapped path  
(configurable in Seam though) is:

/seam/resource/rest/<whatever>

Unfortunately, that means you have to use this in your resources:

@Path("/seam/resource/rest/catalog/item/123")

It would be much nicer if users could skip the /seam/resource/rest  
part of the path. I could use HttpServletRequestWrapper before passing  
the call to dispatcher.invoke() and override all methods that return  
the path. It would be much better if we could tell RESTEasy to map  
@Path with a customizable base.

[Resteasy-developers] release plugin distribution

[Martin A. <sp...@ma...>]

The maven release plugin does the following:

1) make svn tag
2) checks out the tag and builds jar/war/etc from the checkout (runs  
tests)
3) build javadoc and source jars
4) uploads the lot to the distribution point

The last step requires a <distributionManagement> section in the pom  
with details of where to upload to. Typically this is done using scp  
or ftp. Can we do that when releasing resteasy? Who and how uploads  
the release currently?

If we can't I can set it to file:///tmp/resteasy-release to get the  
files that needs to be uploaded manually somewhere else.

M

Re: [Resteasy-developers] Seam and RESTEasy integration

[Bill B. <bb...@re...>]

Ryan J. McDonough wrote:
> On Jul 13, 2008, at 9:44 AM, Christian Bauer wrote:
> 
>> On Jul 13, 2008, at 15:04 , Ryan J. McDonough wrote:
>>
>>> Cool! I'm very interested as to how this is being implemented. Also,
>>> is this integration going to be part of Seam, RESTEasy, or as a sub-
>>> module of RESTEasy?
>> It's going to be part of Seam, planned is a seam-resteasy.jar that you
>> simply drop into your libs (in addition to any resteasy JARs). That's
>> how other frameworks and libs are integrated with Seam today. So I
>> guess we need a RESTEasy dependency in the Seam POMs to compile it
>> (Pete?).
>>
>> Same for configuration: Any @Provider and @Path classes are
>> automatically discovered during Seam application startup when the
>> RESTEasy libs are in the classpath. If you want to customize settings,
>> you override a built-in Seam component in a Seam configuration file
>> (many deployment options here, this is just one of them):
>>
>>     <component name="resteasyApplicationConfig" precedence="20"
>>
>> class="org.jboss.seam.resteasy.ResteasyApplicationConfig">
>>         <property name="scanForResources">
>>             <value>false</value>
>>         </property>
>>         <property name="resourceClassNames">
>>             <value>my.CatalogResource</value>
>>             <value>my.ItemResource</value>
>>         </property>
>>         ... and so on ...
>>     </component>
>>
>> This Seam component supports all the other settings you'd have in
>> web.xml with plain RESTEasy. You do not have to touch web.xml at all
>> with this approach. This Seam component is an extension of the JAX-RS
>> ApplicationConfig. (By the way, this should be an interface, not an
>> abstract class... tell the "experts".)
> 
> We'll take it up.  BTW, IIRC, this class may be renamed to  
> "Application" in a future release of the spec.
> 
>>
>> So that allows you to run your existing @Path and @Provider classes in
>> a Seam app without any additional configuration or changes. Drop the
>> classes into the classpath and Seam will serve HTTP requests through
>> its existing resource-loading architecture (the SeamResourceServlet is
>> enabled in all Seam applications). You can even hook into that request
>> processing and customize the dispatcher, wrap the request, and so on.
>> This is regular Seam stuff.
> 
> Nice!
> 
>>
>> Of course people want that integration not only for integrated
>> bootstrap and request processing but for the Seam programming model
>> when writing resources and providers:
>>
>> 1. You can put an @Name onto your @Path root resource class. This
>> enables Seam lifecycle management for the resource object. If it is
>> ScopeType.EVENT you basically get the JAX-RS default (POJO per
>> request) lifecycle. If it is ScopeType.APPLICATION, you get Singleton
>> lifecycle - you can also put @Synchronized on it. And so on for
>> ScopeType.SESSION and ScopeType.CONVERSATION. Once your resource
>> classes and providers are Seam components, you get full Seam
>> interception for @In(jection), and so on. E.g. you can use @In ItemDAO
>> on a field in your resource implementation.
>>
>> 2. You can put @Name on your @Provider class. It has to be
>> ScopeType.APPLICATION or ScopeType.STATELESS. For the STATELESS
>> providers I need an extension to RESTEasy. I need to tell RESTEasy how
>> it should look up an instance of a Provider from Seam at runtime.
>> Right now you guys only support setProvider(clazz) and
>> setProviderInstance(o) at bootstrap. I need
>> setProviderLookup(anImplementationOfALookupInterface) or something
>> similar.
> 
> Can you open a JIRA issue on that and assign it me?
> 

We should just rename ResourceFactory to ComponentFactory and use that SPI.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] Seam and RESTEasy integration

[Ryan J. M. <ry...@da...>]

On Jul 13, 2008, at 9:44 AM, Christian Bauer wrote:

>
> On Jul 13, 2008, at 15:04 , Ryan J. McDonough wrote:
>
>> Cool! I'm very interested as to how this is being implemented. Also,
>> is this integration going to be part of Seam, RESTEasy, or as a sub-
>> module of RESTEasy?
>
> It's going to be part of Seam, planned is a seam-resteasy.jar that you
> simply drop into your libs (in addition to any resteasy JARs). That's
> how other frameworks and libs are integrated with Seam today. So I
> guess we need a RESTEasy dependency in the Seam POMs to compile it
> (Pete?).
>
> Same for configuration: Any @Provider and @Path classes are
> automatically discovered during Seam application startup when the
> RESTEasy libs are in the classpath. If you want to customize settings,
> you override a built-in Seam component in a Seam configuration file
> (many deployment options here, this is just one of them):
>
>     <component name="resteasyApplicationConfig" precedence="20"
>
> class="org.jboss.seam.resteasy.ResteasyApplicationConfig">
>         <property name="scanForResources">
>             <value>false</value>
>         </property>
>         <property name="resourceClassNames">
>             <value>my.CatalogResource</value>
>             <value>my.ItemResource</value>
>         </property>
>         ... and so on ...
>     </component>
>
> This Seam component supports all the other settings you'd have in
> web.xml with plain RESTEasy. You do not have to touch web.xml at all
> with this approach. This Seam component is an extension of the JAX-RS
> ApplicationConfig. (By the way, this should be an interface, not an
> abstract class... tell the "experts".)

We'll take it up.  BTW, IIRC, this class may be renamed to  
"Application" in a future release of the spec.

>
>
> So that allows you to run your existing @Path and @Provider classes in
> a Seam app without any additional configuration or changes. Drop the
> classes into the classpath and Seam will serve HTTP requests through
> its existing resource-loading architecture (the SeamResourceServlet is
> enabled in all Seam applications). You can even hook into that request
> processing and customize the dispatcher, wrap the request, and so on.
> This is regular Seam stuff.

Nice!

>
>
> Of course people want that integration not only for integrated
> bootstrap and request processing but for the Seam programming model
> when writing resources and providers:
>
> 1. You can put an @Name onto your @Path root resource class. This
> enables Seam lifecycle management for the resource object. If it is
> ScopeType.EVENT you basically get the JAX-RS default (POJO per
> request) lifecycle. If it is ScopeType.APPLICATION, you get Singleton
> lifecycle - you can also put @Synchronized on it. And so on for
> ScopeType.SESSION and ScopeType.CONVERSATION. Once your resource
> classes and providers are Seam components, you get full Seam
> interception for @In(jection), and so on. E.g. you can use @In ItemDAO
> on a field in your resource implementation.
>
> 2. You can put @Name on your @Provider class. It has to be
> ScopeType.APPLICATION or ScopeType.STATELESS. For the STATELESS
> providers I need an extension to RESTEasy. I need to tell RESTEasy how
> it should look up an instance of a Provider from Seam at runtime.
> Right now you guys only support setProvider(clazz) and
> setProviderInstance(o) at bootstrap. I need
> setProviderLookup(anImplementationOfALookupInterface) or something
> similar.

Can you open a JIRA issue on that and assign it me?

>
>
> 3. We'll probably have a mechanism for transporting conversation
> identifiers in HTTP headers. However, I'm thinking that the way this
> should be implemented is with explicit automatically created resources
> that identify a particular conversation "workspace". See Bill's blog
> about JMS integration and how you'd model a transaction resource
> RESTfully. This is the same approach just for Seam conversations.
>
> 4. In a second stage we might want to integrate the Seam Application
> Framework. This is a basic CRUD framework, today used for quick
> development of JSF apps. We can use this as a foundation to expose
> entity lists and instances for CRUD/search directly from the database
> as HTTP resources. Similar to what Rails does out of the box, just
> nicer :)

I'm not sure what Rails does, but maybe I'm thinking along the same  
lines:

http://www.damnhandy.com/2008/07/02/resteasy-and-seam/

One thing I have been trying to look at is how to access nodes of a  
object graph without having to create a resource class for every child  
entity. Some of the Jersey examples do this and this would get  
cumbersome very quickly for a reasonably sized object graph.

>
>
> 5. I'm thinking about a special provider that can marshal an object
> graph into an XHTML (not just XML) response body and back from an
> XHTML request body to an object graph. This is about the
> "connectedness" of resources, see the O'Reilly REST book. As a
> developer I should write a Facelets XHTML template that defines the
> transformation. Imagine that you write it the same way you write a JSF
> template today, with bidirectional binding using EL expressions, from
> object getter/setter pair to XML attribute or element value. We can
> even have built-in Facelets "widgets" that render certain
> microformats. Seam has some machinery for this already but we might
> need an extra interceptor on resource methods to trigger the
> transformation. Or we use Seams pages.xml navigation rules ("when this
> resource method finishes, render this template"). Bill, I'm not sure
> we even need anything in RESTEasy for that, Seam intercepts these
> things anyway if there is a @Name on the class.
>
> Bootstrap, request servicing, and objectives 1 and 2 I already
> implemented locally. Let's get the provider lookup for 2 done and I
> can commit something into Seam trunk. We'll talk about 3, 4, and 5
> later.

Excellent!

>
>
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Resteasy-developers mailing list
> Res...@li...
> https://lists.sourceforge.net/lists/listinfo/resteasy-developers

Re: [Resteasy-developers] Seam integration

[Bill B. <bb...@re...>]

Its going to be part of Seam, from what Christian tells me.  I don't 
know the best place to keep the code though.  A stable SPI would allow 
us to keep the code in Seam, but if we start adding special 
configuration options, we may need to move the integration to Resteasy.


Ryan J. McDonough wrote:
> Cool! I'm very interested as to how this is being implemented. Also, is 
> this integration going to be part of Seam, RESTEasy, or as a sub-module 
> of RESTEasy?
> 
> Ryan-
> 
> On Jul 11, 2008, at 11:40 AM, Bill Burke wrote:
> 
>> FYI,  Christian Bauer is doing the Seam integration for Resteasy.  It is
>> mostly done.
>> -- 
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>> -------------------------------------------------------------------------
>> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
>> Studies have shown that voting for your favorite open source project,
>> along with a healthy diet, reduces your potential for chronic lameness
>> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
>> _______________________________________________
>> Resteasy-developers mailing list
>> Res...@li...
>> https://lists.sourceforge.net/lists/listinfo/resteasy-developers
> 

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com

Re: [Resteasy-developers] [seam-dev] Seam and RESTEasy integration

[Pete M. <pet...@jb...>]

On 13 Jul 2008, at 15:22, Christian Bauer wrote:

>
> On Jul 13, 2008, at 16:12 , Pete Muir wrote:
>
>>> 3. We'll probably have a mechanism for transporting conversation  
>>> identifiers in HTTP headers. However, I'm thinking that the way  
>>> this should be implemented is with explicit automatically created  
>>> resources that identify a particular conversation "workspace". See  
>>> Bill's blog about JMS integration and how you'd model a  
>>> transaction resource RESTfully. This is the same approach just for  
>>> Seam conversations.
>>
>> So this would be similar to named conversations? You have to  
>> explicitly define and use a conversation?
>
> Yes, it's the same concept. You do a first request to create the  
> conversation workspace under a resource path like /rest/conversation/ 
> editItem and then have sub-resources, like PUT a new representation  
> to /rest/conversation/editItem/123. Shouldn't be difficult, the  
> tricky part is the resource design.

Good :-)

> Bill summarized the problem and possible solutions here:
>
> http://bill.burkecentral.com/2008/06/16/resteasy-mom-an-exercise-in-jax-rs-restful-ws-design/
>
>> I assume you would build (4) on (5)?
>
> Well, I'm going to commit (1) and (2) and then let others have a  
> look :) I think Shane should be involved at some point because he  
> knows the current remoting/WS stuff best.
>
> _______________________________________________
> seam-dev mailing list
> sea...@li...
> https://lists.jboss.org/mailman/listinfo/seam-dev

--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete

Re: [Resteasy-developers] [seam-dev] Seam and RESTEasy integration

[Christian B. <chr...@gm...>]

On Jul 13, 2008, at 16:12 , Pete Muir wrote:

>> 3. We'll probably have a mechanism for transporting conversation  
>> identifiers in HTTP headers. However, I'm thinking that the way  
>> this should be implemented is with explicit automatically created  
>> resources that identify a particular conversation "workspace". See  
>> Bill's blog about JMS integration and how you'd model a transaction  
>> resource RESTfully. This is the same approach just for Seam  
>> conversations.
>
> So this would be similar to named conversations? You have to  
> explicitly define and use a conversation?

Yes, it's the same concept. You do a first request to create the  
conversation workspace under a resource path like /rest/conversation/ 
editItem and then have sub-resources, like PUT a new representation  
to /rest/conversation/editItem/123. Shouldn't be difficult, the tricky  
part is the resource design. Bill summarized the problem and possible  
solutions here:

http://bill.burkecentral.com/2008/06/16/resteasy-mom-an-exercise-in-jax-rs-restful-ws-design/

> I assume you would build (4) on (5)?

Well, I'm going to commit (1) and (2) and then let others have a  
look :) I think Shane should be involved at some point because he  
knows the current remoting/WS stuff best.

Re: [Resteasy-developers] [seam-dev] Seam and RESTEasy integration

[Pete M. <pet...@jb...>]

On 13 Jul 2008, at 14:44, Christian Bauer wrote:

>
> On Jul 13, 2008, at 15:04 , Ryan J. McDonough wrote:
>
>> Cool! I'm very interested as to how this is being implemented.  
>> Also, is this integration going to be part of Seam, RESTEasy, or as  
>> a sub-module of RESTEasy?
>
> It's going to be part of Seam, planned is a seam-resteasy.jar that  
> you simply drop into your libs (in addition to any resteasy JARs).  
> That's how other frameworks and libs are integrated with Seam today.  
> So I guess we need a RESTEasy dependency in the Seam POMs to compile  
> it (Pete?).

I will create a module in a bit.

> Same for configuration: Any @Provider and @Path classes are  
> automatically discovered during Seam application startup when the  
> RESTEasy libs are in the classpath. If you want to customize  
> settings, you override a built-in Seam component in a Seam  
> configuration file (many deployment options here, this is just one  
> of them):
>
>    <component name="resteasyApplicationConfig" precedence="20"
>                
> class="org.jboss.seam.resteasy.ResteasyApplicationConfig">
>        <property name="scanForResources">
>            <value>false</value>
>        </property>
>        <property name="resourceClassNames">
>            <value>my.CatalogResource</value>
>            <value>my.ItemResource</value>
>        </property>
>        ... and so on ...
>    </component>

We should have the namespaced version as well:

<reasteasy:reasteasy-application-config scan-for-resouces="false">
    <resteasy:resource-class-names>
       <value>my.CatalogResource</value>
       <value>my.ItemResource</value>
    </resteasy:resource-class-names>
</resteasy:resteasy-application-config>

(btw the precedence isn't necessary, components default to precedence  
40)

>
>
> This Seam component supports all the other settings you'd have in  
> web.xml with plain RESTEasy. You do not have to touch web.xml at all  
> with this approach. This Seam component is an extension of the JAX- 
> RS ApplicationConfig. (By the way, this should be an interface, not  
> an abstract class... tell the "experts".)
>
> So that allows you to run your existing @Path and @Provider classes  
> in a Seam app without any additional configuration or changes. Drop  
> the classes into the classpath and Seam will serve HTTP requests  
> through its existing resource-loading architecture (the  
> SeamResourceServlet is enabled in all Seam applications). You can  
> even hook into that request processing and customize the dispatcher,  
> wrap the request, and so on. This is regular Seam stuff.
>
> Of course people want that integration not only for integrated  
> bootstrap and request processing but for the Seam programming model  
> when writing resources and providers:
>
> 1. You can put an @Name onto your @Path root resource class. This  
> enables Seam lifecycle management for the resource object. If it is  
> ScopeType.EVENT you basically get the JAX-RS default (POJO per  
> request) lifecycle. If it is ScopeType.APPLICATION, you get  
> Singleton lifecycle - you can also put @Synchronized on it. And so  
> on for ScopeType.SESSION and ScopeType.CONVERSATION. Once your  
> resource classes and providers are Seam components, you get full  
> Seam interception for @In(jection), and so on. E.g. you can use @In  
> ItemDAO on a field in your resource implementation.
>
> 2. You can put @Name on your @Provider class. It has to be  
> ScopeType.APPLICATION or ScopeType.STATELESS. For the STATELESS  
> providers I need an extension to RESTEasy. I need to tell RESTEasy  
> how it should look up an instance of a Provider from Seam at  
> runtime. Right now you guys only support setProvider(clazz) and  
> setProviderInstance(o) at bootstrap. I need  
> setProviderLookup(anImplementationOfALookupInterface) or something  
> similar.
>
> 3. We'll probably have a mechanism for transporting conversation  
> identifiers in HTTP headers. However, I'm thinking that the way this  
> should be implemented is with explicit automatically created  
> resources that identify a particular conversation "workspace". See  
> Bill's blog about JMS integration and how you'd model a transaction  
> resource RESTfully. This is the same approach just for Seam  
> conversations.

So this would be similar to named conversations? You have to  
explicitly define and use a conversation?

> 4. In a second stage we might want to integrate the Seam Application  
> Framework. This is a basic CRUD framework, today used for quick  
> development of JSF apps. We can use this as a foundation to expose  
> entity lists and instances for CRUD/search directly from the  
> database as HTTP resources. Similar to what Rails does out of the  
> box, just nicer :)

Nice.

> 5. I'm thinking about a special provider that can marshal an object  
> graph into an XHTML (not just XML) response body and back from an  
> XHTML request body to an object graph. This is about the  
> "connectedness" of resources, see the O'Reilly REST book. As a  
> developer I should write a Facelets XHTML template that defines the  
> transformation. Imagine that you write it the same way you write a  
> JSF template today, with bidirectional binding using EL expressions,  
> from object getter/setter pair to XML attribute or element value. We  
> can even have built-in Facelets "widgets" that render certain  
> microformats. Seam has some machinery for this already but we might  
> need an extra interceptor on resource methods to trigger the  
> transformation. Or we use Seams pages.xml navigation rules ("when  
> this resource method finishes, render this template"). Bill, I'm not  
> sure we even need anything in RESTEasy for that, Seam intercepts  
> these things anyway if there is a @Name on the class.

Yup, I think this nice. I don't see any particular difficulties  
assuming Seam can intercept the calls correctly. You could perhaps do  
the mapping using pages.xml, or an annotation.

I assume you would build (4) on (5)?

--
Pete Muir
http://www.seamframework.org
http://in.relation.to/Bloggers/Pete

[Resteasy-developers] Seam and RESTEasy integration

[Christian B. <chr...@gm...>]

On Jul 13, 2008, at 15:04 , Ryan J. McDonough wrote:

> Cool! I'm very interested as to how this is being implemented. Also,  
> is this integration going to be part of Seam, RESTEasy, or as a sub- 
> module of RESTEasy?

It's going to be part of Seam, planned is a seam-resteasy.jar that you  
simply drop into your libs (in addition to any resteasy JARs). That's  
how other frameworks and libs are integrated with Seam today. So I  
guess we need a RESTEasy dependency in the Seam POMs to compile it  
(Pete?).

Same for configuration: Any @Provider and @Path classes are  
automatically discovered during Seam application startup when the  
RESTEasy libs are in the classpath. If you want to customize settings,  
you override a built-in Seam component in a Seam configuration file  
(many deployment options here, this is just one of them):

     <component name="resteasyApplicationConfig" precedence="20"
                 
class="org.jboss.seam.resteasy.ResteasyApplicationConfig">
         <property name="scanForResources">
             <value>false</value>
         </property>
         <property name="resourceClassNames">
             <value>my.CatalogResource</value>
             <value>my.ItemResource</value>
         </property>
         ... and so on ...
     </component>

This Seam component supports all the other settings you'd have in  
web.xml with plain RESTEasy. You do not have to touch web.xml at all  
with this approach. This Seam component is an extension of the JAX-RS  
ApplicationConfig. (By the way, this should be an interface, not an  
abstract class... tell the "experts".)

So that allows you to run your existing @Path and @Provider classes in  
a Seam app without any additional configuration or changes. Drop the  
classes into the classpath and Seam will serve HTTP requests through  
its existing resource-loading architecture (the SeamResourceServlet is  
enabled in all Seam applications). You can even hook into that request  
processing and customize the dispatcher, wrap the request, and so on.  
This is regular Seam stuff.

Of course people want that integration not only for integrated  
bootstrap and request processing but for the Seam programming model  
when writing resources and providers:

1. You can put an @Name onto your @Path root resource class. This  
enables Seam lifecycle management for the resource object. If it is  
ScopeType.EVENT you basically get the JAX-RS default (POJO per  
request) lifecycle. If it is ScopeType.APPLICATION, you get Singleton  
lifecycle - you can also put @Synchronized on it. And so on for  
ScopeType.SESSION and ScopeType.CONVERSATION. Once your resource  
classes and providers are Seam components, you get full Seam  
interception for @In(jection), and so on. E.g. you can use @In ItemDAO  
on a field in your resource implementation.

2. You can put @Name on your @Provider class. It has to be  
ScopeType.APPLICATION or ScopeType.STATELESS. For the STATELESS  
providers I need an extension to RESTEasy. I need to tell RESTEasy how  
it should look up an instance of a Provider from Seam at runtime.  
Right now you guys only support setProvider(clazz) and  
setProviderInstance(o) at bootstrap. I need  
setProviderLookup(anImplementationOfALookupInterface) or something  
similar.

3. We'll probably have a mechanism for transporting conversation  
identifiers in HTTP headers. However, I'm thinking that the way this  
should be implemented is with explicit automatically created resources  
that identify a particular conversation "workspace". See Bill's blog  
about JMS integration and how you'd model a transaction resource  
RESTfully. This is the same approach just for Seam conversations.

4. In a second stage we might want to integrate the Seam Application  
Framework. This is a basic CRUD framework, today used for quick  
development of JSF apps. We can use this as a foundation to expose  
entity lists and instances for CRUD/search directly from the database  
as HTTP resources. Similar to what Rails does out of the box, just  
nicer :)

5. I'm thinking about a special provider that can marshal an object  
graph into an XHTML (not just XML) response body and back from an  
XHTML request body to an object graph. This is about the  
"connectedness" of resources, see the O'Reilly REST book. As a  
developer I should write a Facelets XHTML template that defines the  
transformation. Imagine that you write it the same way you write a JSF  
template today, with bidirectional binding using EL expressions, from  
object getter/setter pair to XML attribute or element value. We can  
even have built-in Facelets "widgets" that render certain  
microformats. Seam has some machinery for this already but we might  
need an extra interceptor on resource methods to trigger the  
transformation. Or we use Seams pages.xml navigation rules ("when this  
resource method finishes, render this template"). Bill, I'm not sure  
we even need anything in RESTEasy for that, Seam intercepts these  
things anyway if there is a @Name on the class.

Bootstrap, request servicing, and objectives 1 and 2 I already  
implemented locally. Let's get the provider lookup for 2 done and I  
can commit something into Seam trunk. We'll talk about 3, 4, and 5  
later.