On 7 June 2013 16:12, Hardy Ferentschik <ha...@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 <emman...@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@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev