You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Sergey Beryozkin <sb...@gmail.com> on 2012/04/02 21:54:06 UTC
Blueprint schema blocks nested static class names
Hi,
The blueprint schema [1] blocks the class names containing a '$'
character, specifically, a Tclass types expects all the Java class names
to match the xsd:NCName pattern.
Thus attempting to load a class such as "a.b.MyClass$MyNestedClass"
fails with the schema validation error which as it happens works OK in
Spring.
I'd like to propose to drop the NCName restriction and introduce and
xsd:string in Tclass instead.
IMHO that is the simplest solution - the Java runtime will effectively
validate the class name anyway so trying to enforce the Java class name
rules in the Blueprint schema may not be ideal.
If people are OK with this proposed update then I can proceed with the
change in the next few days
Sergey
[1]
https://svn.apache.org/repos/asf/aries/trunk/blueprint/blueprint-api/src/main/resources/org/osgi/service/blueprint/blueprint.xsd
Re: Blueprint schema blocks nested static class names
Posted by Jeremy Hughes <jp...@gmail.com>.
Hi,
The blueprint.xsd is defined by the OSGi Alliance, so this would need
to be changed in the spec. The Blueprint spec doesn't mention inner
classes so there's nothing AFAICT in the spec that excludes the use of
them - so arguably you could open a bug at the OSGi Alliance [1]. It's
worth discussing first on the developers list [2].
[1] www.osgi.org/bugzilla
[2] http://www.osgi.org/MailLists/HomePage
Cheers,
Jeremy
On 2 April 2012 20:54, Sergey Beryozkin <sb...@gmail.com> wrote:
> Hi,
>
> The blueprint schema [1] blocks the class names containing a '$' character,
> specifically, a Tclass types expects all the Java class names to match the
> xsd:NCName pattern.
>
> Thus attempting to load a class such as "a.b.MyClass$MyNestedClass" fails
> with the schema validation error which as it happens works OK in Spring.
>
> I'd like to propose to drop the NCName restriction and introduce and
> xsd:string in Tclass instead.
> IMHO that is the simplest solution - the Java runtime will effectively
> validate the class name anyway so trying to enforce the Java class name
> rules in the Blueprint schema may not be ideal.
>
> If people are OK with this proposed update then I can proceed with the
> change in the next few days
>
> Sergey
>
> [1]
> https://svn.apache.org/repos/asf/aries/trunk/blueprint/blueprint-api/src/main/resources/org/osgi/service/blueprint/blueprint.xsd