I think I have written something confusing.
The intention of my remark was that somebody might have thought that
the new xml spec have been used but that this was not the case.
Effectively what you have written in your message.

On 9/28/06, Rick McGuire <[EMAIL PROTECTED]> wrote:
Heinz Drews wrote:
> The endorsed dirs are prepended to the bootclass path.
> Correcting the current situation should not cause classloading
> problems.  It might cause a problem because now the newer of the xml
> specs are used instead of the one contained in the JRE.
Geronimo was already placing jars in the endorsed dir with the intention
that they
be picked up that way.  It was a bug that it wasn't.


>
> If we use a mechanism like the one used by Eclipse the spawning of a
> new JVM should not  be too complicated.  Therefore this should be
> still considered as an option.
>
> Heinz
>
> On 9/28/06, Paul McMahan <[EMAIL PROTECTED]> wrote:
>> On 9/28/06, Rick McGuire <[EMAIL PROTECTED]> wrote:
>> > I should be possible to accomplish what Daemon is doing by forking
>> a new
>> > process to run the actual server, but I'm not sure that's really a
>> good
>> > idea.
>> >
>> > So, that's the basics.  Right now, I'm working on fixing up the
>> scripts
>> > and removing the non-function property setting from Daemon.  Does this
>> > seem like the correct approach?
>>
>> I agree that forking the jvm is probably not a good idea because it
>> complicates the startup process.  Fixing the script instead seems like
>> a cleaner approach.  My only concern is that Geronimo's classloader
>> may not be implemented in such a way that would give precedence to the
>> classes loaded in this way, which seems contrary to my (limited)
>> understanding of the JVM spec.  I haven't tested to see if that's the
>> case.
>>
>> Paul
>>
>


Reply via email to