Re: What do you think about a classloader task ?
Rainer Noack wrote: Hi Steve Your security issues sounds very reasonable for me. I've never thought of this, as I've used the URL option rarely in practice and only for LAN access where security was irrelevant. Another reason is, that I've no experience with this stuff. Do you think, it could be a blocker? What is the best solution in the case, there is nobody who is more familiar with this stuff and implements the security issues now? a) Contribute as is and document this issue in the task documentation until it's hopefully implemented later or b) Change the task, so that it does not accept non-file URLs (should be no big deal) or accepts only the original Path type instead of the extended one. Regards, Rainer I think for a build process you are taking your own risks. The danger is that if people do bind to remote URLs for stuff, they create a new back door. We should document that :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What do you think about a classloader task ?
Hi Rainer, How did you manage to post your code? I tried to do the same awhile back, but apache.org wouldn't accept a zip attachment, and when I attached the java files individually, it stripped them all out of the email - leaving only text files... Cheers, Robert -Original Message- From: Rainer Noack [mailto:[EMAIL PROTECTED] Sent: 29 March 2004 11:59 To: [EMAIL PROTECTED] Subject: What do you think about a classloader task ? Hi Ant developers, After taskdef supports the loaderref attribute, I've written a task that is able to a) append classpath entries to existing classloaders, b) explicitely create classloaders, c) put the actual path of a classloader into a property and d) log a simple report about the currently classloaders. Currently it supports URLClassLoader and AntClassLoader. It is designed to simply support custom extensions for any arbitrary ClassLoader. I've posted it some time ago - a little rash (sorry) - to this list. However, as classpathes can completely managed from inside the build.xml, this task has helped in several projects 1. to avoid the need to either change Ant's default installation by adding or removing jars to or from Ant's lib dir or manage the classpath in the launching script and 2. to avoid classpath-problems with custom tasks (especially if they should - for whatever reason - be used as jars in the same buildfile as they were created). b) and c) can be used to easily sync other task's classpathes and d) was helpful to debug some classpath problems and understand classloader behaviour ;-) When I found a similar Classloader task in Ant's CVS (originally from Costin Manolache), I was wondering that it was never advanced and released. IMHO, a classloader task would be a pretty helpfull extension to the existing alternatives for some usage. Are there reasons for not releasing it? I would be grateful for a short annotation (found nothing in the list archive). Otherwise, I would be proud to contribute the task to Ant if you find it helpful too. Regards (and excuse me for the long mail), Rainer P.S. Adding this task to the external task list is dissatisfying IMHO, as it shoots the major advantage (1.) down. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What do you think about a classloader task ?
Hi Robert, I've sent the results from patch.xml (CVS-repository): a patch.txt file (the diff output) and a patch.tar.gz with the new files. However, sending a patch or enhancement to the list without prior agreement, seems to be a breach of the rules and will be ignored. I'm currently a bit insecure about the appropriate form. Regards, Rainer -Original Message- From: Robert Smith [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 1:20 PM To: 'Ant Developers List'; [EMAIL PROTECTED] Subject: RE: What do you think about a classloader task ? Hi Rainer, How did you manage to post your code? I tried to do the same awhile back, but apache.org wouldn't accept a zip attachment, and when I attached the java files individually, it stripped them all out of the email - leaving only text files... Cheers, Robert -Original Message- From: Rainer Noack [mailto:[EMAIL PROTECTED] Sent: 29 March 2004 11:59 To: [EMAIL PROTECTED] Subject: What do you think about a classloader task ? Hi Ant developers, After taskdef supports the loaderref attribute, I've written a task that is able to a) append classpath entries to existing classloaders, b) explicitely create classloaders, c) put the actual path of a classloader into a property and d) log a simple report about the currently classloaders. Currently it supports URLClassLoader and AntClassLoader. It is designed to simply support custom extensions for any arbitrary ClassLoader. I've posted it some time ago - a little rash (sorry) - to this list. However, as classpathes can completely managed from inside the build.xml, this task has helped in several projects 1. to avoid the need to either change Ant's default installation by adding or removing jars to or from Ant's lib dir or manage the classpath in the launching script and 2. to avoid classpath-problems with custom tasks (especially if they should - for whatever reason - be used as jars in the same buildfile as they were created). b) and c) can be used to easily sync other task's classpathes and d) was helpful to debug some classpath problems and understand classloader behaviour ;-) When I found a similar Classloader task in Ant's CVS (originally from Costin Manolache), I was wondering that it was never advanced and released. IMHO, a classloader task would be a pretty helpfull extension to the existing alternatives for some usage. Are there reasons for not releasing it? I would be grateful for a short annotation (found nothing in the list archive). Otherwise, I would be proud to contribute the task to Ant if you find it helpful too. Regards (and excuse me for the long mail), Rainer P.S. Adding this task to the external task list is dissatisfying IMHO, as it shoots the major advantage (1.) down. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What do you think about a classloader task ?
Open a bug (enhancement request) and attache the patch and zip files to it. I gues you should put the text of your previous message as the body of the bug. Jose Alberto -Original Message- From: Rainer Noack [mailto:[EMAIL PROTECTED] Sent: 29 March 2004 12:54 To: [EMAIL PROTECTED] Subject: RE: What do you think about a classloader task ? Hi Robert, I've sent the results from patch.xml (CVS-repository): a patch.txt file (the diff output) and a patch.tar.gz with the new files. However, sending a patch or enhancement to the list without prior agreement, seems to be a breach of the rules and will be ignored. I'm currently a bit insecure about the appropriate form. Regards, Rainer -Original Message- From: Robert Smith [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 1:20 PM To: 'Ant Developers List'; [EMAIL PROTECTED] Subject: RE: What do you think about a classloader task ? Hi Rainer, How did you manage to post your code? I tried to do the same awhile back, but apache.org wouldn't accept a zip attachment, and when I attached the java files individually, it stripped them all out of the email - leaving only text files... Cheers, Robert -Original Message- From: Rainer Noack [mailto:[EMAIL PROTECTED] Sent: 29 March 2004 11:59 To: [EMAIL PROTECTED] Subject: What do you think about a classloader task ? Hi Ant developers, After taskdef supports the loaderref attribute, I've written a task that is able to a) append classpath entries to existing classloaders, b) explicitely create classloaders, c) put the actual path of a classloader into a property and d) log a simple report about the currently classloaders. Currently it supports URLClassLoader and AntClassLoader. It is designed to simply support custom extensions for any arbitrary ClassLoader. I've posted it some time ago - a little rash (sorry) - to this list. However, as classpathes can completely managed from inside the build.xml, this task has helped in several projects 1. to avoid the need to either change Ant's default installation by adding or removing jars to or from Ant's lib dir or manage the classpath in the launching script and 2. to avoid classpath-problems with custom tasks (especially if they should - for whatever reason - be used as jars in the same buildfile as they were created). b) and c) can be used to easily sync other task's classpathes and d) was helpful to debug some classpath problems and understand classloader behaviour ;-) When I found a similar Classloader task in Ant's CVS (originally from Costin Manolache), I was wondering that it was never advanced and released. IMHO, a classloader task would be a pretty helpfull extension to the existing alternatives for some usage. Are there reasons for not releasing it? I would be grateful for a short annotation (found nothing in the list archive). Otherwise, I would be proud to contribute the task to Ant if you find it helpful too. Regards (and excuse me for the long mail), Rainer P.S. Adding this task to the external task list is dissatisfying IMHO, as it shoots the major advantage (1.) down. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What do you think about a classloader task ?
+1 Rainer Noack wrote: Hi Ant developers, After taskdef supports the loaderref attribute, I've written a task that is able to a) append classpath entries to existing classloaders, b) explicitely create classloaders, c) put the actual path of a classloader into a property and d) log a simple report about the currently classloaders. Currently it supports URLClassLoader and AntClassLoader. It is designed to simply support custom extensions for any arbitrary ClassLoader. I've posted it some time ago - a little rash (sorry) - to this list. However, as classpathes can completely managed from inside the build.xml, this task has helped in several projects 1. to avoid the need to either change Ant's default installation by adding or removing jars to or from Ant's lib dir or manage the classpath in the launching script and 2. to avoid classpath-problems with custom tasks (especially if they should - for whatever reason - be used as jars in the same buildfile as they were created). b) and c) can be used to easily sync other task's classpathes and d) was helpful to debug some classpath problems and understand classloader behaviour ;-) When I found a similar Classloader task in Ant's CVS (originally from Costin Manolache), I was wondering that it was never advanced and released. IMHO, a classloader task would be a pretty helpfull extension to the existing alternatives for some usage. Are there reasons for not releasing it? I would be grateful for a short annotation (found nothing in the list archive). Otherwise, I would be proud to contribute the task to Ant if you find it helpful too. Regards (and excuse me for the long mail), Rainer P.S. Adding this task to the external task list is dissatisfying IMHO, as it shoots the major advantage (1.) down. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What do you think about a classloader task ?
There was some discussion about Costin's classloader task for the 1.6 release: http://marc.theaimsgroup.com/?l=ant-devm=106389211508059w=2 Peter Rainer Noack wrote: Hi Ant developers, After taskdef supports the loaderref attribute, I've written a task that is able to a) append classpath entries to existing classloaders, b) explicitely create classloaders, c) put the actual path of a classloader into a property and d) log a simple report about the currently classloaders. Currently it supports URLClassLoader and AntClassLoader. It is designed to simply support custom extensions for any arbitrary ClassLoader. I've posted it some time ago - a little rash (sorry) - to this list. However, as classpathes can completely managed from inside the build.xml, this task has helped in several projects 1. to avoid the need to either change Ant's default installation by adding or removing jars to or from Ant's lib dir or manage the classpath in the launching script and 2. to avoid classpath-problems with custom tasks (especially if they should - for whatever reason - be used as jars in the same buildfile as they were created). b) and c) can be used to easily sync other task's classpathes and d) was helpful to debug some classpath problems and understand classloader behaviour ;-) When I found a similar Classloader task in Ant's CVS (originally from Costin Manolache), I was wondering that it was never advanced and released. IMHO, a classloader task would be a pretty helpfull extension to the existing alternatives for some usage. Are there reasons for not releasing it? I would be grateful for a short annotation (found nothing in the list archive). Otherwise, I would be proud to contribute the task to Ant if you find it helpful too. Regards (and excuse me for the long mail), Rainer P.S. Adding this task to the external task list is dissatisfying IMHO, as it shoots the major advantage (1.) down. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What do you think about a classloader task ?
Rainer Noack wrote: Hi Ant developers, After taskdef supports the loaderref attribute, I've written a task that is able to a) append classpath entries to existing classloaders, b) explicitely create classloaders, c) put the actual path of a classloader into a property and d) log a simple report about the currently classloaders. Currently it supports URLClassLoader and AntClassLoader. It is designed to simply support custom extensions for any arbitrary ClassLoader. I've posted it some time ago - a little rash (sorry) - to this list. However, as classpathes can completely managed from inside the build.xml, this task has helped in several projects 1. to avoid the need to either change Ant's default installation by adding or removing jars to or from Ant's lib dir or manage the classpath in the launching script and 2. to avoid classpath-problems with custom tasks (especially if they should - for whatever reason - be used as jars in the same buildfile as they were created). This all seems useful, and is the logical extension of the -lib option to insert new stuff into the base classloader. I am currently busy doing classpath stuff and ant integration with our deployment framework (see http://cvs.sourceforge.net/viewcvs.py/smartfrog/core/extras/ant/doc/ant_tasks.sxi). One thing smartfrog does is lets you specify a codebase when describing a new app to host/deploy; that codebase takes URLs. now in security on mode, only signed and sealed URLs are allowed, but ignoring that detail, being able to spec URLs to where jars come from is very, very slick. Security does matter; you dont want to have build files that go codebase add url=http://gump.apache.org/latest/junit/dist/junit.jar; / codebase without something saying 'is this a trusted release of junit'. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: What do you think about a classloader task ?
Hi Steve Your security issues sounds very reasonable for me. I've never thought of this, as I've used the URL option rarely in practice and only for LAN access where security was irrelevant. Another reason is, that I've no experience with this stuff. Do you think, it could be a blocker? What is the best solution in the case, there is nobody who is more familiar with this stuff and implements the security issues now? a) Contribute as is and document this issue in the task documentation until it's hopefully implemented later or b) Change the task, so that it does not accept non-file URLs (should be no big deal) or accepts only the original Path type instead of the extended one. Regards, Rainer -Original Message- From: Steve Loughran [mailto:[EMAIL PROTECTED] Sent: Monday, March 29, 2004 3:35 PM To: Ant Developers List Subject: Re: What do you think about a classloader task ? Rainer Noack wrote: Hi Ant developers, After taskdef supports the loaderref attribute, I've written a task that is able to a) append classpath entries to existing classloaders, b) explicitely create classloaders, c) put the actual path of a classloader into a property and d) log a simple report about the currently classloaders. Currently it supports URLClassLoader and AntClassLoader. It is designed to simply support custom extensions for any arbitrary ClassLoader. I've posted it some time ago - a little rash (sorry) - to this list. However, as classpathes can completely managed from inside the build.xml, this task has helped in several projects 1. to avoid the need to either change Ant's default installation by adding or removing jars to or from Ant's lib dir or manage the classpath in the launching script and 2. to avoid classpath-problems with custom tasks (especially if they should - for whatever reason - be used as jars in the same buildfile as they were created). This all seems useful, and is the logical extension of the -lib option to insert new stuff into the base classloader. I am currently busy doing classpath stuff and ant integration with our deployment framework (see http://cvs.sourceforge.net/viewcvs.py/smartfrog/core/extras/ant/doc/ant_task s.sxi). One thing smartfrog does is lets you specify a codebase when describing a new app to host/deploy; that codebase takes URLs. now in security on mode, only signed and sealed URLs are allowed, but ignoring that detail, being able to spec URLs to where jars come from is very, very slick. Security does matter; you dont want to have build files that go codebase add url=http://gump.apache.org/latest/junit/dist/junit.jar; / codebase without something saying 'is this a trusted release of junit'. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
