From: Werner Keil <werner.keil_at_gmail.com>
Date: Thu, 26 Jul 2012 18:17:45 +0200
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_at_lycos.com> 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_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>> 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
>
>
>
>
