While I basically agree with you, Dan, I think your points speak very clearly
to the possibility of combinatorial explosion. While it's certainly possible
and even common to provide such services as JMS or Mail or even database
persistence from outside a formal Java container, the great disadvantage to
Fedora in trying to support such architectures is that there _aren't_ (to my
knowledge) forms that are anything like as rigid as the JEE specs for so doing.
Classpath is another story. It's quite true that most containers allow
classloading to be structured in various ways. In fact, I would say that nearly
every container has a different way of doing it! {grin}
I agree completely with your point about modularization. I don't want to ride
the OSGi hobby-horse too far, but I do think OSGi offers far and away the best
system for producing exactly that level of clean modularization, particularly
by offering means of strongly linking modules of code (Java packages) with
modules of deployment (jars as OSGi bundles). I think it worth bearing in mind,
however, that while architects and developers may (increasingly) see Fedora as
a set of parts, many sites are going to be much more interested in an
easily-deployable package. Offering an Erector set for repositories makes
possible very sophisticated repository architecture, but only to an audience
able to afford and interested in that level of investment.
---
A. Soroka
Online Library Environment
the University of Virginia Library
On Aug 12, 2011, at 11:14 AM, Daniel Davis wrote:
> Despite what vendors would have you think, the lines between kinds of
> "containers" and even system services have become rather blurred. Most
> of the commercial "app" servers provide servlet containers and EJB
> containers but may have other sorts of containers and services.
> Services (all kinds of middleware) such a JMS providers can live outside
> of containers entirely (or be implemented in micro-containers. JMS may
> be implemented in non-Java messaging systems. And most commercial
> products provide some means control the classpath outside the EAR/WAR
> distributions.
>
> Part of this may be the view that Fedora is a "product" to be deployed
> rather than a set of libraries to be built into a "product" by a third
> party. And the derived product is deployed into an execution
> environment. Supported by whoever built the derived product. If so,
> future refactorings of Fedora could keep this in mind --- to optimize to
> support build processes and largely drop the notion of a deployment
> (installer) altogether. The modularity has kind of been going in that
> direction for a while anyway.
>
> -- Dan Davis
>
> On 8/12/2011 10:37 AM, Aaron Birkland wrote:
>>> I'd like to suggest a different route, one already formally endorsed by
>>> Fedora. Moving the application to the OSGi framework will enable it to be
>>> deployed in almost any container (including many totally off the JEE
>>> specs), helped by the clean, stringent OSGi classloading architecture. It's
>>> an enormous amount of work to be done, certainly, but I'd suggest that it
>>> will be work of more lasting benefit than constructing in-project machinery
>>> to support multiple containers.
>> +1, for sure.
>>
>>> There might be some simple ways to help the community support itself
>>> without investing a lot of committer time in the effort. If one site has
>>> good schemes for this kind of deployment that aren't too onerous, that
>>> might be very helpful to start.
>> Right. In the link I posted yesterday, the jboss community seems to
>> have acknowledged that dependencies in wars that conflict with container
>> provided artifacts is a common problem, and there are some
>> configuration-based workarounds. I'm sure we could collect stories of
>> what works and what doesn't.
>>
>> -Aaron
>>
>>
>> ------------------------------------------------------------------------------
>> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
>> user administration capabilities and model configuration. Take
>> the hassle out of deploying and managing Subversion and the
>> tools developers use with it.
>> http://p.sf.net/sfu/wandisco-dev2dev
>> _______________________________________________
>> Fedora-commons-developers mailing list
>> Fedora-commons-developers@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
>
> ------------------------------------------------------------------------------
> Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
> user administration capabilities and model configuration. Take
> the hassle out of deploying and managing Subversion and the
> tools developers use with it.
> http://p.sf.net/sfu/wandisco-dev2dev
> _______________________________________________
> Fedora-commons-developers mailing list
> Fedora-commons-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
------------------------------------------------------------------------------
FREE DOWNLOAD - uberSVN with Social Coding for Subversion.
Subversion made easy with a complete admin console. Easy
to use, easy to manage, easy to install, easy to extend.
Get a Free download of the new open ALM Subversion platform now.
http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Fedora-commons-developers mailing list
Fedora-commons-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fedora-commons-developers
