--- Scott Stirling <[EMAIL PROTECTED]> wrote: > DD asks: > > > Does that play well with application containers > that often embed Ant? > > Stephen McConnell replies, in part: > > Something to keep in mind is that the creation of > a URL is handled inside > > the system classloader. As such when the JVM > attempts to locate handler > > classes, it is limited to classes that exist > within the system classloader > > or system extensions. Application normally deal > with this constraint be > > ensuring that the jar file containing protocol > handlers is included in > > system classloader or is installed as a JVM > extension - however, an > > alternative is to deploy a JVM with a mutable > system classloader. > > What do you guys mean by "mutable system > classloader?" This is > intriguing but also smells suspicious to me, having > worked with > classloaders quite a bit over the years. > > > > > Enabling the declaration of > > > > custom protocol handlers as a part of system > classloader expansion > > > > would significantly simply things for > applications such as Depot > > > > (which makes extensive use of custom > handlers). > > Custom protocol handlers can, I know because I've > done it, be handled > in another way by building up support for them at > the application > layer. For example (from a an XML file for location > metadata: > > <map src="cp:maps/first-floor.png" > xSize="300" ySize="500" name="First > Floor"/> > > That src="cp:maps/first-floor.png" is handled in > code that interprets > any src attribute value beginning with "cp:" as a > pointer to a > resource that should be loaded from the classpath > (the cp). This was > added to support loading maps in a JUnit test > context. When the "cp:" > prefix is not present, the resource is interpreted > as a file system > resource. > > This is a simple example. My point is just that > custom protocol > handlers could probably be handled as an application > layer > enhancement, as alternative to leveraging the JVM > system settings, > which is invasive and inconvenient to deploy, > especially in embedded > contexts. > > > > > the combination of system classloader mutation > plus support for > > > > custom URL handlers would contribute to a > significant potential > > > > simplification of > > > > Depot's extensions to the Ant project model > and task some > > > task implementations. > > What is Depot?, if you don't mind me asking, late to > the discussion. > > > Custom handlers allow the introduction of > alternative resource > > identification and retrieval mechanisms. For > example - data could be > > referenced using a query structure expressed as a > url and the handler could > > use the url to interrogate a remote database. > Another example is multiple > > remote data sources (as is the case of the > 'artifact' protocol). In these > > example the custom URL enables the removal of > logic concerning resource > > type and associated retrieval mechanics from > application code. This results in > > greater portability and easier long-term > maintenance. > > I think you're right. I remember a classic JavaWorld > example using the > protocol handler API to create one for working with > the Windows > registry. That said, in the embedded contexts where > Ant often runs > (IDEs, installers, app servers, other tools), it is > arguably much more > powerful for Ant to be able to control such things > in its application > layer rather than depending on system-level JVM > configuration. > > Where would these protocols appear from a user > perspective? In build > scripts? If that's the case, then I'd definitely say > consider letting > Ant handle them and convert them to standard URLs > through a registry > mechanism perhaps like the custom task registry.
Scott, are you talking about something like option (b) that I described at the end of: http://marc.theaimsgroup.com/?l=ant-dev&m=115885448826992&w=2 ? -Matt > > > > I guess my position on these handlers depends on > the ease to > > > install them to a running JVM, and the actual > use cases > > > having them would solves. --DD > > Scott Stirling > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
