In the evaluation of functions an error is singalized by a FunctionProcessingException. This means if an error occurs a FunctionProcessingException is thrown that traverses the whole stacktrace up to the place where it is caught and and INDETERMINADTE is returned.
The problem is that this exception fills in the stracktrace (fillInStacktrace) and that is an expensive operation.
Change the fillInStacktrace method so that it does nothing by default. Add a possibility (e.g. through an Initializer) to enable the fillInStacktrace, e.g. for debugging purposes.
It can be thoguht of that the PDP can be put into DEV_MODE.
Additionaly in the functions a "logger.debug"-should be added to print the exception when an error occurs.
Hm... this would indeed pollute the method signatures considerably.
I was thinking that we could delegate the creation of the Exception to a factory. That factory gets initialized with the DEV_MODE flag and either raises a FunctionProcessingException or a FastFunctionProcessingException. The factory could do some tweaking of the stack trace element array to remove itself from the stacktrace.
Question is where the factory should be attached to. Semantically we want it to be part of the PDP state. But currently functions have no reference to the PDP, so they cannot get to the factory. Would it be acceptable to store a reference to the PDP the function belongs to in the function instances? if yes, what about other entities that are initialized with the PDP. Should they be changed as well to carry a reference to the PDP instance?
That the functions (and maybe other types) have a reference to the PDP does also not sound very cool.
I have another idea:
The functions (and other types) are initialized by the initializers (interface org.herasaf.xacml.core.simplePDP.initializers.api.Initializer). The initializer-method gets the PDP-Configuration (org.herasaf.xacml.core.simplePDP.SimplePDPConfiguration) as parameter while initializing.
We could make de DEV_MODE part of the PDP-Configuration (boolean flag) and pass it then to the functions when initialized.
Then, because it is a flag, it might be possible to control the exception-behavior within the FunctionProcessingException and it wouldn't be necessary to have a second Exception (FastFunctionProcessingException).
What do you think?
, OK, let's start with this approach and see how it looks. I will be gone until next week, so probably won't be able to work on this until weekend after next...
@fhuonder, unfortunately the approach with a single exception does not work. fillInStackTrace() is called by the constructor of Throwable. The call to the super constructor has to be the first line of code in the sub-class constructor, thus only after I can set the PDP configuration to make any decisions in fillInStackTrace(). The decision whether to fill the stacktrace or not has to be taken before the Exception is raised.
Java 7 and higher would offer a new constructor to help with this. But with Java 5 support I think we have to go for 2 different exception types.
Our suggestion would then be to introduce the second exception that does not fill-in the stacktrace.
The Fast-Exception should be an extension to the normal exception but with an empty fillInStackTrace-method.
Then we introduce a factory for this exception that is to be used in the functions. (FunctionProcessingExceptionFactory.newInstance(...))
This factory is statically configured when the PDP is set up (in the PdpFactory) with the DEV-MODE-Flag and returns the correct exception at runtime. Due to the fact that the Fast-Exception extends the normal exception the factory could simply return the normal exception.
What do you think?
I also think that we should open up an issue for the release 2.0.0 to change this implementation, with the new constructor that was introduced in java 7, to get rid of the second exception.
Would you do this?`