[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