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

[Hardy Ferentschik]

On 7 Jan 2013, at 5:44 PM, Sanne Grinovero <sanne at hibernate.org> wrote:

> 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

Yes it is and as Gunnar pointed out there might also be more resistance from the ops people to to something like this

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

See, now we start talking. If we have the right tools we can start talking about this. 
The current scripts are more of a hack than anything and I would not like people to
do the same thing. Also, what is this maven plugin supposed to do? Patch your local
AS instance. That's fine for your local build, but how does this help production?
What are you going to deliver to the guys running the actual production app? An ear file
and a zip with the instructions to please unzip this first here? 

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

I am not talking Search in this case. It was a general comment against modifying 
modules directories.

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

Sure, there might be situations where the module approach is better. I was just saying
it should not be the "default way of doing things". I trust you that the scenarios 
you describe are best solved the way you say, but I still think it is a little unfortunate.  

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

How can it feels better by just naming it something else. What counts is that I have to 
install a default AS instance and then modify/patch its inner configuration.

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

Now that is different imo. Now we provide some proper tooling around this.
When are you having this ready to go?

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

So basically we are saying on our app server it is actually harder to get this to work than on 
others. Interesting. Maybe we should target Glassfish then. 

--Hardy