Costin,
Costin Manolache wrote:
>
>
> I saw a proposal for 'conditional' on all tasks ( for ant1.6). In any case
> the current ant ( even 1.5 ) seems to have all the elements it needs to start
> tomcat ( cactus and anteater are doing it ).
>
Basically, commons-launcher classloads the ant.jar bundled with Tomcat 5
(Jasper2 also classloads Ant 1.5). commons-launcher is just a wrapper
for bootstrapping Ant plus some custom tasks and data types. I don't use
Ant's scripts because Ant' batch script suffers the same Windows
problems as every other batch based program:
1. You can't run the application in the background (Ant's <java> task
does a Process.waitFor() on all forks)
2. Ant must be launched with a DOS batch script that is subject to the
same DOS shell flakiness as the old Tomcat scripts had (e.g. %0
sometimes does not contain a path, the "for" command sometimes cannot
handle spaces in paths, environment variables cannot handle "="
characters in them, etc.)
3. Ant cannot be detached from a DOS shell
I did not want to reinvent Ant. I merely wanted to use its XML
structure. In essence, like Jasper2, I am embedding Ant in my tool.
Isn't this what code reuse is all about?
>
>
>>As for making the launcher functionality optional, I am OK with whatever
>>the community wants. But before the community takes it out, let me
>
>
> I don't think the 'community' wants something - and I must admit I had
> very little idea of this going on.
I mentioned the "community" because Bill Barker voiced some reservations
about including commons-launcher.
>
> If _you_ think this is a good idea - you must make a more explicit
> proposal, make sure everyone is aware of this, eventually have a vote
> and add some documentation ( a spec / the proposal / whatever ).
>
This was included in Remy's Tomcat 5 proposal. It was under an item,
IIRC, entitled "Tomcat 5 will use the Launcher used in Sun's JWSDP
product". Since the Tomcat 5 proposal got approved, I assumed it was my
responsibility to put the Launcher into Tomcat 5. I generally don't try
to push features into Tomcat as I have very little spare time.
> I think it is an excelent idea and I would love to see it happen -
> but I don't like the implementation details I'm seeing so far.
>
> Depending on commons-sandbox and reinventing things that are already
> in ant, or doing things slightly differently than ant is doing is not very
> good.
>
Again, I am not reinventing Ant. I am using Ant's functionality only as
an embedded library. In fact, in the Sun JWSDP product, its Launcher did
not use Ant at all and focused only on fixing the DOS problems and
running with a DOS shell. The use of Ant was a nice way to expose the
scripting of the tool instead of burying the scripting in Java code.
> You can add the tasks that you need in tomcat, and 'antlib' is
> very likely to happen for ant1.6 ( the current feeling is that
> ant optional tasks should be split ).
>
>
>
>>1. Make Tomcat 5 startup reliably on Windows (Windows batch scripts are
>> notoriously flaky).
>>2. Emulate the Unix startup on Windows (Windows has no "&" background
>> operator like Unix and you cannot redirect stderr to an output file)
>>3. Run background applications (like Tomcat 5 or GUI applications)
>> without a DOS shell on Windows.
>>4. Eliminate maintainance of 2 sets of scripts (one set for Windows and
>> one set for Unix).
>
>
> And also:
> 5. make tomcat startup easy to automate from ant ( all the test
> frameworks will benefit )
>
> 6. use a well-known format ( <path>, etc ) to describe the env.
>
> 7. reuse open-source code instead of reinventing the wheel ( ant ).
>
> 8. Add extra features - like multiple profiles ( using different targets
> ), ability to easily execute 'pre/post' tasks ( like generating the
> apache config files )
>
> And I can go on - there are many other benefits.
>
> Nobody is arguing ( at least not me ) on the benefits of the idea.
>
>
>
>> From the above list of features, you probably have noticed that the
>>launcher does not add any new features for Unix platforms but really
>>adds a lot of "fit and finish" to Tomcat on Windows.
>
>
> I think it adds quite a bit on both unix and windows.
>
>
>
>>So, I think the basic trade-off with using the launcher vs. scripts is
>>that with the launcher you get a more native looking application on
>>Windows at the price of losing the simplicity of scripts and adding one
>>more dependency to the build.
>
>
> I disagree ( twice )- the bat scripts are not simple, and you _don't_
> have to add dependencies to the build.
>
>
>
>>My recommendation for the community would be to either use the launcher
>>or use scripts and not try to accomodate both. I believe that keeping
>>the old scripts *and* the launcher would cause a lot more maintenance
>>and a more confusion among users.
>
>
> I partially agree - the scripts are well tuned and work, so there's no
> reason to drop them.
They work fine on Unix. On Windows, they work fine *if* you:
1. Always define %CATALINA_HOME% (%0 is not always reliable)
2. You don't have spaces in %CATALINA_HOME% ("for" loops do not work
with spaces on some Windows versions)
3. You don't use any of the %JAVA_OPTS% or %CATALINA_OPTS% environment
varables (batch scripts on some versions of Windows will abort if
there are "=" characters in the environment variable)
4. You don't want stderr to be logged to a file (stderr cannot be
redirected in a DOS shell)
>
> At least in 3.3 we did a lot of simplifications - like 'guessing'
> tomcat.home, etc - so a lot of stuff can be removed.
>
>
>>If the community chooses not to use the launcher, feel free to remove it
>>from the Tomcat 5 build and restore the old scripts.
>
>
> I'm not the 'community' - but I agree with 'choosing' :-)
>
> Make a proposal, have a vote - that's the only way to know what the
> community chooses.
>
The vote to put it in was already made in the Tomcat 5 proposal. So I
think voting on it again is redundant. If someone would like to propose
its removal, I am OK with that and I can even do the removal for them.
Unfortunately, I really don't have much spare time available right now
to push for acceptance of this new piece of code. So, if anyone is
really uncomfortable with this code or they don't think it is ready for
use in Tomcat yet, I will have no hurt feelings if we want it to be
taken out. In fact, I would find that understandable since I have not
been able to find the time to write up the documentation for the tool.
Patrick
> Costin
>
>
>
>>Patrick
>>
>>Costin Manolache wrote:
>>
>>>Patrick ( and all ),
>>>
>>>The 'launcher' is a very good idea - reducing the use of .bat/sh and
>>>having 'keepalive' functionality and a clean startup file are all
>>>great.
>>>
>>>My only requirement is to keep the code clean and minimise
>>>dependencies.
>>>
>>>My understanding of the launcher is that it uses ant file to describe
>>>the paths, conditions, etc. I looked at the code in sandbox - and there
>>>are few issues ( many tasks that duplicate existing functionality in
>>>ant, etc ), and some should be contributed back to ant ( like the
>>>enhancements to Execute ). I support the idea - as long as tomcat code
>>>is kept clean and this is optional.
>>>
>>>Right now we have a mess of launchers / entry points.
>>>
>>>Costin
>>>
>>>
>>>
>>>--
>>>To unsubscribe, e-mail:
>>><mailto:[EMAIL PROTECTED]> For additional
>>>commands, e-mail: <mailto:[EMAIL PROTECTED]>
>>
>
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
________________________________________________________________
Patrick Luby Email: [EMAIL PROTECTED]
Sun Microsystems Phone: 408-276-7471
901 San Antonio Road, USCA14-303
Palo Alto, CA 94303-4900
________________________________________________________________
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
