This needs to go in jar (library) rather than the war (app)

Goes for Glassfish as well as JBoss it seems.
This sort of defies one purpose of dependency injection. You
want to be able to code alternative implementations in a library,
but have the application using that library decide deploy-time
which implementation to use.

Strangely enough this works in Tomcat 7 with Weld included in the jar.

I believe following ticket is about this issue:
https://issues.jboss.org/browse/CDI-18

Glassfish has JSF/CDI capabilities already

Attempts to solve some Eclipse/Maven discrepancy

-

Merge branch 'temp'

Conflicts:
src/main/java/com/indexdata/pz2utils4jsf/config/Pz2Config.java

Avoids npe when no config file path

Experimenting with tomcat/jboss/glassfish

Work on error handling

Fix throw of missing mandatory parameter and write suggestion
Documentation
Some renaming

Avoids npe in case of main config file missing

.. and diagnose the scenario for troubleshooting

Embeds pz2 error XML, if any, in the app error XML

Work in progress on error detect,report,troubleshoot

Adds configuration errors (had command errors)
Resolves more errors
Adds more suggestions

Work on error reporting. Adds troubleshooter.

Packaging pazpar2/io error messages in response objects

For return to and display in the UI

Debug stmts and fix for double object instantiation

Spurious objects created by CDI due to the way some of the
pz2 bean and config constructors where written.

Fixes support for posting pz2 service definition xml

Adds another config option (by MasterKey config)

Adds injectable pazpar2 client configs

To allow users of the toolkit a freedom of choice regarding
configuration scheme (ie web.xml, property file, masterkey configuration
scheme, etc)

Work-in-progress on interchangeable config mechanisms

Renames "controls" to "pz2widgets"

Removes non-generic elements from utility package

Adds beans and configs

Adds Weld (CDI) dependency

Adds pazpar2 listeners