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:
http://www.playframework.org/documentation/1.2.3/dependency
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:
http://fantom.org/sidewalk/topic/675
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_at_gmail.com> 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_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
>>
>>
>>
>>
>
>
>
>