Rob,
Curious - What application server do you use? Jetty embedded within
Felix?
I never suggested it wasn't possible to do (I know it's possible),
only that it isn't feasible for most organizations to attempt. But if
I've got my current generation of applications deployed on WAS,
WebLogic, or JBoss, most organizations would look at me like I was
crazy were I to suggest embedding Jetty within Felix.
Kirk Knoernschild
http://www.kirkk.com
http://techdistrict.kirkk.com
http://planet.kirkk.com
twitter: pragkirk
On Mar 26, 2009, at Mar 26, 8:56 AM, Rob Walker wrote:
Nice response ;)
I guess we just come at it from different directions. We do use OSGi
for web app development, and it's been very successful. We've got
rock solid GWT support, a decent spread of back end services,
including all the usual infrastructure plumbing like logging, user
auth, personalization etc etc. We did roll a lot of it ourselves,
but in truth most of the effort was figuring out how best to
architect things - which I suspect we'd have needed to do even if
we'd used more pre-built app framework functionality. We did pick
and choose a lot of free standing libs to help us, such as the usual
suspects of Log4j, Apache Commons Configuration, Hibernate, XML and
XSLT tools, a sprinkle of Spring Security, java html/chart/pdf
report generators like iText, TrueZip, and too many others too
mention.
In the end, it wasn't that much code or effort to wire each of these
libs in ways that exactly met our needs.
-- Rob
Kirk Knoernschild wrote:
Rob,
Thank you for the comment on my blog posting. I've responded, but
will also take a moment to respond here, as well.
I didn't intend to come across as narrowly focused. In fact, I
thought I was pretty broadly focused and had made it clear I was
talking about OSGi for web application development. I felt I was
pretty clear that OSGi proper (Equinox and Felix) is ready for
primetime, but the tooling and application platform is not. I'm an
OSGi advocate, but it's unrealistic to expect an enterprise
developer to glue together the components necessary to develop an
enterprise application using OSGi. That's why we use products and
frameworks - so we don't have to. You can respectfully disagree
with my argument, but the reality is that until better tooling
exists and the application platform exposes the capabilities of
OSGi, the enterprise is not going to use it. And I wish they could!
I shall now take a retreat to write some code...:-)
Kirk Knoernschild
http://www.kirkk.com
http://techdistrict.kirkk.com
http://planet.kirkk.com
twitter: pragkirk
On Mar 26, 2009, at Mar 26, 1:04 AM, Rob Walker wrote:
I added my 10c:
http://techdistrict.kirkk.com/2009/03/25/osgi-discontent-no-migration-path/#comment-7129
When did developing sotfware and apps get reduced to mindless lego
block assembly - where did all the real programmers go? I guess
they're writing code not blogs!
- R
Dave McLoughlin wrote:
Someone may want to comment/respond on this article:
http://techdistrict.kirkk.com/2009/03/25/osgi-discontent-no-migration-pa
th/
Dave McLoughlin | OpenLogic
720 240 4530 | phone
303 818 1686 | cell
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Ascert - Taking systems to the Edge
[email protected]
+44 (0)20 7488 3470
www.ascert.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Ascert - Taking systems to the Edge
[email protected]
+44 (0)20 7488 3470
www.ascert.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
