Hey Jeppe,
The new approach is quite similar to the old approach, but takes
advantage of a new trick that I've learned. Basically the following
three lines of code will return a set of URLs:
packageName = packageName.replace('.', '/');
ClassLoader loader = Thread.currentThread().getContextClassLoader();
Enumeration<URL> urls = loader.getResources(packageName);
Each URL will be either a path to a directory matching the requested
package within a directory in the classpath, or a path inside a JAR
in which case the URL also includes the full path to the JAR.
What's great about this approach is that it's very efficient -
there's no need to specify url filters like most of us do now. And
where the current approach falls down when the classloader isn't a
URLClassLoader, this one will work because it doesn't depend on any
methods that aren't in the ClassLoader interface :D
-t
On Oct 5, 2006, at 4:37 PM, Jeppe Cramon wrote:
> Hi Tim
>
> I'm behind you on this too. I think it's more important to keep
> Stripes clean while we can.
> Go for it :)
>
> Could you elaborate on whats new in your scanning approach as I'm
> quite interrested in that for other purposes?
>
> /Jeppe
> -----Original message-----
> From: Tim Fennell [EMAIL PROTECTED]
> Date: Thu, 05 Oct 2006 18:01:40 +0200
> To: Stripes Development List [email protected]
> Subject: [Stripes-dev] Backwards Compatibility & 1.5
>
>> Hey All,
>>
>> I'm wondering what you all would think of some (mostly minor)
>> backwards compatibility breaks in Stripes 1.5? I'm not thinking of
>> doing anything too drastic, the two things I have in mind so far are:
>>
>> 1. Changing the default way classes are scanned for. I've found a
>> new way that should be more resilient in the face of bizarre
>> classloaders and classloader setups, and probably more efficient to
>> boot. It would require the specification of one or more "root"
>> package to start scanning from (e.g. com.myco or
>> com.myco.web.stripes) and then scans from there on down. The change
>> would *require* a new configuration property and would remove two
>> existing ones (ActionResolver.*Filters). Of course, a nice big error
>> message can be lobbed at users who still have the old configuration.
>>
>> 2. Changing @Before and @After to take an on="" attribute. This
>> breaks things because the lifecycle stages are currently specified as
>> the value attribute, which means the attribute name can be omitted
>> because it's the only attribute. This would cause compile breaks (at
>> least it'd be found early), but can be fixed with a relatively simple
>> search/replace for @Before(XXX) -> @Before(stages=XXX)
>>
>> My take is that if these are clearly documented in the release notes
>> and announcements, along with how to deal with them, it's probably
>> not a big deal. I'd figure that for someone who knows what they're
>> doing, fixing these things is probably a 15-30 minute task during the
>> upgrade - they don't change some fundamental way Stripes works or
>> alter backwards compatibility of features that will impact how most
>> action beans work. I also think that it's probably better to bite
>> the bullet and make sure Stripes 1.5 is as good and clean as
>> possible, instead of trying to come up with a not so great solution
>> that keeps backwards compatibility.
>>
>> I might also take the time to remove some of the methods that have
>> been deprecated since early on (like Stripes 1.1/1.2). So, what do
>> you all think?
>>
>> -t
>>
>> ---------------------------------------------------------------------
>> ----
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to
>> share your
>> opinions on IT & business topics through brief surveys -- and earn
>> cash
>> http://www.techsay.com/default.php?
>> page=join.php&p=sourceforge&CID=DEVDEV
>> _______________________________________________
>> Stripes-development mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/stripes-development
>
> ----------------------------------------------------------------------
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys -- and earn
> cash
> http://www.techsay.com/default.php?
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Stripes-development mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stripes-development
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
