Just FYI, the webservices subsystem has something related to this topic, see https://issues.jboss.org/browse/WFLY-451 . Basically deployments containing WS endpoints are scanned by the webservices susbsystem to detect Apache CXF libraries (which should not be included in the deployment, being them already available on the server). If they're found, a verbose/explanatory warning is printed and the deployment aborted. User will either fix the deployment or disable the webservices subsystem for it. Alessio On 05/22/2013 09:22 AM, Nicklas Karlsson wrote: > (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. > > Thoughts? > > -- > Nicklas Karlsson, +358 40 5062266 > Vaakunatie 10 as 7, 20780 Kaarina > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Alessio Soldano Web Service Lead, JBoss _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On 05/22/2013 04:04 AM, Nicklas Karlsson wrote: > That's a good example. I guess the JPA subsystem could check for > incorrectly bundled Hibernate, JSF for incorrectly bundled impl, JAX-RS > probably could use their own. Could they all be extracted to a common > deployment-check-subsystem (or more precisely, should they?) > +10 for this idea. I like both approaches. It would be great to have a deployment *lint* detector of some form. If it is created as a common system, it might be more difficult to reach into the various deployers to diagnose issues. For the common approach, it could also be a standalone tool that is built up over time. If it is standalone, a log scanner would be a nice complement so that we could easily identify common runtime problems in addition to deployment time. > > On Wed, May 22, 2013 at 10:46 AM, Alessio Soldano <asoldano(a)redhat.com > <mailto:asoldano@redhat.com>> wrote: > > Just FYI, the webservices subsystem has something related to this > topic, > see https://issues.jboss.org/**browse/WFLY-451<https://issues.jboss.org/br...;. Basically deployments > containing WS endpoints are scanned by the webservices susbsystem to > detect Apache CXF libraries (which should not be included in the > deployment, being them already available on the server). If they're > found, a verbose/explanatory warning is printed and the deployment > aborted. > User will either fix the deployment or disable the webservices > subsystem > for it. > > Alessio > > On 05/22/2013 09:22 AM, Nicklas Karlsson wrote: > > (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. > > > > Thoughts? > > > > -- > > 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:wildfly-dev@lists.**jboss.org<wildfly-dev@lists.jboss.org> > > > > > https://lists.jboss.org/**mailman/listinfo/wildfly-dev<https://lists.j... > > > -- > Alessio Soldano > Web Service Lead, JBoss > ______________________________**_________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.**jboss.org<wildfly-dev@lists.jboss.org> > > > > https://lists.jboss.org/**mailman/listinfo/wildfly-dev<https://lists.j... > > > > > -- > Nicklas Karlsson, +358 40 5062266 > Vaakunatie 10 as 7, 20780 Kaarina > > > ______________________________**_________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/**mailman/listinfo/wildfly-dev<https://lists.j... > >

I think that you have an *itch* in mind and should give it a go either way. If you start it as an internal tool, it could be switched to external later if that makes sense. The important thing is to start building this tool up on github, so that others can use it and contribute to it also! On 05/22/2013 08:34 AM, Nicklas Karlsson wrote: > An external tool is probably easiest to develop but wouldn't it be hard > to know what classes are implicitly added by the deployers (e.g. JPA > stuff based on persistence.xml) presence? > For the modules, I guess one could iterate over the module roots, read > in the module.xml:S, load thes module and see what's exported and build > up a registry to see if there are packages provided both by the > deployment and the AS. Really depends on how you want to determine the dependencies (based on what the deployers actually do versus *dependency rules* described in a file/code). > > On Wed, May 22, 2013 at 3:23 PM, Scott Marlow <smarlow(a)redhat.com > <mailto:smarlow@redhat.com>> wrote: > > On 05/22/2013 04:04 AM, Nicklas Karlsson wrote: > > That's a good example. I guess the JPA subsystem could check for > incorrectly bundled Hibernate, JSF for incorrectly bundled impl, > JAX-RS > probably could use their own. Could they all be extracted to a > common > deployment-check-subsystem (or more precisely, should they?) > > > +10 for this idea. > > I like both approaches. It would be great to have a deployment > *lint* detector of some form. If it is created as a common system, > it might be more difficult to reach into the various deployers to > diagnose issues. > > For the common approach, it could also be a standalone tool that is > built up over time. If it is standalone, a log scanner would be a > nice complement so that we could easily identify common runtime > problems in addition to deployment time. > > > > On Wed, May 22, 2013 at 10:46 AM, Alessio Soldano > <asoldano(a)redhat.com <mailto:asoldano@redhat.com> > <mailto:asoldano@redhat.com <mailto:asoldano@redhat.com>>> wrote: > > Just FYI, the webservices subsystem has something related > to this topic, > see https://issues.jboss.org/__browse/WFLY-451 > <https://issues.jboss.org/browse/WFLY-451> . Basically deployments > containing WS endpoints are scanned by the webservices > susbsystem to > detect Apache CXF libraries (which should not be included > in the > deployment, being them already available on the server). If > they're > found, a verbose/explanatory warning is printed and the > deployment > aborted. > User will either fix the deployment or disable the > webservices subsystem > for it. > > Alessio > > On 05/22/2013 09:22 AM, Nicklas Karlsson wrote: > > (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. > > > > Thoughts? > > > > -- > > Nicklas Karlsson, +358 40 5062266 > <tel:%2B358%2040%205062266> <tel:%2B358%2040%205062266> > > > Vaakunatie 10 as 7, 20780 Kaarina > > > > > > > > _________________________________________________ > > wildfly-dev mailing list > > wildfly-dev(a)lists.jboss.org > <mailto:wildfly-dev@lists.jboss.org> > <mailto:wildfly-dev@lists.__jboss.org > <mailto:wildfly-dev@lists.jboss.org>> > > > https://lists.jboss.org/__mailman/listinfo/wildfly-dev > <https://lists.jboss.org/mailman/listinfo/wildfly-dev> > > > -- > Alessio Soldano > Web Service Lead, JBoss > _________________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > <mailto:wildfly-dev@lists.__jboss.org > <mailto:wildfly-dev@lists.jboss.org>> > > https://lists.jboss.org/__mailman/listinfo/wildfly-dev > <https://lists.jboss.org/mailman/listinfo/wildfly-dev> > > > > > -- > 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:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/__mailman/listinfo/wildfly-dev > <https://lists.jboss.org/mailman/listinfo/wildfly-dev> > > > > > > -- > Nicklas Karlsson, +358 40 5062266 > Vaakunatie 10 as 7, 20780 Kaarina _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Hi Nicklas, I had been thinking of doing something along similar lines. However, I was considering a CLI command related to "deploy" that is able to replicate the class loading environment for each part of a deployment (ear, ejb-jar, war, far, etc) and then check whether or not each class in the deployment is already available in the class loader, subject to the spec's API visibility rules. That may be a bit over the top though. This is also a big +10 from me too, btw. We spend more time on the forums getting people to list their deployment contents when troubleshooting than anything else. Steve C On 22/05/2013, at 10:34 PM, Nicklas Karlsson <nickarls(a)gmail.com&gt; wrote: An external tool is probably easiest to develop but wouldn't it be hard to know what classes are implicitly added by the deployers (e.g. JPA stuff based on persistence.xml) presence? For the modules, I guess one could iterate over the module roots, read in the module.xml:S, load thes module and see what's exported and build up a registry to see if there are packages provided both by the deployment and the AS. On Wed, May 22, 2013 at 3:23 PM, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > On 05/22/2013 04:04 AM, Nicklas Karlsson wrote: > >> That's a good example. I guess the JPA subsystem could check for >> incorrectly bundled Hibernate, JSF for incorrectly bundled impl, JAX-RS >> probably could use their own. Could they all be extracted to a common >> deployment-check-subsystem (or more precisely, should they?) >> > > +10 for this idea. > > I like both approaches. It would be great to have a deployment *lint* > detector of some form. If it is created as a common system, it might be > more difficult to reach into the various deployers to diagnose issues. > > For the common approach, it could also be a standalone tool that is built > up over time. If it is standalone, a log scanner would be a nice > complement so that we could easily identify common runtime problems in > addition to deployment time. > > >> >> On Wed, May 22, 2013 at 10:46 AM, Alessio Soldano <asoldano(a)redhat.com >> <mailto:asoldano@redhat.com>> wrote: >> >> Just FYI, the webservices subsystem has something related to this >> topic, >> see https://issues.jboss.org/**browse/WFLY-451<https://issues.jboss.org/br...;. Basically deployments >> containing WS endpoints are scanned by the webservices susbsystem to >> detect Apache CXF libraries (which should not be included in the >> deployment, being them already available on the server). If they're >> found, a verbose/explanatory warning is printed and the deployment >> aborted. >> User will either fix the deployment or disable the webservices >> subsystem >> for it. >> >> Alessio >> >> On 05/22/2013 09:22 AM, Nicklas Karlsson wrote: >> > (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. >> > >> > Thoughts? >> > >> > -- >> > 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:wildfly-dev@lists.**jboss.org<wildfly-dev@lists.jboss.org> >> > >> >> > https://lists.jboss.org/**mailman/listinfo/wildfly-dev<https://lists.j... >> >> >> -- >> Alessio Soldano >> Web Service Lead, JBoss >> ______________________________**_________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.**jboss.org<wildfly-dev@lists.jboss.org> >> > >> >> https://lists.jboss.org/**mailman/listinfo/wildfly-dev<https://lists.j... >> >> >> >> >> -- >> Nicklas Karlsson, +358 40 5062266 >> Vaakunatie 10 as 7, 20780 Kaarina >> >> >> ______________________________**_________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/**mailman/listinfo/wildfly-dev<https://lists.j... >> >> > -- Nicklas Karlsson, +358 40 5062266 Vaakunatie 10 as 7, 20780 Kaarina _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

... 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 ;-) Paul.

On 22 May 2013, at 08:22, Nicklas Karlsson <nickarls(a)gmail.com <mailto:nickarls@gmail.com>> wrote: > (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. > > Thoughts? > > -- > Nicklas Karlsson, +358 40 5062266 > Vaakunatie 10 as 7, 20780 Kaarina > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Paul Robinson Web Service Transactions Lead paul.robinson(a)redhat.com <mailto:paul.robinson@redhat.com> JBoss, a Division of Red Hat Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA) _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Nicklas, 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 ;-) Paul. On 22 May 2013, at 08:22, Nicklas Karlsson <nickarls(a)gmail.com&gt; wrote: (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. Thoughts? -- Nicklas Karlsson, +358 40 5062266 Vaakunatie 10 as 7, 20780 Kaarina _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Paul Robinson Web Service Transactions Lead paul.robinson(a)redhat.com JBoss, a Division of Red Hat Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA)

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 <mailto:nickarls@gmail.com>>wrote: 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 <paul.robinson(a)redhat.com <mailto:paul.robinson@redhat.com>>wrote: Nicklas, 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 ;-) Paul. On 22 May 2013, at 08:22, Nicklas Karlsson <nickarls(a)gmail.com <mailto:nickarls@gmail.com>> wrote: > (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. > > Thoughts? > > -- > 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:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Paul Robinson Web Service Transactions Lead paul.robinson(a)redhat.com <mailto:paul.robinson@redhat.com> JBoss, a Division of Red Hat Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (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 wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Does anyone know if the code is available somewhere on github? No, Tomaz, don't you reply - you should be on the beach ;-) On Wed, May 29, 2013 at 10:49 AM, Jaikiran Pai <jpai(a)redhat.com <mailto:jpai@redhat.com>> wrote: 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" http://www.jboss.org/events/JUDCon/2013/unitedstates/agenda/day2track1.html -Jaikiran On Tuesday 28 May 2013 12:10 PM, Nicklas Karlsson wrote: > 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 <mailto:nickarls@gmail.com>>wrote: > > 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 > <paul.robinson(a)redhat.com <mailto:paul.robinson@redhat.com>>wrote: > > Nicklas, > > 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 ;-) > > Paul. > > > On 22 May 2013, at 08:22, Nicklas Karlsson > <nickarls(a)gmail.com <mailto:nickarls@gmail.com>> wrote: > >> (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. >> >> Thoughts? >> >> -- >> 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:wildfly-dev@lists.jboss.org> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Paul Robinson > Web Service Transactions Lead > paul.robinson(a)redhat.com <mailto:paul.robinson@redhat.com> > > JBoss, a Division of Red Hat > Registered in England and Wales under Company Registration > No. 03798903 > Directors: Michael Cunningham (USA), Brendan Lane > (Ireland), Matt Parson > (USA), Charlie Peters (USA) > > > > > -- > Nicklas Karlsson, +358 40 5062266 <tel:%2B358%2040%205062266> > Vaakunatie 10 as 7, 20780 Kaarina > > > > > -- > 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:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Nicklas Karlsson, +358 40 5062266 Vaakunatie 10 as 7, 20780 Kaarina _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

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 <paul.robinson(a)redhat.com <mailto:paul.robinson@redhat.com>> wrote: Nicklas, 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 ;-) Paul. On 22 May 2013, at 08:22, Nicklas Karlsson <nickarls(a)gmail.com <mailto:nickarls@gmail.com>> wrote: > (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. > > Thoughts? > > -- > 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:wildfly-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Paul Robinson Web Service Transactions Lead paul.robinson(a)redhat.com <mailto:paul.robinson@redhat.com> JBoss, a Division of Red Hat Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson (USA), Charlie Peters (USA) -- Nicklas Karlsson, +358 40 5062266 Vaakunatie 10 as 7, 20780 Kaarina _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev