×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Book Review: OSGi and Apache Felix 3.0

samzenpus posted more than 3 years ago | from the read-all-about-it dept.

Book Reviews 52

RickJWagner writes "OSGi is a Java framework that's designed to simplify application deployments in shared environments. It allows applications with differing dependencies to run side-by-side in the same container without any deployment time contortions. The end result is that your application that needs FooLib v2.2.2 can run right beside my application that needs FooLib v1.0, something not often possible in today's application servers." Keep reading for the rest of Rick's review.OSGi is actually more than that, though. It's a framework with a very granular component lifecycle model, so you can carefully manage when the various parts of your application start up. It contains a service registry, so your application can either advertise or consume services. It's a controllable application runtime framework, complete with shell language that allows administrative tasks to be performed.

All these things and more are covered in the book. The author assumes the reader knows nothing more than what an average Java coder would know, so the development environment is given great coverage. (As is increasingly common, Maven2 is the build mechanism being used. The author goes to great lengths to explain how to construct every .pom file you'll need.) By the way, you'll be needing plenty of .pom files, as you are going to be incrementally building a simple bookshelf application, adding functionality chapter by chapter.

The book's example business logic is nothing out of the ordinary, which is good. If you're new to OSGi you're going to have your hands full learning the ins and outs of packing applications, the component deployment cycle, etc. Any experienced developer is going to instantly recognize the business problem you're trying to solve, so at least you won't be bothered by that. There is plenty of new material to study otherwise-- even tasks as ordinary as logging or deploying a servlet are vastly different than what you're probably used to. I remember I once read an article on the web about a new Java spec, the article was called "Don't make me eat the elephant again!" Well, if you're new to OSGi and want to get started.... break out the silverware!

In some ways, I'd compare Felix to an application server. It's an environment you use to deploy your applications, and it comes complete with a shell language used to administer the container. (The shell language, called 'Gogo', is given it's own chapter. You're also given Gogo commands throughout the book as you develop, deploy, and run your application.)

OSGi specifies a "Bundle Repository", which is a place where you can place your deployment artifacts so others can access them when they're listed as dependencies to their applications. (All this is done in the manifest files, by the way. You're given a good overview of all of this.) The OBR is yet another part of the landscape that will become important to you, so it's given good coverage in several chapters as you need to access it.

The development tasks are carefully covered. You are given very clear instructions on Maven to start, later on the author might withhold a little information to make you work a little. (Hint: the book's sample code fills in gaps nicely, if you get stuck.) The book also includes a series of 'Pop quizzes' to help you check your understanding of the material. More than once I found I might've been reading a little too quickly and paged back-- sure enough, the material had been presented, but I hadn't been paying enough attention. I liked this part of the book.

The application you're building is realistic enough, and you incrementally add functionality to it to make it something similar to what you might actually need in the real world. You start with the basic object model needed for a CRUD application, then add on niceties like a text UI, logging, a graphical interface, etc. Along the way you're introduced to things like iPojo, which is a dependency injection mechanism for OSGi. (Remember that elephant? Here's a small chunk...)

The book ends with a nice-to-have chapter on troubleshooting issues and two appendices. The first one covers the development environment, Maven/Eclipse. The second one covers advanced topics that should be within reach for the reader by the time they've reached the end of the book.

So, what's the bottom line? I'd say this book is good for anyone who wants to learn OSGi in general, or Felix in particular. No prerequisites exist, except maybe basic competency in Java. For developers just shopping around for an instructional book, without a need to pick up OSGi..... I'd say maybe not. (Why clutter your brain with this stuff, unless you're going to put it to good use?) Overall, the book is well written and presents things in an easily understandable way. On a scale of 1 — 10, I'd give this book an 8.1.

You can purchase OSGi and Apache Felix 3.0, Beginner's Guide from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

52 comments

There are so many CMSs, frameworks (1)

Compaqt (1758360) | more than 3 years ago | (#35129268)

There are so many CMSs [cmsmatrix.org], frameworks, Javascript libraries, DBs (even open source), and other parts of the stack that you could have one person in the company just devoted solely to trying to keep up, and be able to provide advice when a team is considering implementing something or another.

It's hard to think that you'd be using the "best-of-breed" if you don't even know what's available.

Re:There are so many CMSs, frameworks (1)

Nerdfest (867930) | more than 3 years ago | (#35129358)

Or you could have 100 people writing your own version of each of them.

Seriously, design for change, make your best effort at picking a framework in a given area and start developing. Change later if you chose wrong, your're still going to be ahead of the game and you've learned something. Provide feedback to the Java community about your experiences and recommendations. Despite what some companies have people thinking these days, choice is a good thing.

Re:There are so many CMSs, frameworks (1)

Compaqt (1758360) | more than 3 years ago | (#35136390)

Yeah, don't get me wrong. Even the middle of the pack for various categories of frameworks/libraries are far superior to hand-rolled stuff that we all used back in the day.

The second part of my point is that it might actually be a good idea for larger organizations to actually have one person just devoted to testing new frameworks instead of devs having to guess on the applicability of a package for their company based on the its homepage.

Re:There are so many CMSs, frameworks (1)

nitehawk214 (222219) | more than 3 years ago | (#35129398)

I agree. But what is the alternative? To use only off-the-shelf or hosted CMS and issue tracking applications with no ability to customize at all? I suppose the opposite end of the spectrum is to roll your own system yourself. Either way the answer is "it depends...".

Disclaimer: I have written plugins for Atlassian's Jira using their original home-grown plugin framework and the new OSGi "Plugin 2" framework. Both can be headaches, and both are way easier than writing my own Issue Management system.

However I love that link to cmsmatrix. It quick accurately shows how absurd the area is.

Re:There are so many CMSs, frameworks (0)

Anonymous Coward | more than 3 years ago | (#35129542)

CMS?!? When did anyone mention a CMS??

Re:There are so many CMSs, frameworks (1)

BohKnower (586304) | more than 3 years ago | (#35129874)

I have big news for you, most framework are stackable, and you can use another framework like Spring to integrate them. Do not despair, start at your own pace and in a few days you will have a perfect architecture!

Yeah, libraries and imports - Java's strength. (0)

Anonymous Coward | more than 3 years ago | (#35129330)

In the mid 80s a computer came out with shared libraries. Multiple versions of the same shared library could be installed, and when an application needed a library, it would request the minimum version number required. If the API actually changed, then you would just have a different library altogether, so you could run both libraries besides each other. One would open 'library', the other, open 'library2', for example.

Java doesn't have libraries, it just has more and more classes on the classpath. So when your com.foo.bar API changes entirely, you can't do squat about it (well, apparently you can use the system this book is about). Your program has no means to say "import com.foo.bar from library" or "import com.foo.bar from library2".

This is similar to the annoyance of having two classes named the same on different paths. Instead of being about to do:

import com.foo.Bar;
import com.meerkat.Bar as MKBar;

so you don't have to write the full class name in your code... you can't.

Re:Yeah, libraries and imports - Java's strength. (1)

Cougar Town (1669754) | more than 3 years ago | (#35129676)

Sounds like the API version problem that would affect any language. If the API changes, you have no choice but to use a specific version that matches your app (without modifying/recompiling the app, that is). Java is the same, and Java apps can specify jar dependencies and versions of those.

But what we're talking about here isn't even that. We're talking about just one application (the app server) that runs multiple, sandboxed pieces of code (by "sandboxed" here I mean keeping these pieces of code separate from each other and potential conflicts, not running in a security-restricted area). You'd have to sandbox this in C or anything else too if it's all running in the same process. What happens if Apache mod_a requires libfoo 1.5 but Apache mod_b requires a more recent and incompatible libfoo 2.0? It's all in the same process. The OS's linker isn't going to just load multiple (potentially conflicting) versions of the same thing into the same process. If you're sharing libs, you'd still have to sandbox the modules within your runtime environment so that the right module hooked up to the right library code and didn't interfere with other modules.

(Someone please correct me if I'm wrong here and operating systems have evolved the ability to automatically know what parts of your code are "pluggable" and need to be sandboxed, or if multiple conflicting libraries can be loaded into a single process with no conflicts... I haven't done systems programming for a few years)

Basically, what you're saying applies to applications using shared libraries, and it's not much different in Java, other than the fact that Java ClassLoaders do the work instead of the OS's shared library subsystem. And when you're talking about one application that loads multiple modules/plugins/applets/whatever you'll have to sandbox them since it's still all running in the same process. This is where OSGi comes in.

(disclaimer: this isn't a Java vs. anything post... just trying to describe why OSGi is useful and why that fact doesn't necessarily mean anything good or bad about Java itself... as for the imports... yep, the language wasn't designed to support "import ... as ..." ... I don't mind that though, since I can count on one hand the number of times it would've been useful to me in my 12 years of Java development... ymmv)

Re:Yeah, libraries and imports - Java's strength. (-1)

Anonymous Coward | more than 3 years ago | (#35130674)

Someone please correct me if I'm wrong here and operating systems have evolved the ability to automatically know what parts of your code are "pluggable" and need to be sandboxed, or if multiple conflicting libraries can be loaded into a single process with no conflicts... I haven't done systems programming for a few years

.NET has had strong assembly versioning and side-by-side execution built in since version 1.1 (i.e., for the last 8-9 years).

It's simple enough that for the most part it "just works" (but like most .NET code, it's also very configurable well documented).

Re:Yeah, libraries and imports - Java's strength. (2)

nitehawk214 (222219) | more than 3 years ago | (#35129774)

Except this is exactly what OSGi is designed to work around. Each plugin runs in its own classloader, in effect sandboxing each one. One plugin can work on library, while the other works on library2.

Now if you need one piece of java code that depends on 2 versions of a library. Yep you are screwed. However I have never had a case of

As far as api vendors breaking library compatibility without notifying anyone. Yes this sucks, and yes this exists in every language I have ever worked in. If you are lucky the classes wont compile so you know what is comming.

Re:Yeah, libraries and imports - Java's strength. (1)

godefroi (52421) | more than 3 years ago | (#35138948)

Just going to point this out, because no one seems to have pointed it out yet, but .NET solved this problem from the beginning. Libraries are versioned, and even (optionally) signed, and the correct version is always loaded, if it was signed. If not, the available version is loaded, and this behavior can be overridden through configuration at runtime, such that a reference to a library can be "redirected" to another version.

It's even possible to load multiple versions of the same library at the same time, and use different versions of the same class, as needed.

Java in a nutshell (0)

Anonymous Coward | more than 3 years ago | (#35129386)

The application you're building is realistic enough, and you incrementally add functionality

Then you a servlet container, a "dependency injection mechanism", and some "beans" whatever the FUCK they are.
Later your application collapses under unmanageable complexity, and you wish you'd avoided the Java ecosystem completely.

Re:Java in a nutshell (1)

Anonymous Coward | more than 3 years ago | (#35129724)

I know this hell, but I still prefer java over c++, .net, php or ruby for most non-trivial tasks.

Re:Java in a nutshell (3, Insightful)

Cougar Town (1669754) | more than 3 years ago | (#35129750)

If those things cause your application to collapse under unmanageable complexity, then those things probably weren't the right tool for the job, or you didn't know how to use them.

It sounds like you don't understand dependency injection or beans, so you're very likely to end up hating it all and losing control of your project. If you do understand those things, then you know when they are appropriate to use and when not to, so you don't end up hating something without a valid reason simply because you didn't understand how to use it.

This really simple application of making informed, logical decisions applies to all areas of programming (in any language) and most other things in life. You'll learn that as you mature.

Java, huh? (1)

goose-incarnated (1145029) | more than 3 years ago | (#35129636)

Your application would run within an application framework, which runs on an Application Server, which runs on a JVM, which runs on an OS, which then gets deployed into a node in some cloud. All to solve some problem that's already been solved.

Sometimes I look at the crap that is most java enterprise development, and wonder what the hell is preventing the load of manure from collapsing under its own weight - then I realise that that is why it takes a minimum of a dev-team of at least 6 people to do *anything* at all, within this app-framework, within the app-server, within the jvm ....

Re:Java, huh? (1)

BitHive (578094) | more than 3 years ago | (#35129940)

Feh, that's nothing a 10,000-line XML config file can't solve! Power tools for power users!

Re:Java, huh? (3, Interesting)

Cyberax (705495) | more than 3 years ago | (#35130084)

Uhm. Have you ever had a thought that 'solved' problems tend to be unsolved in reality?

15 years ago most of Java enterprise stuff would have been written in crashy C++ with a lot of impenetrable CORBA mappings and weird UI frameworks. Or maybe if you are 'lucky' in impenetrable COBOL.

And actually, I can write software in Java (and now in Scala) single-handedly faster than several Python programmers. Because I know how to use all these tons of frameworks.

Re:Java, huh? (1)

goose-incarnated (1145029) | more than 3 years ago | (#35130260)

Uhm. Have you ever had a thought that 'solved' problems tend to be unsolved in reality?

Yes . Yes I have. However, when the "problems" being solved are problems caused by using the tech in the first place, then I've little sympathy. The enterprise "java app" is actually a plugin to a framework which runs on an application server. To get your code to compile/test/debug cycle you need all 3. Not really a problem, until you find out that each of them have their own rats nest of xml configs, in not-quite-readable form. But not a problem, because yet another 3 plugins exist to provides a web-frontend to each of those java stacks. Of course, you end up subclassing a class that has already been subclassed 8 times, with 4 different xml configs.

The "complexity" introduced is entirely artificial, and results in a recursive nightmare of "we need to write $Y to solve $X", when $X was a result of "we need to write $X to solve $Z". There is no more complexity in the majority of problems that java enterprise stacks gets used for than there was before, only now it takes an army of devs 3 years to develop the stack, then an entirely different army gets assigned to maintain it.

Don't get me wrong - I'm all for more abstraction, only the problem I see with all of these chained stacks is that they are abstracting *away* from the solution and towards a technology, and not abstracting towards the solution and away from the technology .

15 years ago most of Java enterprise stuff would have been written in crashy C++ with a lot of impenetrable CORBA mappings and weird UI frameworks. Or maybe if you are 'lucky' in impenetrable COBOL.

And actually, I can write software in Java (and now in Scala) single-handedly faster than several Python programmers. Because I know how to use all these tons of frameworks.

And I can solve most problems faster in Lisp than in Java, C++, python or most other things. What was your point?

Re:Java, huh? (1)

Cyberax (705495) | more than 3 years ago | (#35130960)

"The enterprise "java app" is actually a plugin to a framework which runs on an application server. To get your code to compile/test/debug cycle you need all 3."

Sure. And you also need an OS, and microcode in firmware. Oh, and probably electric connection as well.

"Not really a problem, until you find out that each of them have their own rats nest of xml configs, in not-quite-readable form. "

My current app has exactly one 20-line XML config, even though it uses Hibernate, Guice, GWT, querydsl, Wicket with about 50 indirect dependencies.

Though I'm going to move it back to Maven, so I guess I'll have to live with 10-20 kilobytes of POM files because they are nicer tha uber-kewl DSLs.

"But not a problem, because yet another 3 plugins exist to provides a web-frontend to each of those java stacks. Of course, you end up subclassing a class that has already been subclassed 8 times, with 4 different xml configs."

And _that_ is pure nonsense.

"Don't get me wrong - I'm all for more abstraction, only the problem I see with all of these chained stacks is that they are abstracting *away* from the solution and towards a technology, and not abstracting towards the solution and away from the technology ."

Whoa, a whole shitload of managerial bullshit. Hint: you should use word 'synergistic' more.

Frameworks merely allow one to work on the solutions with additional tools. That's all.

"And I can solve most problems faster in Lisp than in Java, C++, python or most other things. What was your point?"

I somehow doubt it. LISP programmers always brag how LISP is uber-productive, yet the end result of 50 years of LISP is dying Emacs. At least Python people produce interesting software.

Re:Java, huh? (1)

badkarmadayaccount (1346167) | more than 3 years ago | (#35163960)

You do know there is flight reservation management software, and web-store CMSes written in LISP, right? And what's wrong with emacs? LISP is pretty much perfect, thing is, everything else is good enough, making them eternal enemies...

Re:Java, huh? (1)

Cyberax (705495) | more than 3 years ago | (#35169144)

"You do know there is flight reservation management software, and web-store CMSes written in LISP, right?"

No I don't. Haven't seen them, maybe it's possible to find them if one looks in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of The Leopard". Yeah, they might exist but they are irrelevant.

No popular sites I know use LISP, no popular tools I know use LISP, etc. And I know a lot of tools.

Oh, sorry. I know of one tool which used LISP. It was Microsoft's CLR, which initially used LISP to implement GC. It later got translated to C# and then moved to F#.

"LISP is pretty much perfect, thing is, everything else is good enough, making them eternal enemies..."

Yep. And you know what else is perfect? - Hitler!

About 10 years ago I've seen a nice quote: "LISP programmers use the 'lazy evaluation' system - programs are not written until they are called. And because they are not written they are not getting called. And so nothing gets written in LISP." Nothing has changed since then, except for LISP programmers' hubris maybe.

Re:Java, huh? (1)

badkarmadayaccount (1346167) | more than 3 years ago | (#35172524)

That CMS thing - Yahoo! Store. And I somewhat doubt you work in the appropriate niche markets. On the last bit - you're right - though it's a good tool (I might have overstated a bit), but if no one uses it, well, tough... so you are right in a sense. OTOH, I dare you to find a technical limitation that doesn't apply doubly so for another programming language.

Re:Java, huh? (1)

Cyberax (705495) | more than 3 years ago | (#35172586)

LISP is old. It's seriously old, even though its concepts are still very advanced.

It doesn't have pattern matching - a staple of modern functional languages, for example. There's no algebraic types and they can't be emulated using macroses without writing half of a buggy Haskell implementation in LISP. No good list comprehensions as well. LISP macroses also look antiquated now - there's no quasiquotation.

Also, not much tools.

And as for niche markets, they does not mean anything. There's a niche market in VB6, MUMPS, COBOL and Fortran.

Re:Java, huh? (1)

mswhippingboy (754599) | more than 3 years ago | (#35130432)

Your application would run within an application framework, which runs on an Application Server, which runs on a JVM, which runs on an OS, which then gets deployed into a node in some cloud. All to solve some problem that's already been solved. Sometimes I look at the crap that is most java enterprise development, and wonder what the hell is preventing the load of manure from collapsing under its own weight - then I realise that that is why it takes a minimum of a dev-team of at least 6 people to do *anything* at all, within this app-framework, within the app-server, within the jvm ....

Is someone forcing you to use these frameworks? These various frameworks hold much value to those that have need of them (such as enterprises, for which it was intended), otherwise they wouldn't exist. Just because you don't need them to for your particular app space doesn't mean they are "crap". It's easy to "dis" a technology that you don't understand. Generally, true appreciation (or educated criticism) of a given technology only comes with at least a rudimentary understanding of why things are the way they are.

Re:Java, huh? (2)

goose-incarnated (1145029) | more than 3 years ago | (#35130754)

Your application would run within an application framework, which runs on an Application Server, which runs on a JVM, which runs on an OS, which then gets deployed into a node in some cloud. All to solve some problem that's already been solved. Sometimes I look at the crap that is most java enterprise development, and wonder what the hell is preventing the load of manure from collapsing under its own weight - then I realise that that is why it takes a minimum of a dev-team of at least 6 people to do *anything* at all, within this app-framework, within the app-server, within the jvm ....

Is someone forcing you to use these frameworks?

Yes.

These various frameworks hold much value to those that have need of them (such as enterprises, for which it was intended), otherwise they wouldn't exist.

I find that to be an illogical argument - namely, that their very existence is a result of them adding much value. Just because something *exists* does not mean that it is "holds much value". Lots of things exist, that have very little value.

Just because you don't need them to for your particular app space doesn't mean they are "crap". It's easy to "dis" a technology that you don't understand. Generally, true appreciation (or educated criticism) of a given technology only comes with at least a rudimentary understanding of why things are the way they are.

My understanding of why the java enterprise space is the way it is, is (I hope) more than rudimentary. Why do you need an app framework? Why, so that your enterprise can readily and easily have new logic added to it? Why does your new logic get monstrous xml-files? To properly specify the behaviour of the new module, of course. But the xml file is too large and unwieldy to massage? Not a problem - lets create a framework and/or more modules that lets us edit *any* xml file. Why does your module *need* the app framework? Because the app framework supplies a basic architecture for pluggable modules (configured by xml, natch!) Wait, if thats the case, where's the reason for the application server? So that we can run multiple pluggable applications and/or frameworks that each get configured with a different xml file. Why do we need to run all of this? Because business logic is complex!!!!

See, here's my take - you see a problem, you write a general solution that is made specific by configuration parameters? No problem. You see a problem and write a module to solve that problem that gets used within a wider framework? No problem. You see a problem, and write a general solution to be used in a very specific framework, which results in a different problem, that gets a different solution, that results in a different problem, that gets a different solution ... etc ad nauseum.

(Yes, I've had to deal with this recently and am still sore that, of the entire codebase, a mere 1.2% LoC were devoted to actually solving the business problem - most of the code was spent inheriting, specifying interfaces, dumped in xml config files, or xml build files, doing weird reflection-fu at runtime for little to no actual gain in business logic, doing equally strange things with long chains of inherited classes (with each class only getting subclassed once, which sort of brings up the question of why separate the classes in the first place)).

The JAINSLEE is a good example of artificial complexity in action.

Re:Java, huh? (0)

Anonymous Coward | more than 3 years ago | (#35131252)

Not sure I understand your grudge entirely, but here goes.

What do you think frameworks do? or why are they necessary in the first place? They all started at some point solving a particular business use case. Eventually they are more and more generalized to simply serve several clients. Then they are taken a step further and are more generalized to solve a wider range of problems and to replace duplicate code. Then as the frameworks grow some of the code is bundled into specific functionality that a jar or a module does well and only that. Separation of concerns.
That way you can have many small modules that do certain things well, instead of a monolith that is hard to change, and you have to swipe the entire app out at one time instead of the more basic modules.
What's the problem with xml config files? They're just there to configure the modules. If you don't like that you can use yaml or some type of a language (ruby, groovy, whatever).

A business problem should only be solved with 1% of the codebase (config files mostly or rules).

Re:Java, huh? (0)

Anonymous Coward | more than 3 years ago | (#35131446)

What do you think frameworks do? or why are they necessary in the first place?

Open source frameworks exist to make open source developers feel important, and Java has a lot of important framework developers. If you ever actually trace through the framework code of a typical Java project, you'll quickly discover that 99% of the included modules are never used by any other module; they're simply included because someone once included them, and nobody had the clout to insult the original developer who included them by cutting them back out again.

I do agree with OP, which is that if you do cheap Java development, you spend a lot of worthless time dealing with the frameworks, and those frameworks are generally very, very badly written.

But it's open source, which means that you have choice. The choice to write your own framework.

Re:Java, huh? (1)

mswhippingboy (754599) | more than 3 years ago | (#35132232)

I have no idea how much experience you have in enterprise development, but your comments are consistent with someone who hasn't spent much time in this area.

Contrary to what many small time hackers and code monkeys think, most enterprise architects and CTOs are not complete idiots (though I'm sure some are). They are well aware of the additional complexity that powerful frameworks introduce. However, this complexity is a small price to pay when compared to the complexity of a thousand different applications all doing things their own way and trying to get them all to talk together. Today's frameworks make systems integrations that were a pipe dream a few years ago standard fare. Tools such as EAI (Enterprise Architecture Integration), ESB (Enterprise Service Bus), BPM (Business Process Modeling) and others are necessary tools in a modern enterprise today. Custom logic can easily (if you know what you are doing) be implemented in these systems using frameworks such as OSGi, EJB and others.

No doubt (as was seen in EJB 2.x) the configuration maintenance can become unwieldy. However, this is a fault of the implementation, not the concept and as EJB 3.0 showed, improvements can be made without losing the "goodness" of earlier versions. Over time the tooling improves and the implementations smooth the sharp edges.

OSGi certainly has it's thorns as do most complex frameworks, but it attempts to tackle some pretty complex problems.

You can find fault in just about any set of source code and Open Source projects are no exception, although the quality of code (and architecture) I've seen in popular Java Open Source projects is pretty high. While I'm sure you are a legend in you own mind, most of the code that gets committed in these high-visibility enterprise projects is produced by some really smart folks.

Re:Java, huh? (1)

kaffiene (38781) | more than 3 years ago | (#35148530)

The problem here is that /. is peopled with newbs who think that because they've hacked together a web-app in PHP, they understand all of what web development entails. The multi product, multiple system integration tasks you mention represent a business problem that these guys have never even seen before so they don't have the first idea what these ESB, SOA-type systems are developed to do. Hence, in ignorance, they claim that they do nothing at all but add redundant layers to a solution.

Hating Java is a religion here.

Re:Java, huh? (1)

Anonymous Coward | more than 3 years ago | (#35130546)

I've worked in both enterprise and startups and I can say that while Python and are all cool the reality is that most languages outside of Java & .net are missing many of the helpful libraries and functions you need to just get stuff done. I can't count the number of times we were working in python where we would need to do something complex because of requirements and we could easily find a java or .net library but python would have nothing.

Now if you have real rockstars you can recreate any library given time, but do you really want your rockstart developers constantly re-inventing the wheel? OSGI rocks and it solves some pretty hard problems. Read more about it and think about how you would solve similar problems in your language of choice. Even further, think of what it would take you to build an equivalent to OSGI, and get it adopted, tested, and usable by others. A lot of enterprise software while having some cludgy interfaces has the benefit of massive adoption which is helpful from both an integration standpoint as well as a stability standpoint.

Re:Java, huh? (1)

shutdown -p now (807394) | more than 3 years ago | (#35131142)

I can't count the number of times we were working in python where we would need to do something complex because of requirements and we could easily find a java or .net library but python would have nothing.

Out of curiosity, why not use Jython or IronPython in that case?

Re:Java, huh? (0)

abigor (540274) | more than 3 years ago | (#35130750)

No, you're pretty much wrong on all points. Let me guess: hobbyist programmer?

Re:Java, huh? (0)

Anonymous Coward | more than 3 years ago | (#35131160)

The hobbyist programmers I've seen have generally been more competent than the programmers I've seen employed in the field. Not all, of course.

Re:Java, huh? (1)

Anonymous Coward | more than 3 years ago | (#35134120)

Sometimes I look at the crap that is most java enterprise development, and wonder what the hell is preventing the load of manure from collapsing under its own weight - then I realise that that is why it takes a minimum of a dev-team of at least 6 people to do *anything* at all, within this app-framework, within the app-server, within the jvm ....

No, there is a secret shortcut: Maven. With one command (mvn archetype:create) you suddenly have all of that set up, and just set-to coding your business logic. Our team (average size: 2) has built two large products in a short space of time using Java, OSGi, (and Groovy, JRuby, Jython, and all the other bits using the JVM gives you access too).

Re:Java, huh? (1)

Adam Jorgensen (1302989) | more than 3 years ago | (#35135294)

Take a look at the Play web framework for Java. It's a refreshing dose of sanity that takes all the lessons learned about web dev in the last 10 years and applies them to Java. It's a really nice experience and it also supports Scala.

Available on Safari (0)

Anonymous Coward | more than 3 years ago | (#35129646)

http://my.safaribooksonline.com/book/software-engineering-and-development/ide/9781849511384

Re:Available on Safari (0)

Anonymous Coward | more than 3 years ago | (#35130276)

thanks - added to my 5-slot bookshelf for reading

Uh, that's not just possible, it's super possible (1)

Anonymous Coward | more than 3 years ago | (#35129666)

Tomcat already handles this situation just fine with separate classloaders for each application. And even if it didn't, actually application servers like WebSphere or Glassfish do handle it. Just don't put your libs in the global lib folder and it's been working for years.

Re:Uh, that's not just possible, it's super possib (1)

nitehawk214 (222219) | more than 3 years ago | (#35130144)

This takes it a step further. This can allow you to have different plugins using different libraries inside the same webapp/ear.

Re:Uh, that's not just possible, it's super possib (2)

nzNick (721082) | more than 3 years ago | (#35133448)

Dude - OSGI is soooo much more then Tomcats class loader separation. Think of a SINGLE web app (war file in Tomcat) that needs to use two versions of the same jar file (think apache-commons).... This is OSGI -binding to specific library versions WITHIN the same class loader context - all dependencies specified in the manifest file. But I agree with the reviewer - if you are not running into enterprise level lass loader issues, dependency issues, and other resource management (pooling etc) management, you probably will be a while away from needing OSGI, but in an enterprise scale environment, OSGI solves some very nasty problems. Nick

Eclipse (4, Interesting)

TopSpin (753) | more than 3 years ago | (#35129668)

The review failed to mention that OSGi is the basis of Eclipse; Eclipse is primarily a collection of OSGi managed components. Eclipse 'Rich Client Platform' (GUI, in other words) applications also inherit this model. The point is that OSGi is not merely another web application container specification; it is entirely suitable for non-web related work. The specification is free and several of the best implementations (Equinox, in Eclipse) are open source.

Re:Eclipse (0)

Anonymous Coward | more than 3 years ago | (#35130008)

The review failed to mention that OSGi is the basis of Eclipse;

In much the same way that a book on Oracle P/L fails to mention anything about MSSQL.

Re:Eclipse (2)

mswhippingboy (754599) | more than 3 years ago | (#35130314)

The review failed to mention that OSGi is the basis of Eclipse;

In much the same way that a book on Oracle P/L fails to mention anything about MSSQL.

In principal that's true, but because Eclipse is, by a very wide margin, the largest adopter of OSGi it does seem that it would have been mentioned at least as a side note.

It would be like a review of a book on using Objective-C for mobile development and never mentioning Apple.

Re:Eclipse (0)

Anonymous Coward | more than 3 years ago | (#35134082)

Except not quite, Apple has something to do with Objective-C and mobile devices, and mobile devices on which you can develop in Objective-C,\
Eclipse has nothing to do with servlet containers and application servers.

Re:Eclipse (0)

Anonymous Coward | more than 3 years ago | (#35131702)

Not only that, but WebSphere, Oracle WebLogic and Spring DM server are all built using OSGI as well. Its a solid solution for the hard problems that come with trying to isolate executing code from each other in a way that allow dynamic changes at any time. The app server authors have realised this and move to using the OSGI framework internally to make thing easier for themselves.

Getting started with OSGi and Felix (2)

smartin (942) | more than 3 years ago | (#35133314)

I haven't read the book yet but if you want to get started with OSGi and Felix just pop over to the Felix web site and read their getting stared documentation. It is clear and well written and I was able to get an OSGi app up and running is a couple or hours.

http://felix.apache.org/site/getting-started.html [apache.org]

Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...