DO NOT REPLY [Bug 14834] New: - Custom selector doesn't setProject() nor allow loaderef on loaded class

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14834>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14834

Custom selector doesn't setProject() nor allow loaderef on loaded class

           Summary: Custom selector doesn't setProject() nor allow loaderef
                    on loaded class
           Product: Ant
           Version: 1.5.1
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Core
        AssignedTo: ant-dev@jakarta.apache.org
        ReportedBy: ddevienne@lgc.com


Here's my current beef with the custom selector.

1) Custom selector can only take <param> nested elements, instead of complex 
data types!
   All extensions points in Ant need to support the normal set/add/create Bean 
pattern used by tasks and types. No just selectors, but filters, selectors, 
conditions, and xml catalog resolvers...

2) Custom selector doesn't call setProject() on the loaded class when it's a 
ProjectComponent.
   To turn around (1), I defined a pathref <param> taking the id as value. 
Unfortunately, one needs access to the Project to be able to resolve the id!!!
This is achieved using the code below.

public class ExtendSelector extends BaseSelector {
...
    public void verifySettings() {
    ...
        if (dynselector instanceof ProjectComponent) {
            ((ProjectComponent)dynselector).setProject(getProject());
        }
    }
}

3) Even if (2) was solved, I would still be not happy because then I would fall 
into a classloader problem. The id I reference is a custom type extending Path 
loaded using a special loaderef, and Custom selector doesn't allow using a 
custom loaderef, thus I would end up with a ClassCastException because although 
using the same classpath, and same classname, the instance loaded under an id 
in Project would be laoded from another classloader than the instance reference 
I would be casting it into!!!

I'm down to being forced to passing my datatype as a string into the param, and 
having to reparse it in my custom selector to make it work...

Really, I mean really, all Ant extension points should be handled exactly the 
same, with proper bean access, classloading, and initialization.

Even if I'm gripping about selectors here because it's what I'm using, this is 
valid in general for Ant, and is critical in my mind for Ant's health.

Could please the expert debate this please? Thanks, --DD

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>