[jira] [Created] (ARIES-2089) Element Path from Parser inside explanation for ComponentDefinitionException

["Heiko Studt (Jira)" <ji...@apache.org>]

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)