mgoellnitz / dinistiq Goto Github PK

In fact it checks for abstract classes - but it checks the input parameter instead of the output candidate.

Some tests have a strange assumption about "orders" of elements in sets.

If a beans gets injected values given from a properties file, some anonymous local (to that file) values might me injected too - most likely strings. These strings are not part of the dependency collection and especially not part of the ordering process. Subsequently this process fails.

The problem seems to have been introduced with 0.5 with its more precise ordering check.

Copy/paste error with parameter only used in other projects resulting in some strange "null" names.

It should be possible and is possible to use Dinistiq without the web integration part referencing the Servlet API. But doing so produces confusion and useless Log entries stating errors which are in fact not there.

To be usable in Google App Engine dinistiq relied on the Servlet API 2.5. With Servlet API 3.1 we could provide a leaner web integration API and configuration.

The indirection through the generic dinistiq dispatcher servlet can be removed. We will loose the pattern patching then but also one step in the calling sequence for requests.

On start dinistiq fails if the list of package names passed to the constructor is empty or not modifiable.

I now consider the EPL of JUnit a problematic license for dinistiq.