You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomee.apache.org by David Jencks <da...@yahoo.com> on 2006/10/01 20:16:51 UTC
Binding into global (and other) jndi
Dain has been working on a global jndi implementation that looks
really nice. However the deployment of bindings part of it has
brought up some long-festering architectural worries and perhaps we
are now in a position to deal with them in a systematic manner.
David Blevins pointed out to me a long time ago that one of the core
principles of openejb was that ejb containers should have nothing
transport specific attached to them. This was when I installed a
TSSBean reference in ejb containers to enable binding ejbs into
corba. I pointed out that letting the ejb container know jndi-names
and local-jndi-names had the same problem, and IIRC he agreed that
this was an architectural flaw. In any case, intentionally or not,
he convinced me that both the tssbean link and the jndi names should
not be attached to the ejb container. If you install dain's global
jndi stuff the jndi names now get recycled up to 3 times: for the
openejb proprietary jndi impl, global jndi, and corba. The global
jndi connector binding creates a similar but worse problem for j2ca
connectors, since it tries to bind using only the "name" component of
the abstract name, rather than allowing a specific global jndi name,
and AFAICT it doesn't let you specify which connectors you want to bind.
I think for all of these situations a cleaner runtime solution is a
component that links the thing you want to bind and the binding
context, and includes the name(s) you want to bind under. Currently
this would I think have to be a gbean. This is what Dain implemented
for gbean bindings. So, I'm proposing that bindings for connectors
in global jndi, and ejbs in global jndi, corba, and the openejb jndi,
each be set up by gbeans, each holding the name(s) to bind under and
a reference to the object to be bound. This part is pretty easy to
write.
Slightly harder is deployment: setting up these gbeans. If we modify
our schemas this can be done using NamingBuilders: here they won't be
constructing the components jndi context but rather exposing the
component in various naming systems. I think the really hard part is
figuring out some xml that is manageable to write and expresses the
meaning clearly.
For connectors it's pretty easy, we can just have a repeating element
<global-jndi-name>foo</global-jndi-name>
For ejbs with the current 3 naming systems it's a bit harder. One
possibility would look something like this:
<jndi>
<global/>
<corba>
<tss-link>foo-tss</tss-link>
</corba>
<openejb/>
<remote-name>foo</remote-name>
<local-name>bar</local-name>
</jndi>
where the global, corba, and openejb elements indicate which naming
system to bind to and the names are supplied with remote-name and
local-name. A remote jndi would ignore the local-name elements. You
could have multiple jndi elements to get different bindings in
different naming systems.
To make this extensible the naming system elements would have to be
in a substitution group and extend an abstract element. The ones we
know about now could all be in the same namespace.
Thoughts?
thanks
david jencks
Re: Binding into global (and other) jndi
Posted by Dain Sundstrom <da...@iq80.com>.
The architectural flaw that David pointed out is that the container
knew about the JNDI names. Since we split the container and the
deployment apart in 2.2, the container is no longer aware of the JNDI
names or the TSS stuff. I don't think this addresses all of David's
concerns, but it is definitely an improvement.
Anyway, I think I have a simple idea to address naming. If we use
naming protocols to designate the naming type, we should be able to
have a single string for all existing naming systems. For example:
<jndi-names>
ejbs/foo
rmi://foo
openejb://ejbs/foo
cos-naming://foo-tss
jaxr://foo
</jndi-names>
To process this we can either have actual contexts bound under those
names that handle the binding correctly (this is how rmi naming
works), or we can have a JNDI binding GBeans for the specific
protocols that ignore the unknown protocols.
The nice thing about this solution is it doesn't require any special
knowledge on our users' part.
-dain
Re: Binding into global (and other) jndi
Posted by Dain Sundstrom <da...@iq80.com>.
On Oct 4, 2006, at 10:51 AM, David Blevins wrote:
> On Aug 7, 2006, at 7:38 PM, David Blevins wrote:
>> As far as specifying the names goes, we should still have some
>> sort of strategy for automatically creating the jndi-names for
>> each interfaces for people who don't really care as long as they
>> don't have to type them in. This has been something i've wanted
>> to do for a while. We do it already, but it should be completely
>> configurable at a system or ejb-jar. The explicitly set names
>> would always win over the templated names.
With the new JNDI code, this will be easy to implement. You can add
a gbean that watches for all ejb deployments to start, and then grabs
the relevant information from the deployment, calculates the name and
bind the home (ejb3 interface) to the calculated name.
-dain
Re: Binding into global (and other) jndi
Posted by David Blevins <da...@visi.com>.
On Oct 4, 2006, at 8:27 AM, Matt Hogstrom wrote:
>
> On Oct 1, 2006, at 8:16 PM, David Jencks wrote:
>
>>
>> For connectors it's pretty easy, we can just have a repeating element
>> <global-jndi-name>foo</global-jndi-name>
>>
>> For ejbs with the current 3 naming systems it's a bit harder. One
>> possibility would look something like this:
>>
>> <jndi>
>> <global/>
>> <corba>
>> <tss-link>foo-tss</tss-link>
>> </corba>
>> <openejb/>
>> <remote-name>foo</remote-name>
>> <local-name>bar</local-name>
>> </jndi>
>>
>> where the global, corba, and openejb elements indicate which
>> naming system to bind to and the names are supplied with remote-
>> name and local-name. A remote jndi would ignore the local-name
>> elements. You could have multiple jndi elements to get different
>> bindings in different naming systems.
>
> What if the user specifies a single name that would bind into all
> naming systems by default (as appropriate). If the user chooses to
> be more specific or isolated in the bindings they could through
> some extended XML. So one could use something like:
>
> Bean w/remote and local interfaces.
> <jndi>
> <name>foo</name>
> </jndi>
>
> This would result in the same name being bound into the corba,
> remote and local naming. I'd make global the default context
> although that could be argued.
>
> Perhaps one could simply bind the EJBName into all three contexts
> and not have to specify this property at all.
>
> Not knowing too much about the naming stuff I may be off the mark a
> bit. But I'd make the defaults for no XML the most common so we
> improve simplicity.
Read my proposal as it has the same goal as what you mention; you
just specify the name for the interface and it's bound to all
applicable naming services with that name. The only technical issue
with your proposal is that a bean doesn't have just one interface per
naming service. If you connect to JNDI via the
o.a.openejb.client.LocalInitialContextFactory, for example, you can
lookup a bean via it's remote home, local home, business remote
(ejb3), or business local (ejb3) interfaces. Same would go for
Geronimo's global JNDI.
That said, in an even older email, I also mention this:
On Aug 7, 2006, at 7:38 PM, David Blevins wrote:
> As far as specifying the names goes, we should still have some sort
> of strategy for automatically creating the jndi-names for each
> interfaces for people who don't really care as long as they don't
> have to type them in. This has been something i've wanted to do
> for a while. We do it already, but it should be completely
> configurable at a system or ejb-jar. The explicitly set names
> would always win over the templated names.
Thoughts?
-David
Re: Binding into global (and other) jndi
Posted by Matt Hogstrom <ma...@hogstrom.org>.
On Oct 1, 2006, at 8:16 PM, David Jencks wrote:
>
> For connectors it's pretty easy, we can just have a repeating element
> <global-jndi-name>foo</global-jndi-name>
>
> For ejbs with the current 3 naming systems it's a bit harder. One
> possibility would look something like this:
>
> <jndi>
> <global/>
> <corba>
> <tss-link>foo-tss</tss-link>
> </corba>
> <openejb/>
> <remote-name>foo</remote-name>
> <local-name>bar</local-name>
> </jndi>
>
> where the global, corba, and openejb elements indicate which naming
> system to bind to and the names are supplied with remote-name and
> local-name. A remote jndi would ignore the local-name elements.
> You could have multiple jndi elements to get different bindings in
> different naming systems.
What if the user specifies a single name that would bind into all
naming systems by default (as appropriate). If the user chooses to
be more specific or isolated in the bindings they could through some
extended XML. So one could use something like:
Bean w/remote and local interfaces.
<jndi>
<name>foo</name>
</jndi>
This would result in the same name being bound into the corba, remote
and local naming. I'd make global the default context although that
could be argued.
Perhaps one could simply bind the EJBName into all three contexts and
not have to specify this property at all.
Not knowing too much about the naming stuff I may be off the mark a
bit. But I'd make the defaults for no XML the most common so we
improve simplicity.
Matt Hogstrom
matt@hogstrom.org
Re: Binding into global (and other) jndi
Posted by Dain Sundstrom <da...@iq80.com>.
On Oct 2, 2006, at 1:24 PM, David Blevins wrote:
> <jndi-name interface="some.bean.SomeBeanLocalHomeInterface">some/
> jndi/name/SomeBeanLocalHome</jndi-name>
> <jndi-name interface="some.bean.SomeBeanRemoteHomeInterface">some/
> jndi/name/SomeBeanRemoteHome</jndi-name>
> <jndi-name
> interface="some.bean.SomeBeanRemoteBusinessInterface">some/jndi/
> name/SomeBeanRemoteBizIntfc</jndi-name>
> <jndi-name
> interface="some.bean.SomeBeanLocalBusinessInterface">some/jndi/name/
> SomeBeanLocalBizIntfc</jndi-name>
I never responded to this directly, but I think it is the right
direction to take OpenEJB 3. The only change I'd make it to maybe
rename the tag from jndi-name to binding. My earlier proposal
neatly fits into this model since the name is just a string, so if
you have rmi-naming bound to rmi: you can still bind directly to
rmi:myBean.
-dain
Re: Binding into global (and other) jndi
Posted by David Blevins <da...@visi.com>.
On Oct 2, 2006, at 10:00 AM, David Blevins wrote:
>
> On Oct 1, 2006, at 11:16 AM, David Jencks wrote:
>> For ejbs with the current 3 naming systems it's a bit harder. One
>> possibility would look something like this:
>>
>> <jndi>
>> <global/>
>> <corba>
>> <tss-link>foo-tss</tss-link>
>> </corba>
>> <openejb/>
>> <remote-name>foo</remote-name>
>> <local-name>bar</local-name>
>> </jndi>
>>
>> where the global, corba, and openejb elements indicate which
>> naming system to bind to and the names are supplied with remote-
>> name and local-name. A remote jndi would ignore the local-name
>> elements. You could have multiple jndi elements to get different
>> bindings in different naming systems.
>>
>> To make this extensible the naming system elements would have to
>> be in a substitution group and extend an abstract element. The
>> ones we know about now could all be in the same namespace.
>>
>>
>> Thoughts?
>
> There was a discussion on this in context of OpenEJB 3. It was
> short and no real conclusion was made, but let me see if I can't
> dig it up.
>
Alright, here is that discussion http://marc.theaimsgroup.com/?
l=openejb-development&m=115500473129558&w=2
Dunno how much relates, but it's worth reading the tail end at least.
In that I had proposed essentially:
<jndi-name interface="some.bean.SomeBeanLocalHomeInterface">some/
jndi/name/SomeBeanLocalHome</jndi-name>
<jndi-name interface="some.bean.SomeBeanRemoteHomeInterface">some/
jndi/name/SomeBeanRemoteHome</jndi-name>
<jndi-name
interface="some.bean.SomeBeanRemoteBusinessInterface">some/jndi/name/
SomeBeanRemoteBizIntfc</jndi-name>
<jndi-name
interface="some.bean.SomeBeanLocalBusinessInterface">some/jndi/name/
SomeBeanLocalBizIntfc</jndi-name>
The only wrapper element would be the bean definition, really don't
need a "<jndi>" wrapper element. Though we could have one.
A partial motivation for 'interface' as an attribute is that in the
ejb3 schema a bean can have unlimited number of business interfaces.
Not sure if this was really the intention -- we'll find out at
certification time I guess.
I thought I had an attribute in there that specified the consuming
protocol ( <jndi-name protocol="foo"), but I guess I did not add
that. I guess I was thinking that you could figure out what to do
with the interface based on the data in ejb-jar (service-endpoint,
remote, local, etc) and in the interface class itself (annotations,
super interface types).
Though it may be good to have an optional "protocol='foo'" attribute
where the lack of it implied "all available and applicable
protocols". Just thinking it would be a bummer to have to supply
jndi names for the corba, openejb remote protocol, and internal
global JNDI trees for a plain remote interface, for example, as all
three names could really be the same -- you'd probably only want the
option to make them different.
Thoughts on that basic premise?
Anyway, lots of things we could do here. I threw up this wiki page
so we could brain storm more:
http://cwiki.apache.org/confluence/display/OPENEJB/JNDI+Name+Config
Add any options or variations you think may be attractive.
-David
Re: Binding into global (and other) jndi
Posted by David Blevins <da...@visi.com>.
On Oct 1, 2006, at 11:16 AM, David Jencks wrote:
> Dain has been working on a global jndi implementation that looks
> really nice. However the deployment of bindings part of it has
> brought up some long-festering architectural worries and perhaps we
> are now in a position to deal with them in a systematic manner.
>
> David Blevins pointed out to me a long time ago that one of the
> core principles of openejb was that ejb containers should have
> nothing transport specific attached to them. This was when I
> installed a TSSBean reference in ejb containers to enable binding
> ejbs into corba. I pointed out that letting the ejb container know
> jndi-names and local-jndi-names had the same problem, and IIRC he
> agreed that this was an architectural flaw. In any case,
> intentionally or not, he convinced me that both the tssbean link
> and the jndi names should not be attached to the ejb container. If
> you install dain's global jndi stuff the jndi names now get
> recycled up to 3 times: for the openejb proprietary jndi impl,
> global jndi, and corba. The global jndi connector binding creates
> a similar but worse problem for j2ca connectors, since it tries to
> bind using only the "name" component of the abstract name, rather
> than allowing a specific global jndi name, and AFAICT it doesn't
> let you specify which connectors you want to bind.
>
> I think for all of these situations a cleaner runtime solution is a
> component that links the thing you want to bind and the binding
> context, and includes the name(s) you want to bind under.
> Currently this would I think have to be a gbean. This is what Dain
> implemented for gbean bindings. So, I'm proposing that bindings
> for connectors in global jndi, and ejbs in global jndi, corba, and
> the openejb jndi, each be set up by gbeans, each holding the name
> (s) to bind under and a reference to the object to be bound. This
> part is pretty easy to write.
>
> Slightly harder is deployment: setting up these gbeans. If we
> modify our schemas this can be done using NamingBuilders: here they
> won't be constructing the components jndi context but rather
> exposing the component in various naming systems. I think the
> really hard part is figuring out some xml that is manageable to
> write and expresses the meaning clearly.
>
> For connectors it's pretty easy, we can just have a repeating element
> <global-jndi-name>foo</global-jndi-name>
>
> For ejbs with the current 3 naming systems it's a bit harder. One
> possibility would look something like this:
>
> <jndi>
> <global/>
> <corba>
> <tss-link>foo-tss</tss-link>
> </corba>
> <openejb/>
> <remote-name>foo</remote-name>
> <local-name>bar</local-name>
> </jndi>
>
> where the global, corba, and openejb elements indicate which naming
> system to bind to and the names are supplied with remote-name and
> local-name. A remote jndi would ignore the local-name elements.
> You could have multiple jndi elements to get different bindings in
> different naming systems.
>
> To make this extensible the naming system elements would have to be
> in a substitution group and extend an abstract element. The ones
> we know about now could all be in the same namespace.
>
>
> Thoughts?
There was a discussion on this in context of OpenEJB 3. It was short
and no real conclusion was made, but let me see if I can't dig it up.
-David
>
> thanks
> david jencks
>
Re: Binding into global (and other) jndi
Posted by David Blevins <da...@visi.com>.
On Oct 1, 2006, at 11:16 AM, David Jencks wrote:
> Dain has been working on a global jndi implementation that looks
> really nice. However the deployment of bindings part of it has
> brought up some long-festering architectural worries and perhaps we
> are now in a position to deal with them in a systematic manner.
>
> David Blevins pointed out to me a long time ago that one of the
> core principles of openejb was that ejb containers should have
> nothing transport specific attached to them. This was when I
> installed a TSSBean reference in ejb containers to enable binding
> ejbs into corba. I pointed out that letting the ejb container know
> jndi-names and local-jndi-names had the same problem, and IIRC he
> agreed that this was an architectural flaw. In any case,
> intentionally or not, he convinced me that both the tssbean link
> and the jndi names should not be attached to the ejb container. If
> you install dain's global jndi stuff the jndi names now get
> recycled up to 3 times: for the openejb proprietary jndi impl,
> global jndi, and corba. The global jndi connector binding creates
> a similar but worse problem for j2ca connectors, since it tries to
> bind using only the "name" component of the abstract name, rather
> than allowing a specific global jndi name, and AFAICT it doesn't
> let you specify which connectors you want to bind.
>
> I think for all of these situations a cleaner runtime solution is a
> component that links the thing you want to bind and the binding
> context, and includes the name(s) you want to bind under.
> Currently this would I think have to be a gbean. This is what Dain
> implemented for gbean bindings. So, I'm proposing that bindings
> for connectors in global jndi, and ejbs in global jndi, corba, and
> the openejb jndi, each be set up by gbeans, each holding the name
> (s) to bind under and a reference to the object to be bound. This
> part is pretty easy to write.
>
> Slightly harder is deployment: setting up these gbeans. If we
> modify our schemas this can be done using NamingBuilders: here they
> won't be constructing the components jndi context but rather
> exposing the component in various naming systems. I think the
> really hard part is figuring out some xml that is manageable to
> write and expresses the meaning clearly.
>
> For connectors it's pretty easy, we can just have a repeating element
> <global-jndi-name>foo</global-jndi-name>
>
> For ejbs with the current 3 naming systems it's a bit harder. One
> possibility would look something like this:
>
> <jndi>
> <global/>
> <corba>
> <tss-link>foo-tss</tss-link>
> </corba>
> <openejb/>
> <remote-name>foo</remote-name>
> <local-name>bar</local-name>
> </jndi>
>
> where the global, corba, and openejb elements indicate which naming
> system to bind to and the names are supplied with remote-name and
> local-name. A remote jndi would ignore the local-name elements.
> You could have multiple jndi elements to get different bindings in
> different naming systems.
>
> To make this extensible the naming system elements would have to be
> in a substitution group and extend an abstract element. The ones
> we know about now could all be in the same namespace.
>
>
> Thoughts?
There was a discussion on this in context of OpenEJB 3. It was short
and no real conclusion was made, but let me see if I can't dig it up.
-David
>
> thanks
> david jencks
>
Re: Binding into global (and other) jndi
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 10/1/06, David Jencks <da...@yahoo.com> wrote:
> Thoughts?
It's so complicated that the only thing I want is to see it working.
Unit tests will do the thinking ;-)
Jacek
--
Jacek Laskowski
http://www.laskowski.net.pl
Re: Binding into global (and other) jndi
Posted by David Jencks <da...@yahoo.com>.
FWIW I've removed the TSSBean reference from the ejb containers and
made a TSSLink and TSSLinkBuilder that installs them as part of
separating the corba related classes into a separate jar
(OPENEJB-280). The jndi names and local-jndi-names are unfortunately
still attached to the ejb container.
thanks
david jencks
On Oct 1, 2006, at 11:16 AM, David Jencks wrote:
> Dain has been working on a global jndi implementation that looks
> really nice. However the deployment of bindings part of it has
> brought up some long-festering architectural worries and perhaps we
> are now in a position to deal with them in a systematic manner.
>
> David Blevins pointed out to me a long time ago that one of the
> core principles of openejb was that ejb containers should have
> nothing transport specific attached to them. This was when I
> installed a TSSBean reference in ejb containers to enable binding
> ejbs into corba. I pointed out that letting the ejb container know
> jndi-names and local-jndi-names had the same problem, and IIRC he
> agreed that this was an architectural flaw. In any case,
> intentionally or not, he convinced me that both the tssbean link
> and the jndi names should not be attached to the ejb container. If
> you install dain's global jndi stuff the jndi names now get
> recycled up to 3 times: for the openejb proprietary jndi impl,
> global jndi, and corba. The global jndi connector binding creates
> a similar but worse problem for j2ca connectors, since it tries to
> bind using only the "name" component of the abstract name, rather
> than allowing a specific global jndi name, and AFAICT it doesn't
> let you specify which connectors you want to bind.
>
> I think for all of these situations a cleaner runtime solution is a
> component that links the thing you want to bind and the binding
> context, and includes the name(s) you want to bind under.
> Currently this would I think have to be a gbean. This is what Dain
> implemented for gbean bindings. So, I'm proposing that bindings
> for connectors in global jndi, and ejbs in global jndi, corba, and
> the openejb jndi, each be set up by gbeans, each holding the name
> (s) to bind under and a reference to the object to be bound. This
> part is pretty easy to write.
>
> Slightly harder is deployment: setting up these gbeans. If we
> modify our schemas this can be done using NamingBuilders: here they
> won't be constructing the components jndi context but rather
> exposing the component in various naming systems. I think the
> really hard part is figuring out some xml that is manageable to
> write and expresses the meaning clearly.
>
> For connectors it's pretty easy, we can just have a repeating element
> <global-jndi-name>foo</global-jndi-name>
>
> For ejbs with the current 3 naming systems it's a bit harder. One
> possibility would look something like this:
>
> <jndi>
> <global/>
> <corba>
> <tss-link>foo-tss</tss-link>
> </corba>
> <openejb/>
> <remote-name>foo</remote-name>
> <local-name>bar</local-name>
> </jndi>
>
> where the global, corba, and openejb elements indicate which naming
> system to bind to and the names are supplied with remote-name and
> local-name. A remote jndi would ignore the local-name elements.
> You could have multiple jndi elements to get different bindings in
> different naming systems.
>
> To make this extensible the naming system elements would have to be
> in a substitution group and extend an abstract element. The ones
> we know about now could all be in the same namespace.
>
>
> Thoughts?
>
> thanks
> david jencks
>
Re: Binding into global (and other) jndi
Posted by David Jencks <da...@yahoo.com>.
FWIW I've removed the TSSBean reference from the ejb containers and
made a TSSLink and TSSLinkBuilder that installs them as part of
separating the corba related classes into a separate jar
(OPENEJB-280). The jndi names and local-jndi-names are unfortunately
still attached to the ejb container.
thanks
david jencks
On Oct 1, 2006, at 11:16 AM, David Jencks wrote:
> Dain has been working on a global jndi implementation that looks
> really nice. However the deployment of bindings part of it has
> brought up some long-festering architectural worries and perhaps we
> are now in a position to deal with them in a systematic manner.
>
> David Blevins pointed out to me a long time ago that one of the
> core principles of openejb was that ejb containers should have
> nothing transport specific attached to them. This was when I
> installed a TSSBean reference in ejb containers to enable binding
> ejbs into corba. I pointed out that letting the ejb container know
> jndi-names and local-jndi-names had the same problem, and IIRC he
> agreed that this was an architectural flaw. In any case,
> intentionally or not, he convinced me that both the tssbean link
> and the jndi names should not be attached to the ejb container. If
> you install dain's global jndi stuff the jndi names now get
> recycled up to 3 times: for the openejb proprietary jndi impl,
> global jndi, and corba. The global jndi connector binding creates
> a similar but worse problem for j2ca connectors, since it tries to
> bind using only the "name" component of the abstract name, rather
> than allowing a specific global jndi name, and AFAICT it doesn't
> let you specify which connectors you want to bind.
>
> I think for all of these situations a cleaner runtime solution is a
> component that links the thing you want to bind and the binding
> context, and includes the name(s) you want to bind under.
> Currently this would I think have to be a gbean. This is what Dain
> implemented for gbean bindings. So, I'm proposing that bindings
> for connectors in global jndi, and ejbs in global jndi, corba, and
> the openejb jndi, each be set up by gbeans, each holding the name
> (s) to bind under and a reference to the object to be bound. This
> part is pretty easy to write.
>
> Slightly harder is deployment: setting up these gbeans. If we
> modify our schemas this can be done using NamingBuilders: here they
> won't be constructing the components jndi context but rather
> exposing the component in various naming systems. I think the
> really hard part is figuring out some xml that is manageable to
> write and expresses the meaning clearly.
>
> For connectors it's pretty easy, we can just have a repeating element
> <global-jndi-name>foo</global-jndi-name>
>
> For ejbs with the current 3 naming systems it's a bit harder. One
> possibility would look something like this:
>
> <jndi>
> <global/>
> <corba>
> <tss-link>foo-tss</tss-link>
> </corba>
> <openejb/>
> <remote-name>foo</remote-name>
> <local-name>bar</local-name>
> </jndi>
>
> where the global, corba, and openejb elements indicate which naming
> system to bind to and the names are supplied with remote-name and
> local-name. A remote jndi would ignore the local-name elements.
> You could have multiple jndi elements to get different bindings in
> different naming systems.
>
> To make this extensible the naming system elements would have to be
> in a substitution group and extend an abstract element. The ones
> we know about now could all be in the same namespace.
>
>
> Thoughts?
>
> thanks
> david jencks
>