Generally I advocate the approach that one should write the
configuration as they write any API. i.e. POJOs with getters/setters.
Its the job of the container to then take a configuration and map it to
these pojos. I haven't had time to come up with a more concrete proposal
and advocate this for the Managed* classes quite yet though. :-)
David Primmer wrote:
To re-use the the framework in our server environment, we just need an
interface to be able to pull config for a component and an entry point
to start it all off. Doesn't matter what the format or mechanism is.
davep
On Tue, Apr 15, 2008 at 3:29 PM, David Calavera
<[EMAIL PROTECTED]> wrote:
I agree, I think currently there are better solutions than properties files.
The Spring 2.5 annotation configure stuff could be a good example.
On Tue, Apr 15, 2008 at 11:44 PM, Dan Diephouse <
[EMAIL PROTECTED]> wrote:
> I agree with your conclusions - I think the current version is a little
> simplistic. I haven't looked into it much, but I know its on one of my two
> top priority issues for 1.0. Properties files are rarely the way people want
> to configure stuff.
>
>
> David Primmer wrote:
>
> > Thanks Dan. It turns out we were being brain-dead and we should've
> > just used AbderaServlet directly and send in a couple init params like
> > you have in your web.xml.
> >
> > The main question i have now is how to use all the new Managed
> > classes. This is one area where info on how to wire them up will help
> > newbies like me. Some example properties files especially. I couldn't
> > find any in the src. Also, custom routing is the main issue with the
> > ManagedProvider. I'm using a custom provider just for the routing (and
> > since I don't have time to figure out how to write the properties
> > files for the ManagedProvider). Since routing is usually the first
> > place you'd move away from the boilerplate, I'd say it would help to
> > have clear points to factor out the routing info into a class that can
> > be loaded as a property for the managed provider. ManagedRouteManager
> > may also work.
> >
> > davep
> >
> > On Tue, Apr 15, 2008 at 4:46 AM, Dan Diephouse
> > <[EMAIL PROTECTED]> wrote:
> >
> >
> > > We need to make sure this is documented and fix the tutorial. One
> > > shouldn't
> > > have to extend the servlet to get Abdera working. I guess its a
> > > question of
> > > what is best practice... Is it best practice to extend
> > > DefaultProvider, add
> > > your adapters and then supply the init-param for your provider? The
> > > problem
> > > I have with this approach is that it seems a little overly simplistic
> > > as you
> > > still need to get access to your backend somehow (the pre-built
> > > adapters are
> > > another story).
> > >
> > > Dan
> > >
> > >
> > >
> > > David Primmer wrote:
> > >
> > >
> > >
> > > > vasu and i figured it out.
> > > >
> > > > I put the init params into the web.xml:
> > > >
> > > > <init-param>
> > > >
> > > > <param-name>org.apache.abdera.protocol.server.Provider</param-name>
> > > >
> > > > <param-value>org.apache.abdera.example.CustomProvider</param-value>
> > > > </init-param>
> > > >
> > > > then i get them from the config and have the manager create the
> > > > providor:
> > > >
> > > > @Override
> > > > protected Provider createProvider() {
> > > > return manager.newProvider(getProperties(getServletConfig()));
> > > > }
> > > >
> > > > if you leave the init params out, you create a DefaultProvider
> > > > instead
> > > > of your CustomProvider
> > > >
> > > > davep
> > > >
> > > > On Fri, Apr 11, 2008 at 2:04 PM, David Primmer <
> > > > [EMAIL PROTECTED]>
> > > >
> > > >
> > > wrote:
> > >
> > >
> > > >
> > > >
> > > > > I'm doing server setup that I thought should be better documented.
> > > > > Basically, I'd like to make the CustomProvider example work with
> > > > > a
> > > > > web.xml based setup. I see some info on it on the wiki but the
> > > > > example
> > > > > itself uses java code to compose the app and to start jetty.
> > > > >
> > > > > So I made a CustomSampleServlet that extends AbderaServlet and
> > > > > re-uses
> > > > > the other two files from the custom example.
> > > > >
> > > > > This is what it does:
> > > > >
> > > > > public class CustomSampleServlet extends AbderaServlet {
> > > > >
> > > > > private final static Log log =
> > > > > LogFactory.getLog(AbderaServlet.class);
> > > > >
> > > > > @Override
> > > > > protected Provider createProvider() {
> > > > > return new CustomProvider();
> > > > > }
> > > > >
> > > > > @Override
> > > > > public void init() {
> > > > > log.debug("Initialing Abdera Servlet");
> > > > > manager = createServiceManager();
> > > > > provider = createProvider();
> > > > > log.debug("Using provider - " + provider);
> > > > > }
> > > > >
> > > > > }
> > > > >
> > > > >
> > > > > Then in my web.xml I have what is at the bottom of this page:
> > > > >
> > > > >
> > > > >
> > > >
> > >
http://cwiki.apache.org/confluence/display/ABDERA/Your+first+AtomPub+Server
> > >
> > >
> > > > line 179 of ServletRequestContext does:
> > > > > Abdera abdera = provider.getAbdera();
> > > > >
> > > > > but returns null. This doesn't seem right. Next thing i know, i
> > > > > have a
> > > > > null pointer exception on ServletRequestContext.getHost. Can
> > > > > someone
> > > > > help with the provider bootstrap code?
> > > > >
> > > > > Does this have something to do with leaving out this sort of
> > > > > thing?:
> > > > > servletHolder.setInitParameter(ServiceManager.PROVIDER,
> > > > > CustomProvider.class.getName());
> > > > >
> > > > > thanks.
> > > > >
> > > > > davep
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > --
> > > Dan Diephouse
> > > MuleSource
> > > http://mulesource.com | http://netzooid.com
> > >
> > >
> > >
> >
>
> --
> Dan Diephouse
> MuleSource
> http://mulesource.com | http://netzooid.com
>
--
David Calavera
http://www.thinkincode.net
--
Dan Diephouse
MuleSource
http://mulesource.com | http://netzooid.com
