Adrian Crum wrote:
> It's not really a protocol - it is only used inside code.
>
> Your idea is interesting, and would make coding simpler. So, would the
> end result be that the resource loader would "know" what to do with
> component:// resources?
No, I'm thinking along the lines of being able to use webslinger://.
We are wanting to do a framework-only release. As such, no
dependencies should exist *at all* in framework against *anything*
that resides outside of framework. This means that either framework
is completely static, and can never be extended by
applications/specialpurpose/hot-deploy, or some kind of lookup system
will need to be implemented to allow framework to be extended,
whenever another component is added.
These extension points can be used to add location 'protocol' helpers,
new containers, etc, which can then be referenced by various entity
fields, etc.
webslinger supports multiple event
implements(java/groovy/javascript/beanshell/python/ruby/php), multiple
template implementations(velocity/freemarker/php/text), all by
dropping in new jars, and the base code magically discovers them.
This is done by using javax.imagio.spi.ServiceRegistry(<= 1.5), or
java.util.ServiceLoader(>= 1.6), which looks at META-INF/services/$class.
>
> -Adrian
>
> Adam Heath wrote:
>> David E Jones wrote:
>>> It should be supported now, but yeah it would be a good idea to test it
>>> before doing a mass change. And yes, a mass change there would be great
>>> too.
>>>
>>> Once those are done we could probably remove the ${component-dir}/script
>>> directory from the classpath.
>>
>> Hmm, sorta-somewhat unrelated. This series of changes is about using
>> the pseudo-url-like resource loading in ofbiz. This is not
>> extensible, except by adding new code to base. Would using a
>> ServiceRegistry to find new protocol loaders on the classpath be
>> something people are interested in?
>>
>>
