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_at_lycos.com
> <mailto:reza_rahman_at_lycos.com>> 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_at_lycos.com
> <mailto:reza_rahman_at_lycos.com>
> <mailto:reza_rahman_at_lycos.com
> <mailto:reza_rahman_at_lycos.com>>> 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> <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> <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 <http://www.avg.com>
> Version: 2012.0.2171 / Virus Database: 2437/5156 - Release Date: 07/26/12
>