Details
-
New Feature
-
Resolution: Done
-
Minor
-
None
-
All
-
-
GreenHopper Ranking:0|i2p6t7:
-
9223372036854775807
-
Small
-
To be defined
Description
Runtimes, like in cloud, may only know component-api in which there is component runtime.
It happens that error message are not well displayed when the ComponentException has a cause with a subclass of Exception that is unknown by the final application.
A way to prevent such issue would be to recursively transform all cause exceptions to a low level Exception class.
[EDIT]
Some more explanations:
To sumarize:
- Applications that use TCK, like pipeline designer or studio, run pipeline with connectors.
- Connectors have their own class loader
- For instance my JiraInput could use a JiraJavaLib (just an example not the reality)
- The JiraJavaLib contains JiraException
- It can happen that my connector raise an Exception and the the exception is a JiraException instance
- For instance my JiraInput could use a JiraJavaLib (just an example not the reality)
- Since connectors are isolated with their own class loader, the runtime applictation (studio or pipeline designer) doesn't know about JiraException
- So when it receiver this exception it fails with a ClassNotFoundException
- It's more true for pipeline designer since exception is first serialized and the ClassNotFoundException is raised when it tries to deserialize the Exception
That's why we ask that TCK connectors!
- only raise ComponentException
- It is known by runtime application since it is part of the TCK API
- Connector must not inherit from that class
- runtime application will not know those sub-classes
But, there is still an issue:
- ComponentException can have a 'cause' exception, and that cause can have also a 'cause', etc...
- We are facing the same issue:
- Cause classes MUST be known by runtime applications
- if not, it could throw a ClassNotFoundException
- Cause classes MUST be known by runtime applications
This ticket is about to re-recreate the 'cause' chain but with 'standard' Excpetion from java.lang: Exception or Throwable.
Example:
- For instance my connector could raise:
ComponentEception --cause--> JiraException --cause-->JiraTimeoutException --cause-->CommonApacheNetException
- the runtime application may not know JiraException, JiraTimeoutException, CommonApacheNetException classes
- it should be translated to :
ComponentEception --cause--> Exception --cause-->Exception --cause-->Exception
- All causes are instances of Exception, not instance of subclasses of Exception that's the differnce, all runtime applicaiton know about Exception class
- We should convert specific JiraException, JiraTimeoutException, CommonApacheNetException exception to generic Exception copying message and stacktrace into them.
[EDIT]
I think some unit tests should be enough to check if all the causes chain are transformed to Exception instances
Attachments
There are no Sub-Tasks for this issue.