[jboss-dev-forums] [JBoss OSGi Development] - Re: Change in manifest parser breaks symbolic name
adrian@jboss.org
do-not-reply at jboss.com
Wed Aug 26 05:51:27 EDT 2009
The parsing of ParameterAttribute(s) and its decendent classes was already broken. The issue is in the javacc generated code.
The change I made was to parse the BundleSymbolicName as a ParameterAttribute
instead of a plain string because it has directives and attributes, e.g.
Bundle-Symbolic-Name=foo.bar;singleton=true
The reason is that the grammer is ambigous so sometimes it thinks it is parsing a PATH
when it should be parsing a QNAME.
The "tokenizer" part of the code is generating a wrong token and then it fails to match
in the parsing.
There's a commented out test with a TODO in the package import testing because of this.
Fixing this parsing problem is on my list of things to fix.
P.S. This is an "anti-pattern"
| public String getBundleSymbolicName()
| {
|
| <snip/>
|
| if (symbolicName == null)
| throw new IllegalStateException("Cannot obtain " + Constants.BUNDLE_SYMBOLICNAME);
|
| return symbolicName;
| }
|
You shouldn't put validation logic in the metadata model.
This validation of the model should be done when we are asked to install the bundle
so that others can augment/vary the model.
e.g. you could imagine a custom deployer that does for example
| OSGiMetaData md = ...;
| if (md.getBundleSymbolicName() == null)
| // generate one
|
Instead your validation in the getter would mean it has to catch the exception which is counter intuitive.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4251737#4251737
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4251737
More information about the jboss-dev-forums
mailing list