Skip to main content

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Re: Modularization Framework/SPI

  • From: Werner Keil <werner.keil@...>
  • To: jsr342-experts@...
  • Cc: reza_rahman@...
  • Subject: [jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Re: Modularization Framework/SPI
  • Date: Thu, 26 Jul 2012 19:36:30 +0200

Interestingly, beside module definitions in the dependency file, Play!'s application.conf
contains some other simple ways to disable or enable modules and an equally simple approach to log-levels

# Evolutions
# ~~~~~
# You can disable evolutions if needed
# evolutionplugin=disabled

# Logger
# ~~~~~
# You can also configure logback (http://logback.qos.ch/), by providing a logger.xml file in the conf directory .

# Root logger:
logger.root=ERROR

# Logger used by the framework:
logger.play=INFO

# Logger provided to your application:
logger.application=DEBUG


Example from the Secure-Social module, a Security Provider for Social Media (hence I looked at his project occasionally)

Werner

On Thu, Jul 26, 2012 at 7:23 PM, Werner Keil <werner.keil@...> wrote:
To put the focus back on options where modularity already works aside of OSGi, look at the successful and popular Play! Framework and how it handles dependencies in more or less a single file:

Or Fantom, though that does it on a language level, more to how Jigsaw (and other highlights of Fantom over Java) should have been in the first place:

Regards,
-- 

Werner Keil JCP Executive Committee Member | Eclipse UOMo Lead

Twitter @wernerkeil | #Java_Social | #EclipseUOMo | #OpenDDR

Skype werner.keil | Google+ gplus.to/wernerkeil

* Chip-to-Cloud Security Forum: September 19 2012, Nice, French Riviera. Werner Keil, JCP Executive Committee, JSR-321 EG Member will present "Trusted Computing API for Java™"

* Eclipse Day Delft: September 27 2012, Delft, Netherlands. Werner Keil, Eclipse Committer, UOMo Lead, Mærsk Build Manager will present "Triple-E class Continuous Delivery with Hudson, Maven and Mylyn"

* JavaOne: September 30-October 4 2012, San Francisco, USA. Werner Keil,  JCP Executive Committee will represent "Eclipse UOMo, STEM, and JSRs involved in, e.g. 331 or JCP.next"


On Thu, Jul 26, 2012 at 6:17 PM, Werner Keil <werner.keil@...> wrote:
Ok, think of the Top 10 of the Fortune 100, then you get there...


On Thu, Jul 26, 2012 at 6:01 PM, Reza Rahman <reza_rahman@...> wrote:
I guess I'm not sure how to define smaller systems exactly. I work mostly with the flagship corporate applications of Fortune 500 to Fortune 1000 companies and some government organizations (as well as the occasional startup). Most of them indeed do use the solutions you mentioned. Most of the people I talk with are in the same boat.


On 7/26/2012 11:45 AM, Werner Keil wrote:
If it happens infrequently, then you probably deal with smaller systems and not complex stacks like BPM, Portal, etc. more frequently...

Also many large customers where license fees matter tend to demand local deployment on a smaller container like Tomcat, TomEE, Jetty or similar while the Production stage uses JBoss AS, WebLogic or WebSphere depending on the vendor relations of the particular client.

At the moment even that stage requires dual deployment to 2 of these 3

Werner

On Thu, Jul 26, 2012 at 5:39 PM, Reza Rahman <reza_rahman@...> wrote:
Please note my earlier email about "nice to have" vs. an actual compelling need. The particular issue you mention does happen somewhat infrequently (and hence I see as an edge case) and are generally solvable in the vast majority of cases using things app server class-loading tweaks (when it is even needed beyond simply using Maven and being careful about what's placed in the application server's classpath).


On 7/26/2012 11:30 AM, Jason T. Greene wrote:
Really? You have never seen users complain about EE classloader isolation problems? It's pretty common these days for EE deployments to suck in 10+ libraries that conflict with another deployments 10+ libraries.

On 7/26/12 10:27 AM, Reza Rahman wrote:
Thanks for the clarification, but I don't think that I've misinterpreted
much. The overwhelming indication the way I've seen it first hand is
that people don't really need general modularity that much and have much
more bread-and-butter concerns.

On 7/26/2012 11:15 AM, Jason T. Greene wrote:
I think Jeff is frustrated because we are missing his underlying
point. What I think hes saying (and I am sure he will correct me), is
that we need standardized modularity badly. Some are sick of the
packaging and portability challenges in Java EE, and are considering
other options.

To his point we should be careful not to equate perceptions of low
OSGi use with users not wanting modularity.

On 7/26/12 9:28 AM, Reza Rahman wrote:
I can understand that this is something you feel strongly about, but
kindly get a hold of yourself (and I know you can do better :-)). I do
talk with everyone that I can about these issues as frequently as I can
simply because I care (and have absolutely no personal stake in any of
this). The reality that I see consistently matches up very closely with
what Jevgeni is saying rather than what you are saying, sorry.

On 7/26/2012 10:19 AM, Jeff Genender wrote:
Guys,

I don't get the support for the marketing drivel.  We all come from
different backgrounds. Be it Jboss modules, OSGI, roll your own, or
whatever.  If you want data, go look at the Jboss modules, Geronimo
(Websphere CE), Glassfish, Equinox, Karaf, Felix user mailing lists
and the number of blogs on the subject.  Go do your own count of
users... That's *not* marketing... Thats *not* anecdotal... That's our
users. That is who we represent. That's *real* data. guess what...
They *use* our designs. Let's please stop the BS at this point.  This
is a dead horse.  If you have something useful to contribute, please
do it...but let's stop the +1s on the loaded marketing material.

Jeff
Sent from my iPhone

On Jul 26, 2012, at 9:04 AM, Reza Rahman <reza_rahman@...
<mailto:reza_rahman@...>> wrote:

+1 (and I can guarantee that I'm a dispassionate observer on this one
:-)).

On 7/26/2012 8:23 AM, Jevgeni Kabanov wrote:
I'm glad we agree on the sentiment.

The paper is NOT based on customer data. This was a community-wide
poll with 1450+ answers. It agrees with other larger polls, e.g. one
conducted by Eclipse. It certainly is not my side of the fence, it's
what the world looks like, at least in the outline.

My point was that OSGi adoption is fairly low, and it's the
poster-boy of Java modularity story. Is there an actual need outside
the largest shops? Can we accommodate the largest shops in the spec
without impacting the majority of the community? These are important
questions that need answering before we commit to any one solution.

JK

--
Founder & CEO of ZeroTurnaround
@ekabanov | Skype: ekabanov | http://www.linkedin.com/in/ekabanov

On Thursday, 26 July 2012 at 15:17, Jeff Genender wrote:

Jevgeni,

I have to disagree vehemently with your fist comment. Your
presentation of your paper is strawman. Your paper/analysis is from
your customers which is your side of the fence.  You have a small
slice of a different sort of customer and your survey is directed
at people who use JRebel and its likes which is anti OSGi in
nature.  Different strokes for different folks but I am certainly
not calling yours anecdotal... just strawman. ;-)

I wasn't stating OSGi is the end-all.  But it does fit a need for
what people want form what *I* see.  People want the same thing
with LiveRebel.  The areas I listed is what LiveRebel helps to
define as well.

Hence, what you produce is exactly what I want and what your last
statement pretty much summed up.  We need something that allows
someone to plug in whatever modular system for now, be it OSGi,
JBoss Modules, or even LiveRebel.  You stated exactly what I want
to see.

Jeff


On Jul 26, 2012, at 6:57 AM, Jevgeni Kabanov wrote:

This all is very anecdotal. In our survey most folks did not
indicate that they use OSGi or anything like it:
http://files.zeroturnaround.com/developer-productivity-report/zeroturnaround-developer-productivity-report-2012.pdf

(only a third are our customers, the rest just the folks across
the community that responded)

There were also a bunch of open questions and although the no
downtime provisioning of application is a great concern, there
were fairly little issues with multiple library version. And
modularity without a good isolation model is not a way to solve
hot update or the class loading issues you mentioned.

I'm afraid we're trying to solve the issues of the largest shops,
which are always more complex than the rest and probably do need a
custom solution built on OSGi or whatnot. And they already have
access to OSGi on the Glassfish, Websphere and so on.

Wouldn't it make more sense to accommodate OSGi as an optional
extension of the spec and just define better interoperation? I'm
afraid that baking modularity into the Java EE spec will introduce
more complexity than it's worth for most of the Java EE ecosystem.

JK

--
Founder & CEO of ZeroTurnaround
@ekabanov | Skype: ekabanov | http://www.linkedin.com/in/ekabanov

On Thursday, 26 July 2012 at 14:41, Jeff Genender wrote:

Hi Craig... thanks for the response and I darned well agree with
a lot in this email ;-)

answers in line...

On Jul 25, 2012, at 7:30 PM, Craig Ringer wrote:

On 07/25/2012 09:53 PM, Jeff Genender wrote:
In my world, I am seeing users pushing modularity in front of
JavaEE and we are really missing this boat. A large section of
my clients are moving to OSGi stacks picking and choosing what
they want in their stacks, with some building their own JavaEE
light containers (JTA, JPA).

Can you explain in a bit more detail what problems they're
encountering that leave them forced to take this option?
Application and business problems, not just the common "we need
X because we've always used it" issues I see come up sometimes.

Here are what I usually hear:

1) The comments made come along the line of the thick stack and
having resources used by major components that aren't used.
Complaint is EE-bloat.
2) Ability to hot deploy/undeploy without corrupting the
classloaders. Example... try to deploy/deploy a war many times in
a standard JavaEE container until an OutOf Memory exception
occurs.
3) Ability to provision applications and services on the fly
without having to reboot - think cloud-like Applications As A
Service (AaaS).
4) Ability to prevent class clashing with multiple versions.
Wanting to run multiple applications in the same container
without worry for parent classloading corruption - the class tree
classloading issues.
5) Dependent execution. The ability to run transitive
dependencies on other applications/jars, much like a Unix inti.d
or Windows services model. i.e. an application can;t run until
its other dependent applications are running.

OSGi seems to wor in this model, albeit with a great amount of
pain.



Do you have people who really must swap out the JTA
implementation in a an app server with a different one in order
to meet business or application requirements? JPA I fully
understand, but JTA? I'm surprised and interested by that.

Yes, many of my clients are interested in the Blueprint JTA
implementation or use a local resource like Spring. Hence those
who want to use Spring local transactions can rip out the JTA, or
if they need XA, they wire up Aries/Blueprint and enable
aries-transaction. I see this choice a lot.


I'm having very frustrating problems with the lack of
plugability of some of the upper layer stuff myself. Hibernate
is a very poor fit for the needs of an app I'm working on, but
getting EclipseLink to integrate well into AS7 is a major pain.
I appreciate the need for pluggability at least at the higher
levels of the stack, and it's been a major source of pain for me
since I started working with Java EE.

My comments were specific to CDI and some low level, tightly
integrated components in the server like the EJB3
implementation, JTA, JCA, etc. These are tightly integrated and
- from what I've seen in AS7's sources and on the bug tracker -
the existing SPIs appear inadeaute to allow them to simply be
swapped out and replaced. I'd *love* to be wrong about this, but
my experience even trying to swap out theoretically pluggable
things like JPA implementations argues against it.

I would like to see a certain baseline of infrastructure locked
in place as something thatthe app server does not have to
support replacing (it still may if it chooses). In exchange,
certain higher level components like JSF2, JPA2, maybe JAX-RS,
etc would *have* to support being swapped out with either
app-bundled implementations or modules installed in the app
server. This would give vendors realistic test targets and
narrow the number of configurations to something (almost)
testable. It would also make it clearer which specs need really
complete SPIs as a priority.

As for needing a module system: I could not possibly agree more,
and think that things like CDI *should* be modules within the
app server - for app server maintainability and good design.
Sure enough you'll see that all the low level components in AS7
are modules. I just don't think the spec should require the
server vendor to support applications swapping out arbitrary
modules; that needs to be confined to modules implementing specs
where there's a good enough SPI.

The trouble with the module system issue is that JBoss modules
is probably a bit too basic, and OSGi is (IMO) convoluted and
horrible to work with. There isn't a really good candidate.

I completely agree with you... but I am just concerned we are
going to miss the boat if we keep putting this off. ;-)

Jeff


--
Craig Ringer



No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2012.0.2171 / Virus Database: 2437/5147 - Release Date:
07/22/12



No virus found in this message.
Checked by AVG - www.avg.com <http://www.avg.com>
Version: 2012.0.2171 / Virus Database: 2437/5156 - Release Date:
07/26/12











No virus found in this message.
Checked by AVG - www.avg.com
Version: 2012.0.2171 / Virus Database: 2437/5156 - Release Date: 07/26/12















[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Modularization Framework/SPI

(continued)

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Modularization Framework/SPI

Jason T. Greene 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Modularization Framework/SPI

Jeff Genender 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Modularization Framework/SPI

Reza Rahman 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Modularization Framework/SPI

Jason T. Greene 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Modularization Framework/SPI

Werner Keil 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Re: Modularization Framework/SPI

Reza Rahman 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Re: Modularization Framework/SPI

Werner Keil 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Re: Modularization Framework/SPI

Reza Rahman 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Re: Modularization Framework/SPI

Werner Keil 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Re: Modularization Framework/SPI

Werner Keil 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Re: Re: Re: Modularization Framework/SPI

Werner Keil 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Modularization Framework/SPI

Werner Keil 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Re: Modularization Framework/SPI

Reza Rahman 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Modularization Framework/SPI

Jason T. Greene 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Modularization Framework/SPI

Werner Keil 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Modularization Framework/SPI

Jevgeni Kabanov 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Modularization Framework/SPI

Werner Keil 07/26/2012

[jsr342-experts] Re: [javaee-spec users] Re: Re: Modularization Framework/SPI

Markus Eisele 07/26/2012
 
 
Close
loading
Please Confirm
Close