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

[Gunnar Morling]

2013/6/7 Sanne Grinovero <sanne at hibernate.org>

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

I just want to add a point from my perspective of being until recently on
the "user side".

In many shops it's much more difficult (if even possible at all) to change
anything on the app server (installation) itself than putting a new EAR to
it. This is mainly due to political reasons and I (or developers in
general) know the outcome can be the same.

I also understand the advantages of integration etc. you describe, I just
think the requirement of changing the app server itself can be much harder
to meet in many cases than changing the libs of a deployed application; So
if a library requires this kind of set up, it may reduce its attractiveness.

--Gunnar


>
> 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
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>