[wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Nicklas Karlsson
(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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Alessio Soldano
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
Alessio Soldano
Web Service Lead, JBoss
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Nicklas Karlsson
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?)


On Wed, May 22, 2013 at 10:46 AM, Alessio Soldano <[hidden email]> wrote:
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, <a href="tel:%2B358%2040%205062266" value="+358405062266">+358 40 5062266
> Vaakunatie 10 as 7, 20780 Kaarina
>
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


--
Alessio Soldano
Web Service Lead, JBoss
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Scott Marlow
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 <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     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 <tel:%2B358%2040%205062266>
>      > Vaakunatie 10 as 7, 20780 Kaarina
>      >
>      >
>      >
>      > _______________________________________________
>      > wildfly-dev mailing list
>      > [hidden email] <mailto:[hidden email]>
>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>     --
>     Alessio Soldano
>     Web Service Lead, JBoss
>     _______________________________________________
>     wildfly-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> --
> Nicklas Karlsson, +358 40 5062266
> Vaakunatie 10 as 7, 20780 Kaarina
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Nicklas Karlsson
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 <[hidden email]> 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 <[hidden email]
<mailto:[hidden email]>> wrote:

    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, <a href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266 <tel:%2B358%2040%205062266>

     > Vaakunatie 10 as 7, 20780 Kaarina
     >
     >
     >
     > _______________________________________________
     > wildfly-dev mailing list
     > [hidden email] <mailto:[hidden email]>

     > https://lists.jboss.org/mailman/listinfo/wildfly-dev


    --
    Alessio Soldano
    Web Service Lead, JBoss
    _______________________________________________
    wildfly-dev mailing list
    [hidden email] <mailto:[hidden email]>

    https://lists.jboss.org/mailman/listinfo/wildfly-dev




--
Nicklas Karlsson, <a href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev





--
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Scott Marlow
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 <[hidden email]
> <mailto:[hidden email]>> 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
>         <[hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email] <mailto:[hidden email]>>> 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
>               > [hidden email]
>         <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>
>
>               > 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
>         [hidden email] <mailto:[hidden email]>
>         <mailto:[hidden email]
>         <mailto:[hidden email]>>
>
>         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
>         [hidden email] <mailto:[hidden email]>
>         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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Stephen Coy
In reply to this post by Nicklas Karlsson
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]
<mailto:[hidden email]>> wrote:

    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, <a href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266 <tel:%2B358%2040%205062266>

     > Vaakunatie 10 as 7, 20780 Kaarina
     >
     >
     >
     > _______________________________________________
     > wildfly-dev mailing list
     > [hidden email] <mailto:[hidden email]>

     > https://lists.jboss.org/mailman/listinfo/wildfly-dev


    --
    Alessio Soldano
    Web Service Lead, JBoss
    _______________________________________________
    wildfly-dev mailing list
    [hidden email] <mailto:[hidden email]>

    https://lists.jboss.org/mailman/listinfo/wildfly-dev




--
Nicklas Karlsson, <a href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev





--
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Stan Silvert
In reply to this post by Scott Marlow
+11

I like this idea a lot, and especially like the name!


On 5/22/2013 8:54 AM, Scott Marlow wrote:

> 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 <[hidden email]
>> <mailto:[hidden email]>> 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
>>         <[hidden email] <mailto:[hidden email]>
>>         <mailto:[hidden email] <mailto:[hidden email]>>> 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
>>               > [hidden email]
>>         <mailto:[hidden email]>
>>         <mailto:[hidden email]
>>         <mailto:[hidden email]>>
>>
>>               > 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
>>         [hidden email] <mailto:[hidden email]>
>>         <mailto:[hidden email]
>>         <mailto:[hidden email]>>
>>
>>         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
>>         [hidden email] <mailto:[hidden email]>
>>         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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Nicklas Karlsson
In reply to this post by Stephen Coy
Well, the only "truly correct" way is, like you said, to look at the classloading rules like the AS would see them from the POV of the deployment (including all transitive module dependecies, implicit module additions, spec rules, jboss-deployment-structure overrides etc. 

A quick and dirty way which would probably catch 90% of the issues would be a text file of the format

ant*:WARN("Surely you don't need build tools in the deployment?")
*spring*:INFO("Please check you have at least version 3.0.3")
jta:ERROR("Don't do that, it's already provided")
hibernate*:INFO("Make sure you also configure your application for bundled hibernate")
guava*:INFO("You might also want to consider using the module com.google.guava")

We could have a local file with the usual suspects but you could also set the subsystem parameter "onlineCheck" that would go to a (predfined?) URL like jboss.org/stuff/wildfly/8/usualsuspects.txt for the list

Thoughts?



On Wed, May 22, 2013 at 4:10 PM, Stephen Coy <[hidden email]> wrote:
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]
<mailto:[hidden email]>> wrote:

    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, <a href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266 <tel:%2B358%2040%205062266>

     > Vaakunatie 10 as 7, 20780 Kaarina
     >
     >
     >
     > _______________________________________________
     > wildfly-dev mailing list
     > [hidden email] <mailto:[hidden email]>

     > https://lists.jboss.org/mailman/listinfo/wildfly-dev


    --
    Alessio Soldano
    Web Service Lead, JBoss
    _______________________________________________
    wildfly-dev mailing list
    [hidden email] <mailto:[hidden email]>

    https://lists.jboss.org/mailman/listinfo/wildfly-dev




--
Nicklas Karlsson, <a href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev





--
Nicklas Karlsson, <a href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev




--
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Paul Robinson
In reply to this post by Nicklas Karlsson
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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Paul Robinson
Web Service Transactions Lead
[hidden email]

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Jaikiran Pai
On Thursday 23 May 2013 02:42 PM, Paul Robinson wrote:
...
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.

How did he try doing that?

-Jaikiran


On 22 May 2013, at 08:22, Nicklas Karlsson <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Paul Robinson
Web Service Transactions Lead
[hidden email]

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Paul Robinson
I'm guessing something convoluted, that boiled down to:

cp -r jboss-as-7.1.3 ./jboss-as-7.1.3/standalone/deployments

It produced a large log file ;-)

On 23 May 2013, at 10:55, Jaikiran Pai <[hidden email]> wrote:

On Thursday 23 May 2013 02:42 PM, Paul Robinson wrote:
...
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.

How did he try doing that?

-Jaikiran


On 22 May 2013, at 08:22, Nicklas Karlsson <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Paul Robinson
Web Service Transactions Lead
[hidden email]

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


-- 
Paul Robinson
Web Service Transactions Lead
[hidden email]

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Nicklas Karlsson
In reply to this post by Paul Robinson
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 <[hidden email]> 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 <[hidden email]> 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, <a href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Paul Robinson
Web Service Transactions Lead
[hidden email]

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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Nicklas Karlsson
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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, <a href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Paul Robinson
Web Service Transactions Lead
[hidden email]

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, <a href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina



--
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Stuart Douglas
In reply to this post by Nicklas Karlsson


Nicklas Karlsson 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.

This is fixed now, you should just get a warning about files in the
wrong spot.

Stuart

>
>
> On Thu, May 23, 2013 at 12:12 PM, Paul Robinson
> <[hidden email] <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>> 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
>>     [hidden email] <mailto:[hidden email]>
>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>     --
>     Paul Robinson
>     Web Service Transactions Lead
>     [hidden email] <mailto:[hidden email]>
>
>     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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Jaikiran Pai
In reply to this post by Nicklas Karlsson
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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, <a moz-do-not-send="true" href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Paul Robinson
Web Service Transactions Lead
[hidden email]

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, <a moz-do-not-send="true" href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina



--
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Nicklas Karlsson
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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, <a href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

-- 
Paul Robinson
Web Service Transactions Lead
[hidden email]

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, <a href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina



--
Nicklas Karlsson, <a href="tel:%2B358%2040%205062266" value="+358405062266" target="_blank">+358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev




--
Nicklas Karlsson, +358 40 5062266
Vaakunatie 10 as 7, 20780 Kaarina

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Brian Stansberry
I don't see it in his repo.

On 5/29/13 3:24 AM, Nicklas Karlsson wrote:

> 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 <[hidden email]
> <mailto:[hidden email]>> 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
>>     <[hidden email] <mailto:[hidden email]>>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
>>         <[hidden email] <mailto:[hidden email]>>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
>>             <[hidden email] <mailto:[hidden email]>> 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
>>>             [hidden email]
>>>             <mailto:[hidden email]>
>>>             https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>>             --
>>             Paul Robinson
>>             Web Service Transactions Lead
>>             [hidden email] <mailto:[hidden email]>
>>
>>             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
>>     [hidden email]  <mailto:[hidden email]>
>>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
>
> --
> Nicklas Karlsson, +358 40 5062266
> Vaakunatie 10 as 7, 20780 Kaarina
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Rebecca Searls
In reply to this post by Nicklas Karlsson

comment on the original post.

>
>   I think this would be a very valuable tool.  Providing it as a CLI cmd
>   would
>   make it easist to use.  Being able to evaluate the dependencies during
>   deployment
>   would be the most helpful.  The user can run it as a deployment *lint* as
>   Scott
>   noted or as a *dry-run* before actually deploying the app.  As Steve
>   suggests
>   it should  report on the class loading env of each part of the deployment,
>   and
>   check for version issues and the like.
>
>   Ales Justin has a utility that will help with module dependenise analysis
>   and
>   reporting  see https://github.com/alesj/moduledeps.  I've used this in
>   conjuction
>   with tattletale to identify deployed archive dependencies on AS 7 modules
>   as well
>   as missing missing classes.
>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: [wildfly-dev] SDDS (Silly Deployment Detector Subsystem)

Rebecca Searls
In reply to this post by Nicklas Karlsson


comment on the original post.

>
>   I think such a tool is a good stop gap measure but in general I think our
>   perspective on this is all wrong.  We have a great modular framework and
>   isolated classloading.  Its a framework that can support applications
>   running
>   different lib versions on it.  Why not leverage that more?
>
>   It's the changes to the server framework implementation that seems to
>   always
>   cause the most pain in moving an application from one server version to
>   another.
>   AS7 is a case in point.  Providing a new improved framework is a good thing
>   but why not provide an infra-structure (module) along with it to enable the
>   move
>   from the previous to the current seamless?  Why make the customer do so
>   much
>   hard work?
>
>   We've all seen the forum discussion where a user is attempting to migrate
>   their
>   AS 4 app lock stock and barrel to AS 7 and ask how to resolve related
>   errors?
>   I too have scratched my head and asked, "why would he ever want to do
>   that".
>   Well, the user has put in a lot of man hours writing that app, fixing bugs,
>   and
>   making it stable.  He does not want to take the risk of introducing any new
>   bugs with changes.  He does want to write his new code to the current
>   standard
>   and run it in the current environment and he wants a single server
>   environment
>   to do it in.
>    
>   I've always envisioned JEE implementations to be an environment much like
>   an
>   OS.  When I update my OS I don't have to alter any of the apps I'm running.
>   I don't have to redeploy them or reconfigure them in any way.  It just
>   works.
>   I expect the same of my JEE implementations, and to date I've been
>   disappointed
>   by all the vendors.
>
>  
>   I think the framework provided in AS 7 and WildFly empowers us to provide
>   an
>   JEE environment that supports that AS 4 app running unaltered in WildFly. I
>   think there a number of functions that can and should be *retrofited* to
>   WildFly.
>   The Hibernate 3 module is an example of this.  An AS4/AS5 server config
>   loader module is another.  Support for the predecessors of HornetQ and
>   Infinispan
>   are others.
>
>   As we move forward with WildFly and future versions I would argue we need
>   to
>   design seamless support for prior versions of the components and provide
>   backward
>   compatibility not just at the JEE api level but the server framework
>   implementation
>   level. (Treat it like an OS)
>      
>      
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
12