Users who only need to initialize the JAXB support can now call ContextAndPolicy.initializeJAXBContextAndPolicyConfiguration() directly.

I have a small comment on your patch.

• I don't know why but I have some problems with applying it, it always has errors. But I think I can handle it.
• I think (unless I overlooked it) the patch does not solve the problem because it does load the jaxb stuff (formatted output etc) but it does not initialize the functions, data types etc. When marshalling and unmarshalling the JAXB-Type adapters will fail. This factory method must also call all initializers (currently all initializers are only for jaxb stuff).

Hmm... Now when writing some questions arise in my brain :
In my opinion it requires two factories. One for PDP initialization and one for jaxb initialization. The PDP factory also calls the jaxb factory but the jaxb factory can be used standalone.
If this setup would be implemented we must also think about the initializers. Do we now need to kinds of initializers?
A JAXBInitializer that is only applicable to the jaxb factory and a PDP initializers that is only applicable to the PDP factory (these pdp initializers would also have access to the PDP object).

What do you think?

I could understand doing this type of classpath scanning if it wasn't so brittle and if it picked up more than just HERAS defined types. But it is brittle and it doesn't support anything other than HERAS types. So I would strongly recommend simplifying this code.

We do the scanning to be able to automatically pick up the e.g. function classes within the functions package. This to not be forced to initialize all 209+ functions "by hand" within the initializer.
We are certain that it is a usable way to handle this.

Your objection about environment that maybe don't work (OSGi, Google App Engine, ...) I think that we are very open to make the experience with those. I am willing to create test for all of these. I also would take it on my list of todos.

The reason that I am not convinced to throw everything into trash and make it the very simple way is that we think this is a very neat way of getting all those e.g. functions into the JAXB stuff.
I fully understand your point of view to say "why classpath scanning when it would work without". But if you could live with it I am really wanted to give our approach a chance to proof.

On the other hand we still will try to provide (an optional) possibility for users to dynamically add their own types.

JAXBInitializer.run();
After this the whole JAXB stuff is initialized and the following classes can be properly used:

• PolicyMarshaller
• RequestCtxFactory
• RequestCtx
• ResponseCtxFactory
• ResponseCtx