Heiko Studt created ARIES-2089:
----------------------------------

             Summary: Element Path from Parser inside explanation for 
ComponentDefinitionException
                 Key: ARIES-2089
                 URL: https://issues.apache.org/jira/browse/ARIES-2089
             Project: Aries
          Issue Type: Improvement
          Components: Blueprint
         Environment: Our environment is basing upon Apache Felix.
            Reporter: Heiko Studt


We are writing our blueprint XML definitions by hand, which sometimes leads to 
error messages by {color:#000000}org.apache.aries.blueprint.parser.Parser. As 
these error messages do not show the exact position / path inside the XML, we 
are required to retrace our modifications and manually search for the real 
culprit.
{color}

{color:#000000}However, this could be made far easier, if we would know the 
element (and it's path) the Parser is currently working on and for which the 
ComponentDefinitionExceptions was thrown, i.e. add the getErrorPath(element) in 
an exception like.{color}
{code:java}
throw new ComponentDefinitionException(getErrorPath(element) + 
  "One of " + REF_ATTRIBUTE + " attribute, " + VALUE_ATTRIBUTE + " attribute or 
sub element must be set");{code}
{color:#000000}Locally, I have already created some quick code to create such 
an error path adding some key blueprint attributes (starting with id, name, 
key, class) to retrace the position. If this is added to the explanation as 
show above, the debugging will get way easier.{color}

{color:#000000}So I should be able to create a PR, if you like me to.{color}

{color:#000000}I would prefer a sub-exception like 
"ComponentDefinitionElementException" of the OSGI-specified 
ComponentDefinitionException inside org.osgiservice.blueprint.parser which 
would access the attribute name constants of Parser.java to add the important 
ones and prefix the explanation.{color}

{color:#000000}The other idea is putting these methods inside Parser.java and 
concattenating the explanation strings there, which would still throw a 
ComponentDefinitionException itself, but has more logic inside Parser.{color}

{color:#000000}Or are those explanation strings regarded as carved in 
stone?{color}

{color:#000000}
{color}Regarding the Parser and its messages, the only open issue I saw was 
from 2013: ARIES-954



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to