cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: DispatcherServlet
Date Sat, 19 May 2007 11:27:51 GMT
Daniel Fagerstrom wrote:
> Reinhard Poetz skrev:
>> Daniel Fagerstrom wrote:
> ...
>>> But there are important use cases for run time discovery of servlet 
>>> services as well. 
>>
>> definitly. For the use cases that *I* have, a generator will be good 
>> enough - I don't think that I need a source for them:
>>
>> <map:generate type="servlets" src="data/myconfig.xml"/>
>>
>> This could return something like this:
>>
>> <servlets>
>>   <service-A>
>>     <config>...</config>
>>   </service->
>>   <service-B>
>>     <config>...</config>
>>   </service-B>
>> </servlets>
>>
>> What are the usecases for implementing a servlets: protocol at all? 
>> (Maybe I'm overlooking something important here ...)
> 
> In the above output from your generator, you need to reference the 
> actual resources of the listed servlet services. And to be able to do 
> that you need an URI. 

The URI is data/myconfig.xml, resolved against all available servlet services.

> And right now we have not any protocol that is suitable for that.

AFAIU we only have to create ServletConnection objects. Currently the 
constructor expects the connection name as parameter but it shouldn't be 
difficult to create those objects by implementing a second constructor that uses 
the bean id or a bean reference.

> For the use case we are discussing, the assumption is that the caller of 
> the servlets generator is not connected to all the servlet services. 
> Thus we cannot use the servlet: protocol that by design assumes an 
> explicit named connection.
> 
> So we need a protocol that allows (webapp) global servlet service URIs 
> anyway. And then we could as well make it listable as a source is usable 
> in more contexts than a generator.

ok. What I still don't understand is, why we want to make the bean id being part 
of this URI at all? Or do I misinterpret your discussion with Grek here?

Isn't having an URI

servlets:/data/myconfig.xml

good enough to configure a listable source? The getChildren() method of the 
created source will return all child sources that return true on 
childSource().exists().

I don't see the need to lookup not configured servlet services by their name. 
The only use case I can think of is optional servlet services. To solve it, I'd 
rather introduce an "optional" parameter for servlet service configurations. 
However, I'm not convinced that we need this feature at all if we can resolve 
servlets:/data/myconfig.xml URIs which would return servlet service sources that 
are unknow in the context of the current servlet service.

-- 
Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Mime
View raw message