10:02 a.m.
As an app developer I remember that some years ago I fell in love with
JBoss Tattletale [1], as I would use it on my projects regularly to
verify that I wasn't screwing up my deployed dependencies.. something
which was quite common as a naive developer using Maven..
Nowadays I'm loving WildFly's modules system as it would allow me to
break down complex applications further (if I still were to develop
apps on it), or as a Hibernate / Search / Infinispan developer allows
us to package things in a much nicer way, exposing a minimal API
surface to end users.
Then we have deployers such as the JPA subsystem which "automagically"
add dependencies to apps at runtime, and while I like the fact that I
don't have to add specific module-related descriptor files to my app
and trust that the app server *might* do the right thing in most
cases, I'm actually not very happy with the transparency of this
system as I believe most application developers would need an
exhaustive list of what's being added - and such details are all too
fleeting in our different versions.
I think it would be a great feature if the modular classloader
wouldn't just have a well-defined order to find class definitions, but
could go beyond that by actually verify that for a given class name
there are no ambiguous resolutions, within each module (and each
application).
Personally, I would totally love such an appserver who's going to yell at me:
"you bundled two copies of blah, I refuse to deploy that!".
Or similarly: "you're bundling Hibernate, but we're giving it to you
already as we recognized a JPA app and you didn't disable the embedded
module!"
"Seriously, one more copy of the JTA API ?"
Please?
Thanks,
Sanne
1 - http://tattletale.jboss.org/
10:11 a.m.
Right now we have a policy where deployment classes are searched first
unless the container also provides that package, in which case the
deployment package is silently dropped. We could enhance that to
outright reject, however that won't catch cases where we have an API
available that does something but it is not added to the deployment for
whatever reason (missing descriptor, subsystem not configured, etc.).
But it might do for part of the problem anyways...
The other part (logging what dependencies were added) I think would also
be a worthy (but separate) enhancement.
On 12/08/2015 10:02 AM, Sanne Grinovero wrote:
As an app developer I remember that some years ago I fell in love
with
JBoss Tattletale [1], as I would use it on my projects regularly to
verify that I wasn't screwing up my deployed dependencies.. something
which was quite common as a naive developer using Maven..
Nowadays I'm loving WildFly's modules system as it would allow me to
break down complex applications further (if I still were to develop
apps on it), or as a Hibernate / Search / Infinispan developer allows
us to package things in a much nicer way, exposing a minimal API
surface to end users.
Then we have deployers such as the JPA subsystem which "automagically"
add dependencies to apps at runtime, and while I like the fact that I
don't have to add specific module-related descriptor files to my app
and trust that the app server *might* do the right thing in most
cases, I'm actually not very happy with the transparency of this
system as I believe most application developers would need an
exhaustive list of what's being added - and such details are all too
fleeting in our different versions.
I think it would be a great feature if the modular classloader
wouldn't just have a well-defined order to find class definitions, but
could go beyond that by actually verify that for a given class name
there are no ambiguous resolutions, within each module (and each
application).
Personally, I would totally love such an appserver who's going to yell at me:
"you bundled two copies of blah, I refuse to deploy that!".
Or similarly: "you're bundling Hibernate, but we're giving it to you
already as we recognized a JPA app and you didn't disable the embedded
module!"
"Seriously, one more copy of the JTA API ?"
Please?
Thanks,
Sanne
1 - http://tattletale.jboss.org/
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
- DML
6:04 a.m.
On 8 December 2015 at 16:11, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
Right now we have a policy where deployment classes are searched
first
unless the container also provides that package, in which case the
deployment package is silently dropped. We could enhance that to
outright reject, however that won't catch cases where we have an API
available that does something but it is not added to the deployment for
whatever reason (missing descriptor, subsystem not configured, etc.).
But it might do for part of the problem anyways...
Right, I would love that. The main thing really is to prevent
duplicates and ambiguities, and prevent most cases which bring to
complex issues like "LinkageError" exceptions. So the case in which a
class is resolvable from 2+ places, or cases in which one things a
specific library version is being used but actually another is being
loaded.. those errors are subtle as they might go unnoticed.
As you say we can't do much about people who simply forget a needed
dependency or misconfiguration causing a "0 resolvable places"
situation, but also that's much simpler for people to figure out as
you'll get a familiar ClassNotFound exception or something around
those lines.
The other part (logging what dependencies were added) I think would also
be a worthy (but separate) enhancement.
+1
On 12/08/2015 10:02 AM, Sanne Grinovero wrote:
> As an app developer I remember that some years ago I fell in love with
> JBoss Tattletale [1], as I would use it on my projects regularly to
> verify that I wasn't screwing up my deployed dependencies.. something
> which was quite common as a naive developer using Maven..
>
> Nowadays I'm loving WildFly's modules system as it would allow me to
> break down complex applications further (if I still were to develop
> apps on it), or as a Hibernate / Search / Infinispan developer allows
> us to package things in a much nicer way, exposing a minimal API
> surface to end users.
>
> Then we have deployers such as the JPA subsystem which "automagically"
> add dependencies to apps at runtime, and while I like the fact that I
> don't have to add specific module-related descriptor files to my app
> and trust that the app server *might* do the right thing in most
> cases, I'm actually not very happy with the transparency of this
> system as I believe most application developers would need an
> exhaustive list of what's being added - and such details are all too
> fleeting in our different versions.
>
> I think it would be a great feature if the modular classloader
> wouldn't just have a well-defined order to find class definitions, but
> could go beyond that by actually verify that for a given class name
> there are no ambiguous resolutions, within each module (and each
> application).
>
> Personally, I would totally love such an appserver who's going to yell at me:
> "you bundled two copies of blah, I refuse to deploy that!".
>
> Or similarly: "you're bundling Hibernate, but we're giving it to you
> already as we recognized a JPA app and you didn't disable the embedded
> module!"
>
> "Seriously, one more copy of the JTA API ?"
>
> Please?
>
> Thanks,
> Sanne
>
> 1 - http://tattletale.jboss.org/
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
--
- DML
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
10:25 a.m.
On Tue, Dec 8, 2015 at 5:02 PM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
Personally, I would totally love such an appserver who's going to
yell at
me:
"you bundled two copies of blah, I refuse to deploy that!".
Or similarly: "you're bundling Hibernate, but we're giving it to you
already as we recognized a JPA app and you didn't disable the embedded
module!"
"Seriously, one more copy of the JTA API ?"
I've actually done some initial work on this, but never managed to get code
to some "stable" phase
where it could be used for some more than just demo purposes. (it was
presented at London JBUG last year)
But idea was to do just that, have configurable set of "problematic"
bundled jars / classes
that server would than yell at you about.
hence the name silly deployment detector.
code of it could be found https://github.com/ctomc/wildfly-sdd
With some more effort it could be brought to usable tool to help with
messed up deployments.
--
tomaz
6:17 a.m.
Very nice!
Don't you think this should be part of WildFly, to check for sanity at
deployment time?
But it looks like you go even further than my proposal, which was to
simply have the modular classloader verify for ambiguities during
class loading. SSD seems to work on a blacklists approach; I guess
there might be some benefits on that like make sure the validation
happens upfront, while classloading is lazy?
I regularly see people in trouble with multiple Hibernate copies,
although if you disable the Hibernate module injection by configuring
Jipijapa it could be a valid choice to bring your own Hibernate
libraries; it would need to be enhanced to understand such options
based on what the container is going to inject (or not). e.g.
Hibernate should be blacklisted if it's being injected, or allowed if
it's not.
One probably needs both: the blacklist approach needs some curating of
the lists, while the classloader approach will always work as last
defence, although later in the game so it might allow an invalid
deploy.. should it still fail hard at that point, when hitting an
inconsistency at runtime but after successful deploy? Probably not,
although I wonder if that's still easily implementable: the behaviour
of the module's classloader would need to switch after deploy.
Thanks,
Sanne
On 8 December 2015 at 16:25, Tomaž Cerar <tomaz.cerar(a)gmail.com> wrote:
On Tue, Dec 8, 2015 at 5:02 PM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
>
> Personally, I would totally love such an appserver who's going to yell at
> me:
> "you bundled two copies of blah, I refuse to deploy that!".
>
> Or similarly: "you're bundling Hibernate, but we're giving it to you
> already as we recognized a JPA app and you didn't disable the embedded
> module!"
>
> "Seriously, one more copy of the JTA API ?"
I've actually done some initial work on this, but never managed to get code
to some "stable" phase
where it could be used for some more than just demo purposes. (it was
presented at London JBUG last year)
But idea was to do just that, have configurable set of "problematic" bundled
jars / classes
that server would than yell at you about.
hence the name silly deployment detector.
code of it could be found https://github.com/ctomc/wildfly-sdd
With some more effort it could be brought to usable tool to help with messed
up deployments.
--
tomaz
3074
days inactive
3076
days old
4 comments
3 participants
participants (3)
-
David M. Lloyd -
Sanne Grinovero -
Tomaž Cerar