Tomaz is on vacation. He will be at JUDCon in Boston in June and as far
as I know this is exactly the topic that he will be
talking/demonstrating with a custom subsystem implementation. It's
scheduled for June 10th "WildFly extenstions in action"
Tomaz, did you ever get around to starting on your own implementation
you once mentioned?
On Thu, May 23, 2013 at 1:27 PM, Nicklas Karlsson <nickarls(a)gmail.com
Embedded AS! ;-)
But yes, that's another good sanity check. I don't know if it's
been fixed in Weld/AS but at some point you got ambiguous resolves
for CDI when you had beans.xml in both places in the WAR.
On Thu, May 23, 2013 at 12:12 PM, Paul Robinson
Like others this is something I've wanted for some time. There
was some interesting discussion on the following thread. I'll
copy my original thoughts here. Apologies in advance to the
"JEE Police", I was young and naive ;-)
"[jboss-as7-dev] Detecting deployment location errors for xml
files using a JEE schema".
> A common problem I see again and again is when people
> miss-spell the
> filenames of XML artefacts that live in the META-INF and WEB-INF
> directories of a JEE archive. I also see people (myself included)
> putting these artefacts in the wrong location, For example,
> putting the
> beans.xml file in the META-INF of a .war when it belongs in
> the WEB-INF.
Also a student, on a course I teach, tried to deploy AS7 into
AS7! That was fun to debug. Would you be able to spot that ;-)
On 22 May 2013, at 08:22, Nicklas Karlsson <nickarls(a)gmail.com
> (I know there has been some discussion on the topic (old
> community AS7-dev postings, IRC-chat with Tomaz Cerar etc)
> Hanging around the forums, I've noticed that a frequent
> source of hard-to-debug deployment problems and other
> non-linear-behavior is that people often try to deploy
> archives with conflicting dependencies (various EE APIs/impls
> already on the AS, JDBC drivers, maven plugins, you name it).
> Would it be worthwhile to implement a deployment
> processor (disabled by default) that would act as a helpful
> bouncer for the deployment archive? We could have a simple
> isSane(Archive) interface or something and people could write
> their own implementations (that would be picked up through
> the java services system or listed explicitly in some
> module?). Default implementation that come to mind is
> * Blacklisted packages (using Tattletale to warn users if
> they are bundling e.g. EE impls/APIs)
> * Version limiter (using Tattletale to warn if deployment
> contains too old version of lib, e.g. Spring)
> * Unused libs (using Tattletale to warn if deployment
> contains unused jars)
> * Server provided libs (using Tattletale and JBoss Modules)
> to show which dependencies could be handled by a server
> module dependency)
> I'm not sure JBoss Modules contains any "directory" for
> which-modules-provides functionality but I guess the module
> root could be scanned and the resources indexed or something.
> Performance would not be an issue because it's still going to
> be faster that a user playing around with dependencies for days.
> Nicklas Karlsson, +358 40 5062266 <tel:%2B358%2040%205062266>
> Vaakunatie 10 as 7, 20780 Kaarina
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:firstname.lastname@example.org>
Web Service Transactions Lead
JBoss, a Division of Red Hat
Registered in England and Wales under Company Registration No.
Directors: Michael Cunningham (USA), Brendan Lane (Ireland),
(USA), Charlie Peters (USA)
Nicklas Karlsson, +358 40 5062266 <tel:%2B358%2040%205062266>
Vaakunatie 10 as 7, 20780 Kaarina
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina
wildfly-dev mailing list