12:25 p.m.
On 7 Jan 2013, at 5:44 PM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
On 7 June 2013 16:12, Hardy Ferentschik <hardy(a)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