Yeah, I was thinking/doing something similar;

But as of RC4 I seem to have no way of getting access to my Spring
application context without using the "SpringContext" packaged with
Restlet.  There is no longer access to the ServletContext from Application
...  since it turns out my Context is not a ServletContextAdapter (with its
getServletContext method) but an "ApplicationContext", I seem to have no
access to the underlying servlet context from the Application, which was my
last resort for getting access at _least_ to Spring.  (I might be missing
something subtle here, but the examples for RC4 no longer work.)

It seems like I may have to abandon my experiment with Restlet.  It seems
its philosophy and mine do not jive -- like many Java frameworks past it
wants to own the entire stack; it wants to be my object factory instead of
the container I already chose, and it seems to want to be my web server and
application server instead of the one I already chose (for many reasons);
hell, it even wants to manage logging as well.

The value proposition of something like Restlet I thought would be a simple
clean way of mapping URIs to REST concepts, but I think it may have taken on
way too much beyond that for my comfort. If I can't find a simple clean way
of making Restlet cooperate with an existing application code base I will
just go back to using URLRewrite and my own custom resource mapping.

Thanks anyways,
Ryan
--
Ryan Daum
[EMAIL PROTECTED]
Technical Lead, Toronto
647.724.5232 x 2073

On 3/9/07, Makunas, Michael <[EMAIL PROTECTED]> wrote:


I understand your frustration with having to create the application
outside of Spring. One potential solution I've thought might work is to have
a version of restlet's ServerServlet that extends Springs HttpServletBean.
In the meantime, we've been able to get everything except the application
managed by Spring by doing something like this:

Within your class that extends Application:

    Map<String, Finder> resourceMap = (Map<String, Finder>)
springContext       .getBean(RESOURCE_MAP);
    for (String key : resourceMap.keySet()) {
         router.attach(key, resourceMap.get(key));
    }

And in you ApplicatonContext.xml:

     <bean id="resourceMap" class="java.util.HashMap">
       <constructor-arg>
         <map>
              <entry key="/foos/{foo}"><ref bean="fooFinder"/></entry>
              <entry key="/bars/{bar}"><ref bean="barFinder"/></entry>
         </map>
        </constructor-arg>
     </bean>

    <bean id="fooFinder" class="org.restlet.ext.spring.SpringFinder">
        <lookup-method name="createResource" bean="fooResource"/>
    </bean>

    <bean id="barFinder" class="org.restlet.ext.spring.SpringFinder">
        <lookup-method name="createResource" bean="barResource"/>
    </bean>

    <bean id="fooResource" class="com.example.resource.FooResource"
scope="prototype" parent="baseResourceBean" />

    <bean id="barResource" class="com.example.resource.BarResource"
scope="prototype" parent="baseResourceBean" />


Hope that helps...

-Michael

________________________________________
From: Ryan Daum [mailto:[EMAIL PROTECTED]
Sent: 09 March 2007 16:22
To: [email protected]
Subject: Using SpringFinder

I'm trying to use the new SpringFinder class, but I'm unsure about one
thing.

I see from the example in the Javadoc for configuring the resource using
SpringFinder, but I do not see an example about how to register the
SpringFinder from the application. In particular, how can the application
"know" about my SpringFinder instance given that the RESTlet framework
insists on creating the application; it is not injectable, since there
doesn't appear to be a way to have Spring manage the application instance.

Keep in mind that I cannot use the SpringContext stuff included in the
extension package since I am using Restlet in an existing Spring application
invoked from a WAR, and it uses the traditional WebApplicationContext stuff
from Spring which is initialized from a servlet.

Unfortunately it seems (hope I'm wrong) that Restlet is still vaguely
competing with Spring and other IOC systems rather than cooperating with
them.

Ryan

--
Ryan Daum
[EMAIL PROTECTED]
Senior Developer, Toronto
647.724.5232 x 2073

Reply via email to