You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by David Jencks <da...@yahoo.com> on 2005/11/19 00:35:01 UTC
Proposed changes to plan elements related to classloaders.
It's become apparent recently that some of the elements in our plans
related to classloading are a bit confusing. In particular, there is
an include element that no one is sure what is for and is not used, and
a similarly named import element that is like the parentId, only better
:-). Also the lists of special classes for the classloader are in
between the import and dependency elements.
I'd like to change the schema for all plans to use this:
<xs:group name="classloader-infoGroup">
<xs:sequence>
<xs:element ref="sys:parent" minOccurs="0"
maxOccurs="unbounded"/>
<!-- <xs:element name="include"
type="sys:dependencyType" minOccurs="0" maxOccurs="unbounded"/>-->
<xs:element ref="sys:dependency" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="sys:hidden-classes" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="sys:non-overridable-classes" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:group>
The differences are that:
import is renamed parent. This seems less confusing to me. I can
support backwards compatibility in most plans, although perhaps not
plain gbean plans.
include is removed.
the class lists are moved to the end. This makes more sense to me, in
that first we have the info on what goes into the current classloader
in the way of parents and contents, and then we have the modifications
to that list.
Comments?
thanks
david jencks
Re: Proposed changes to plan elements related to classloaders.
Posted by Dain Sundstrom <da...@iq80.com>.
On Nov 18, 2005, at 4:24 PM, David Jencks wrote:
> On Nov 18, 2005, at 4:17 PM, Aaron Mulder wrote:
>
>> On 11/18/05, David Jencks <da...@yahoo.com> wrote:
>>> Dain has a plan that I hope he will explain soon that should make
>>> all
>>> of these elements identical in form, name, and function.
>>> Dependency is
>>> what maven calls them and I don't see a strong reason to change
>>> their
>>> name.
>>
>> If there's a plan on the way, why are we discussing this before we
>> hear the plan? Dain, speak up, man!
>
> IIUC his plan requires maven 2 so won't be feasible for geronimo 1.0
I'm going to try to type it up tomorrow (traveling tomorrow so should
have free time on the airplane). One of the parts of the idea is to
use maven-artifact from maven 2 to manage the repository and to help
with class loader building, so staying close to the maven 2 xml
format will help.
-dain
Re: Proposed changes to plan elements related to classloaders.
Posted by David Jencks <da...@yahoo.com>.
On Nov 18, 2005, at 4:17 PM, Aaron Mulder wrote:
> On 11/18/05, David Jencks <da...@yahoo.com> wrote:
>> Dain has a plan that I hope he will explain soon that should make all
>> of these elements identical in form, name, and function. Dependency
>> is
>> what maven calls them and I don't see a strong reason to change their
>> name.
>
> If there's a plan on the way, why are we discussing this before we
> hear the plan? Dain, speak up, man!
IIUC his plan requires maven 2 so won't be feasible for geronimo 1.0
david jencks
>
> Aaron
>
>>> On 11/18/05, David Jencks <da...@yahoo.com> wrote:
>>>> It's become apparent recently that some of the elements in our plans
>>>> related to classloading are a bit confusing. In particular, there
>>>> is
>>>> an include element that no one is sure what is for and is not used,
>>>> and
>>>> a similarly named import element that is like the parentId, only
>>>> better
>>>> :-). Also the lists of special classes for the classloader are in
>>>> between the import and dependency elements.
>>>>
>>>> I'd like to change the schema for all plans to use this:
>>>>
>>>> <xs:group name="classloader-infoGroup">
>>>> <xs:sequence>
>>>> <xs:element ref="sys:parent" minOccurs="0"
>>>> maxOccurs="unbounded"/>
>>>> <!-- <xs:element name="include"
>>>> type="sys:dependencyType" minOccurs="0" maxOccurs="unbounded"/>-->
>>>> <xs:element ref="sys:dependency" minOccurs="0"
>>>> maxOccurs="unbounded"/>
>>>> <xs:element ref="sys:hidden-classes" minOccurs="0"
>>>> maxOccurs="unbounded"/>
>>>> <xs:element ref="sys:non-overridable-classes"
>>>> minOccurs="0"
>>>> maxOccurs="unbounded"/>
>>>> </xs:sequence>
>>>> </xs:group>
>>>>
>>>>
>>>> The differences are that:
>>>>
>>>> import is renamed parent. This seems less confusing to me. I can
>>>> support backwards compatibility in most plans, although perhaps not
>>>> plain gbean plans.
>>>>
>>>> include is removed.
>>>>
>>>> the class lists are moved to the end. This makes more sense to me,
>>>> in
>>>> that first we have the info on what goes into the current
>>>> classloader
>>>> in the way of parents and contents, and then we have the
>>>> modifications
>>>> to that list.
>>>>
>>>> Comments?
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>
>>>
>>
>>
>
Re: Proposed changes to plan elements related to classloaders.
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
On 11/18/05, David Jencks <da...@yahoo.com> wrote:
> Dain has a plan that I hope he will explain soon that should make all
> of these elements identical in form, name, and function. Dependency is
> what maven calls them and I don't see a strong reason to change their
> name.
If there's a plan on the way, why are we discussing this before we
hear the plan? Dain, speak up, man!
Aaron
> > On 11/18/05, David Jencks <da...@yahoo.com> wrote:
> >> It's become apparent recently that some of the elements in our plans
> >> related to classloading are a bit confusing. In particular, there is
> >> an include element that no one is sure what is for and is not used,
> >> and
> >> a similarly named import element that is like the parentId, only
> >> better
> >> :-). Also the lists of special classes for the classloader are in
> >> between the import and dependency elements.
> >>
> >> I'd like to change the schema for all plans to use this:
> >>
> >> <xs:group name="classloader-infoGroup">
> >> <xs:sequence>
> >> <xs:element ref="sys:parent" minOccurs="0"
> >> maxOccurs="unbounded"/>
> >> <!-- <xs:element name="include"
> >> type="sys:dependencyType" minOccurs="0" maxOccurs="unbounded"/>-->
> >> <xs:element ref="sys:dependency" minOccurs="0"
> >> maxOccurs="unbounded"/>
> >> <xs:element ref="sys:hidden-classes" minOccurs="0"
> >> maxOccurs="unbounded"/>
> >> <xs:element ref="sys:non-overridable-classes"
> >> minOccurs="0"
> >> maxOccurs="unbounded"/>
> >> </xs:sequence>
> >> </xs:group>
> >>
> >>
> >> The differences are that:
> >>
> >> import is renamed parent. This seems less confusing to me. I can
> >> support backwards compatibility in most plans, although perhaps not
> >> plain gbean plans.
> >>
> >> include is removed.
> >>
> >> the class lists are moved to the end. This makes more sense to me, in
> >> that first we have the info on what goes into the current classloader
> >> in the way of parents and contents, and then we have the modifications
> >> to that list.
> >>
> >> Comments?
> >>
> >> thanks
> >> david jencks
> >>
> >>
> >
>
>
Re: Proposed changes to plan elements related to classloaders.
Posted by David Jencks <da...@yahoo.com>.
On Nov 18, 2005, at 3:58 PM, Aaron Mulder wrote:
> This sounds great!
>
> Please further split out the data types so they're not all
> dependencyType (even though they all have URIs or maven chunks).
> Let's have one type where URI means a configID, and a separate type
> where URI means an index into the local repository. Maybe they could
> just be called configIDType and repositoryEntryType. Even if the
> contents are the same, they have different meanings and we can
> document them accordingly in the schema.
I'd be willing to change the type name to something more neutral, but
not to duplicate it. We can document the elements rather than the
types. Considering the likely future I'd rather leave it
dependencyType.
>
> Also, "parent" sounds pretty clear as to what it is, but "dependency"
> doesn't necessarily (isn't a parent kind of a dependency?). It might
> be nice to try to think of a name to use instead of "dependency" that
> says "code to add to the classloader for the current module", like
> maybe "additional-jar"?
Dain has a plan that I hope he will explain soon that should make all
of these elements identical in form, name, and function. Dependency is
what maven calls them and I don't see a strong reason to change their
name.
thanks
david jencks
>
> Thanks,
> Aaron
>
> On 11/18/05, David Jencks <da...@yahoo.com> wrote:
>> It's become apparent recently that some of the elements in our plans
>> related to classloading are a bit confusing. In particular, there is
>> an include element that no one is sure what is for and is not used,
>> and
>> a similarly named import element that is like the parentId, only
>> better
>> :-). Also the lists of special classes for the classloader are in
>> between the import and dependency elements.
>>
>> I'd like to change the schema for all plans to use this:
>>
>> <xs:group name="classloader-infoGroup">
>> <xs:sequence>
>> <xs:element ref="sys:parent" minOccurs="0"
>> maxOccurs="unbounded"/>
>> <!-- <xs:element name="include"
>> type="sys:dependencyType" minOccurs="0" maxOccurs="unbounded"/>-->
>> <xs:element ref="sys:dependency" minOccurs="0"
>> maxOccurs="unbounded"/>
>> <xs:element ref="sys:hidden-classes" minOccurs="0"
>> maxOccurs="unbounded"/>
>> <xs:element ref="sys:non-overridable-classes"
>> minOccurs="0"
>> maxOccurs="unbounded"/>
>> </xs:sequence>
>> </xs:group>
>>
>>
>> The differences are that:
>>
>> import is renamed parent. This seems less confusing to me. I can
>> support backwards compatibility in most plans, although perhaps not
>> plain gbean plans.
>>
>> include is removed.
>>
>> the class lists are moved to the end. This makes more sense to me, in
>> that first we have the info on what goes into the current classloader
>> in the way of parents and contents, and then we have the modifications
>> to that list.
>>
>> Comments?
>>
>> thanks
>> david jencks
>>
>>
>
Re: Proposed changes to plan elements related to classloaders.
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
This sounds great!
Please further split out the data types so they're not all
dependencyType (even though they all have URIs or maven chunks).
Let's have one type where URI means a configID, and a separate type
where URI means an index into the local repository. Maybe they could
just be called configIDType and repositoryEntryType. Even if the
contents are the same, they have different meanings and we can
document them accordingly in the schema.
Also, "parent" sounds pretty clear as to what it is, but "dependency"
doesn't necessarily (isn't a parent kind of a dependency?). It might
be nice to try to think of a name to use instead of "dependency" that
says "code to add to the classloader for the current module", like
maybe "additional-jar"?
Thanks,
Aaron
On 11/18/05, David Jencks <da...@yahoo.com> wrote:
> It's become apparent recently that some of the elements in our plans
> related to classloading are a bit confusing. In particular, there is
> an include element that no one is sure what is for and is not used, and
> a similarly named import element that is like the parentId, only better
> :-). Also the lists of special classes for the classloader are in
> between the import and dependency elements.
>
> I'd like to change the schema for all plans to use this:
>
> <xs:group name="classloader-infoGroup">
> <xs:sequence>
> <xs:element ref="sys:parent" minOccurs="0"
> maxOccurs="unbounded"/>
> <!-- <xs:element name="include"
> type="sys:dependencyType" minOccurs="0" maxOccurs="unbounded"/>-->
> <xs:element ref="sys:dependency" minOccurs="0"
> maxOccurs="unbounded"/>
> <xs:element ref="sys:hidden-classes" minOccurs="0"
> maxOccurs="unbounded"/>
> <xs:element ref="sys:non-overridable-classes" minOccurs="0"
> maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:group>
>
>
> The differences are that:
>
> import is renamed parent. This seems less confusing to me. I can
> support backwards compatibility in most plans, although perhaps not
> plain gbean plans.
>
> include is removed.
>
> the class lists are moved to the end. This makes more sense to me, in
> that first we have the info on what goes into the current classloader
> in the way of parents and contents, and then we have the modifications
> to that list.
>
> Comments?
>
> thanks
> david jencks
>
>
Re: Proposed changes to plan elements related to classloaders.
Posted by David Jencks <da...@yahoo.com>.
I've done some more historical research and now want to keep the
include element and am inclined to keep the import element with its
current name. Discussion inline.
On Nov 18, 2005, at 3:35 PM, David Jencks wrote:
> It's become apparent recently that some of the elements in our plans
> related to classloading are a bit confusing. In particular, there is
> an include element that no one is sure what is for and is not used,
> and a similarly named import element that is like the parentId, only
> better :-). Also the lists of special classes for the classloader are
> in between the import and dependency elements.
>
> I'd like to change the schema for all plans to use this:
>
> <xs:group name="classloader-infoGroup">
> <xs:sequence>
> <xs:element ref="sys:parent" minOccurs="0"
> maxOccurs="unbounded"/>
> <!-- <xs:element name="include"
> type="sys:dependencyType" minOccurs="0" maxOccurs="unbounded"/>-->
> <xs:element ref="sys:dependency" minOccurs="0"
> maxOccurs="unbounded"/>
> <xs:element ref="sys:hidden-classes" minOccurs="0"
> maxOccurs="unbounded"/>
> <xs:element ref="sys:non-overridable-classes"
> minOccurs="0" maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:group>
Now I want:
<xs:group name="classloader-infoGroup">
<xs:sequence>
<xs:element ref="sys:import" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="include" type="sys:dependencyType"
minOccurs="0" maxOccurs="unbounded"/> <!-- this should be a ref also
-->
<xs:element ref="sys:dependency" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="sys:hidden-classes" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="sys:non-overridable-classes" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:group>
>
>
> The differences are that:
>
> import is renamed parent. This seems less confusing to me. I can
> support backwards compatibility in most plans, although perhaps not
> plain gbean plans.
Reasons for keeping import:
1. We have already put out M5 using import, and I remember promising
that we wouldn't change the xml incompatibly.
2. Apparently the term import is used by osgi for a similar purpose.
>
> include is removed.
Reasons for keeping include:
What include does is to copy the contents of the dependency into the
car file. This is not particularly useful for server side
configurations that depend on other configurations, and really need a
repository. However, its really intended for building small executable
jars that include everything they need to run. For instance the
shutdown jar would be an ideal candidate for this. We can include as
much kernel, gbeans, etc as we need and still fit it all into a single
jar that can be moved around away from the repo and still work without
reliance on fragile mechanisms such as manifest classpath.
>
> the class lists are moved to the end. This makes more sense to me, in
> that first we have the info on what goes into the current classloader
> in the way of parents and contents, and then we have the modifications
> to that list.
I still want to do this.
thanks
david jencks
>
> Comments?
>
> thanks
> david jencks
>
Re: Proposed changes to plan elements related to classloaders.
Posted by Jeff Genender <jg...@apache.org>.
Yes! ;-)
David Jencks wrote:
>
> On Nov 18, 2005, at 4:05 PM, Jeff Genender wrote:
>
>> There is a JIRA issue I re-opened on those classes tags. They are
>> duped in Tomcat and Jetty. I would like to see them at the web
>> builder level.
>
> I noticed they were missing from the generic schema. My local changes
> use the same group everywhere including web-builder, so this would fix
> your issue?
>
> thanks
> david jencks
>
>>
>> David Jencks wrote:
>>> It's become apparent recently that some of the elements in our plans
>>> related to classloading are a bit confusing. In particular, there is
>>> an include element that no one is sure what is for and is not used,
>>> and a similarly named import element that is like the parentId, only
>>> better :-). Also the lists of special classes for the classloader
>>> are in between the import and dependency elements.
>>> I'd like to change the schema for all plans to use this:
>>> <xs:group name="classloader-infoGroup">
>>> <xs:sequence>
>>> <xs:element ref="sys:parent" minOccurs="0"
>>> maxOccurs="unbounded"/>
>>> <!-- <xs:element name="include"
>>> type="sys:dependencyType" minOccurs="0" maxOccurs="unbounded"/>-->
>>> <xs:element ref="sys:dependency" minOccurs="0"
>>> maxOccurs="unbounded"/>
>>> <xs:element ref="sys:hidden-classes" minOccurs="0"
>>> maxOccurs="unbounded"/>
>>> <xs:element ref="sys:non-overridable-classes"
>>> minOccurs="0" maxOccurs="unbounded"/>
>>> </xs:sequence>
>>> </xs:group>
>>> The differences are that:
>>> import is renamed parent. This seems less confusing to me. I can
>>> support backwards compatibility in most plans, although perhaps not
>>> plain gbean plans.
>>> include is removed.
>>> the class lists are moved to the end. This makes more sense to me,
>>> in that first we have the info on what goes into the current
>>> classloader in the way of parents and contents, and then we have the
>>> modifications to that list.
>>> Comments?
>>> thanks
>>> david jencks
>>
Re: Proposed changes to plan elements related to classloaders.
Posted by David Jencks <da...@yahoo.com>.
On Nov 18, 2005, at 4:05 PM, Jeff Genender wrote:
> There is a JIRA issue I re-opened on those classes tags. They are
> duped in Tomcat and Jetty. I would like to see them at the web
> builder level.
I noticed they were missing from the generic schema. My local changes
use the same group everywhere including web-builder, so this would fix
your issue?
thanks
david jencks
>
> David Jencks wrote:
>> It's become apparent recently that some of the elements in our plans
>> related to classloading are a bit confusing. In particular, there is
>> an include element that no one is sure what is for and is not used,
>> and a similarly named import element that is like the parentId, only
>> better :-). Also the lists of special classes for the classloader
>> are in between the import and dependency elements.
>> I'd like to change the schema for all plans to use this:
>> <xs:group name="classloader-infoGroup">
>> <xs:sequence>
>> <xs:element ref="sys:parent" minOccurs="0"
>> maxOccurs="unbounded"/>
>> <!-- <xs:element name="include"
>> type="sys:dependencyType" minOccurs="0" maxOccurs="unbounded"/>-->
>> <xs:element ref="sys:dependency" minOccurs="0"
>> maxOccurs="unbounded"/>
>> <xs:element ref="sys:hidden-classes" minOccurs="0"
>> maxOccurs="unbounded"/>
>> <xs:element ref="sys:non-overridable-classes"
>> minOccurs="0" maxOccurs="unbounded"/>
>> </xs:sequence>
>> </xs:group>
>> The differences are that:
>> import is renamed parent. This seems less confusing to me. I can
>> support backwards compatibility in most plans, although perhaps not
>> plain gbean plans.
>> include is removed.
>> the class lists are moved to the end. This makes more sense to me,
>> in that first we have the info on what goes into the current
>> classloader in the way of parents and contents, and then we have the
>> modifications to that list.
>> Comments?
>> thanks
>> david jencks
>
Re: Proposed changes to plan elements related to classloaders.
Posted by Jeff Genender <jg...@apache.org>.
There is a JIRA issue I re-opened on those classes tags. They are duped
in Tomcat and Jetty. I would like to see them at the web builder level.
David Jencks wrote:
> It's become apparent recently that some of the elements in our plans
> related to classloading are a bit confusing. In particular, there is an
> include element that no one is sure what is for and is not used, and a
> similarly named import element that is like the parentId, only better
> :-). Also the lists of special classes for the classloader are in
> between the import and dependency elements.
>
> I'd like to change the schema for all plans to use this:
>
> <xs:group name="classloader-infoGroup">
> <xs:sequence>
> <xs:element ref="sys:parent" minOccurs="0"
> maxOccurs="unbounded"/>
> <!-- <xs:element name="include"
> type="sys:dependencyType" minOccurs="0" maxOccurs="unbounded"/>-->
> <xs:element ref="sys:dependency" minOccurs="0"
> maxOccurs="unbounded"/>
> <xs:element ref="sys:hidden-classes" minOccurs="0"
> maxOccurs="unbounded"/>
> <xs:element ref="sys:non-overridable-classes" minOccurs="0"
> maxOccurs="unbounded"/>
> </xs:sequence>
> </xs:group>
>
>
> The differences are that:
>
> import is renamed parent. This seems less confusing to me. I can
> support backwards compatibility in most plans, although perhaps not
> plain gbean plans.
>
> include is removed.
>
> the class lists are moved to the end. This makes more sense to me, in
> that first we have the info on what goes into the current classloader in
> the way of parents and contents, and then we have the modifications to
> that list.
>
> Comments?
>
> thanks
> david jencks