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 :-)
>>
>>> 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.
>>
>> 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.
>>
>> 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.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109