11:06 a.m.
2013/6/7 Sanne Grinovero <sanne(a)hibernate.org>
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
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev