From: Werner Keil <werner.keil_at_gmail.com>
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_at_gmail.com> 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:
> 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
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
