[hibernate-dev] [jdf-dev] JBoss Modules dependency vs pain POM dependency + exclusions

[Sanne Grinovero]

On 7 June 2013 16:12, Hardy Ferentschik <hardy at hibernate.org> wrote:
> Again, late to the party, but I agree with Emmanuel. Modules is imo to AS specific in order to encourage it
> as a default/referred configuration approach. I see it more as an expert mode to configure your app server.

Right we should make it easier and with clear documentation. But
"dropping something in your /modules" isn't sooo different than
dropping an EAR in your /deploy
both are easily scripted, we have a not-too-nice solution which works
with Maven, and if it becomes a mainstream strategy for other JBoss
modules then we could certainly make a better looking Maven plugin.

>
> And is not also dangerous to fiddle too much with the modules? Adding new modules might be ok, but often
> you end up updating others as well (talking EL and Bean Validation) and there you don't know whether you
> break another subsystem.

What fiddling? we don't update EL nor Bean Validation modules, but we
provide solid modules which are tested by our CI and consumed by other
projects (getting more tests done to benefit all).
We can even provide multiple versions and layer them all on the same
server instance without conflict, or multiple variants for the same
version which have the correct wiring-up for different integrations;
the classpath is controlled and we can test these automatically, while
there is no way we can test documented exclusion lists /
configurations for bundled jars.

Getting more pratical: explain me how I should configure the classpath
for an "embedded lib style" deployment which takes advantage of 2nd
level caching via Infinispan, uses Hibernate Search to store indexes,
and opens a JGroups backend. The dump solution is to include both
Infinispan and JGroups; you'll have to add all dependencies like
JBLogging, JBMarshaller, a provided JTA manager.. you'll get an
app-server class of services but all management extensions will not be
wired up to the AS core, nor Infinispan will be connected to internals
like mod_cluster & al. I'm not even sure if the logger will bind
correctly for dynamic configuration or if it's going to work via a
Log4J bridge which gets intercepted and re-routed to the AS proper
logger .. lots of problems I'd not prepared to face, I bet big time
Tomcat would sound more appealing: no metrics (either can we), no
admin (wouldn't work either), but at least these services don't fight
against each other's resources.

For example, your *really* don't want to start an Infinispan grid in
the scope of Hibernate Search's deployed app and forget to isolate its
clustering channels from the ones in the AS.

Lib deployment could get made to work on some of this but I don't
think all, and even so you would still need to hack on your deployment
descriptor, with very advanced AS knowledge. I'd rather "prepack" the
easy solution, and test it.

> Also it adds additional constrains when deploying the app server and app. It is not just about dropping in a ear/war
> anymore, suddenly I have to "patch" my app server first.

Right I see your point on this: if it feels like patching it doesn't
look good. But it feels much better if you look at it as "dependency
resolution". I can totally see how a wildfly instance could download
these on-demand from the dependency definition; by having these in
Maven, corporate environments might not dislike it too much as they
could have their own repository managers.

BTW this problem is only for JBoss / Wildfly as other app servers
don't bundle Hibernate, so the solution is special purpose as well.

Sanne

>
> On 6 Jan 2013, at 5:41 PM, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
>> As I explain in the email I forwarded, modules are good on paper but
>> suffer from a few practical problems:
>>
>> I need to manually install them on my deployed server instead of just
>> handing over the JAR.
>
> Exactly
>
>> Of course modules are JBoss specific so it's a pain to make my
>> application portable across several app servers.
>
> +1
>
> IMO we should be able to deploy an Search application with Search, ORM et al all bundled up and it should just work.
>
> --Hardy
>