Paul Sandoz wrote:
> Richard Wallace wrote:
>>> Unfortunately there seems no consistent way to get the complete set
>>> of base URLs to stuff of the class loader :-( and therefore no
>>> zero-config approach.
>>>
>>
>> Hmm you're right. It only seems to return the classes directory.
>> That is unexpected and disappointing.
>
> Indeed, i was rather excited at first!
>
>
>> I wonder if looking for a common list of top level packages, "com",
>> "net", "org" for example, would be "good enough".
>>
>
> Hmm... not sure i like that approach as a default option as it is not
> complete and could tend to branch across multiple areas that would
> never be intended to be searched. For example "com" returns these:
>
> jar:file:/usr/jdk/instances/jdk1.5.0/jre/lib/jsse.jar!/com
> jar:file:/usr/jdk/instances/jdk1.5.0/jre/lib/ext/sunjce_provider.jar!/com
> jar:file:/usr/jdk/instances/jdk1.5.0/jre/lib/ext/jhall.jar!/com
> jar:file:/usr/jdk/instances/jdk1.5.0/jre/lib/ext/jmf.jar!/com
> jar:file:/usr/jdk/instances/jdk1.5.0/jre/lib/ext/jmplay.jar!/com
> jar:file:/usr/jdk/instances/jdk1.5.0/jre/lib/ext/clibwrapper_jiio.jar!/com
>
> jar:file:/usr/jdk/instances/jdk1.5.0/jre/lib/ext/jai_imageio.jar!/com
>
> I am not sure we can really specify a default option for the packages.
> Sometimes i create experimental code with package names that would not
> fit into any pattern :-)
>
Like I said, I'm not too thrilled with this approach either. Was just
trying to think of how to solve 80% of the cases easily.
>
>>>
>>>> So there should be no need to specify where the class files and
>>>> jars are.
>>>>
>>>
>>> But instead package names do need to be specified.
>>>
>>
>> Yeah, I had thought that using a blank package name would give you
>> everything and I'm not even happy with my above suggestion of using
>> some common top level package names.
>>
>>> Arguably this requires more configuration knowledge that is likely
>>> to change, for example if i add a new resource in a different
>>> package to my existing resources then i need to include that package
>>> (and if i refactor then i need to change it). Compile-time tools can
>>> help but they do complicate the build and deploy process (which is
>>> why we moved away from them). I think this gets more complicate when
>>> we consider message readers and writers (see end of email).
>>
>> This isn't too much of an issue for me because my resources will
>> almost certainly live under a package like com.myco.myapp.rest and it
>> is extremely unlikely that will change. So I'm perfectly happy to
>> set this single parameter at the beginning of a project and
>> forgetting about it.
>>>
>>> I very much like the idea of a zero-config build and deploy approach
>>> by default.
>>
>> I've found that an absolutely zero-config is a good thing to strive
>> for, but not always - I'd maybe even say rarely - attainable.
>>
>
> Yes. What we are learning from the class scanning approach is we
> cannot assume that classes are always consistently available in one
> location and from the file system using a particular class loader.
> Sometimes classes are loaded from the network or a database. The
> Struts code makes the assumption on a file-based approach.
>
> What i like is by default there is a nice out of the box experience to
> get started.
>
> I am glad we have a pluggable solution via ResourceConfig so that
> developers can choose one of a standard set of strategies or a roll
> their own.
>
This is the solution that I wound up implementing on the train to work
this morning. I created a PackageResourceConfig like you mentioned
before and (since I'm already using Struts2) used the XWork ResolverUtil
I mentioned previously to do the grunt work. The only problem that I
ran into was that, at first, I thought the parameter map passed into the
constructor would contain a complete list of servlet init parameters.
So I added an init-param for "resourcePackages" with my resource package
like "com.myco.myapp.rest" and had hoped to be able to get it from my
PackageResourceConfig. But that doesn't work. On closer inspection,
the parameter map passed to the constructor is a newly created map with
only the PROPERTY_RESOURCE_PATH attribute copied over. For now I've
hard coded my resource package, but I'd rather not have to. Is there
any reason the servlet parameter map isn't just passed along to the
constructor directly?
>
>>>
>>> Hmmm... perhaps we could do the following:
>>>
>>> Have a PackageResourceConfig that takes a list of package names that
>>> are transformed into URLs (like what Struts does) that are then
>>> scanned for classes (using ASM). The PackageResourceConfig class and
>>> the package names for the PackageResourceConfig instance could be
>>> passed as servlet init-params. That should work consistently for the
>>> two forms of Jetty deployment.
>>>
>>> What do you think?
>>
>> Sounds fine to me. Any idea when you plan on tackling this?
>>
>
> Next week. It should be mostly a little refactoring of what we already
> have.
>
Fantastic.
>
>>>
>>> BTW i am curious if you tried setting the servlet init-param:
>>>
>>> "com.sun.ws.rest.config.property.ResourcePaths"
>>>
>>> to the absolute location of where the class files reside in the dev
>>> deploy case? i.e. whether the Servlet.getRealPath works in such cases.
>>
>> I didn't try it because I figured it would work but wasn't a long
>> term solution.
>>
>
> OK.
>
> Paul.
>