The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

mortench (1) [Avatar] Offline
#1
I am relatively new to OSGI but just bought the PDF book and read most of it.
Some feedback:
1) The long section on OSGI logging makes me want to run screaming away of OSGI !!! The writing in the books was ok, but the OSGO subject of logging seems so overly complicated. I suspect this is overkill for most people that do not need loggers to be changed at runtime. I also suspect that I can personally continue to use plain old 1-line "java.util.logging.Logger" statements even in my OSGI bundles but the book does not mention this option so I am unsure. If using java's standard logger remains a possibility (?) the book should mention this !!
2) Hmm. OSGI seems to force all suppliers of OSGI modules to be experts in the OSGI lifecycle and multithreading. Not sure 80% of Java developers can do this. Is there a way to hide some of this complexity for OSGI clients that just need to implement one of my interfaces in a simple OSGI module by enforcing some lifecycle limitations and make anything single-threaded for specific clients?
3) Glassfish V3's OSGI support is what finally got me to consider OSGI for projects now, but the book does not mention Glassfish's OSGI support or the OSGI support of any other application servers. It would be nice with a small writeup detailing the app servers that support OSGI, incl. OSGI versions supported/limitations/extensions and how to leverage OSGI in applications servers.
4) I liked the section of JUnit testing with Pax Exam, but is lacks some information about how to do parameterized junit tests in Pax if possible (problem as JUnit's @RunWith(Parameterized.class) conflicts with the @RunWith that Pax uses).
5) I missed a section of how to use OSGI with CDI (Weld) for dependency injection etc. This is important as Weld is used in both the new JBoss and Glassfish.
6) Java as a language is increasingly becoming less important then the JVM with newer more interesting languages such as Scala, JRuby, Jython, Groovy that can be integrated with Java directly or through the javax.scripting api. Unfortunately, the book does not mention how/if OSGI can deal with other JVM languages. In particular I would be interested in examples of f.x. a JRuby script (not jar) + manifest file used as a OSGI module (to implement a service interface)?
7) Especially, liked the section on debugging and the earlier mention on cobtura !
Cheers,
Morten Christensen (www.41concepts.com)
sahoo (1) [Avatar] Offline
#2
Re: Feedback - Just read bought OSGIInAction and read most of it
Using OSGi in GlassFish is very simple. Take a look at
http://www.slideshare.net/wwwsahoo/osgi-java-ee-in-glassfish-3553192

For more questions, ask us in GlassFish forum:
http://forums.java.net/jive/forum.jspa?forumID=56&start=0

Thanks,
Sahoo
richard.hall (87) [Avatar] Offline
#3
Re: Feedback - Just read bought OSGIInAction and read most of it
First, sorry for the delayed response...normally I am notified about posts, but it appears that didn't happen in this case.

> I am relatively new to OSGI but just bought the PDF
> book and read most of it.
> Some feedback:
> 1) The long section on OSGI logging makes me want to
> run screaming away of OSGI !!! The writing in the
> books was ok, but the OSGO subject of logging seems
> so overly complicated. I suspect this is overkill for
> most people that do not need loggers to be changed at
> runtime. I also suspect that I can personally
> continue to use plain old 1-line
> "java.util.logging.Logger" statements even in my OSGI
> bundles but the book does not mention this option so
> I am unsure. If using java's standard logger remains
> a possibility (?) the book should mention this !!

Perhaps it wasn't as clear as it could have been, but the discussion on logging was just the example being used to discuss optional and dynamic imports. It was not intended to be an introduction to logging in OSGi.

You definitely can use Java logging in OSGi and Pax Logging does a good job of getting other logging solutions working in OSGi.

> 2) Hmm. OSGI seems to force all suppliers of OSGI
> modules to be experts in the OSGI lifecycle and
> multithreading. Not sure 80% of Java developers can
> do this. Is there a way to hide some of this
> complexity for OSGI clients that just need to
> implement one of my interfaces in a simple OSGI
> module by enforcing some lifecycle limitations and
> make anything single-threaded for specific clients?

It is true that OSGi exposes concurrency issues, but so does Java in general. Since OSGi is just a module/service layer over Java it isn't really possible for it to hide concurrency any more than Java could hide. Granted, event delivery, for example, is subject to different threads, so that can be tricky, but other than that OSGi doesn't create threads to drive user code.

In reality, it is the systems/frameworks built on top of OSGi that should hide concurrency for their users. For example, GlassFish is implemented on top of OSGi, but provides the normal Java EE mechanisms to shield enterprise developers from some complex concurrency issues.

> 3) Glassfish V3's OSGI support is what finally got me
> to consider OSGI for projects now, but the book does
> not mention Glassfish's OSGI support or the OSGI
> support of any other application servers. It would be
> nice with a small writeup detailing the app servers
> that support OSGI, incl. OSGI versions
> supported/limitations/extensions and how to leverage
> OSGI in applications servers.

Agreed, that could have been a good addition, but we ran out of space.

> 4) I liked the section of JUnit testing with Pax
> Exam, but is lacks some information about how to do
> parameterized junit tests in Pax if possible (problem
> as JUnit's @RunWith(Parameterized.class) conflicts
> with the @RunWith that Pax uses).

I'll let Stuart comment on that.

> 5) I missed a section of how to use OSGI with CDI
> (Weld) for dependency injection etc. This is
> important as Weld is used in both the new JBoss and
> Glassfish.

This is a space issue again. CDI would likely drag in too many topics to cover. The original target was 350 pages and we are over 500 now! smilie

> 6) Java as a language is increasingly becoming less
> important then the JVM with newer more interesting
> languages such as Scala, JRuby, Jython, Groovy that
> can be integrated with Java directly or through the
> javax.scripting api. Unfortunately, the book does not
> mention how/if OSGI can deal with other JVM
> languages. In particular I would be interested in
> examples of f.x. a JRuby script (not jar) + manifest
> file used as a OSGI module (to implement a service
> interface)?

While this is an interesting topic and could have been covered in the last part of the book, it is more of a niche topic of interest and certainly a niche topic for OSGi, so again we had to draw the line somewhere. Further, none of us are experts on this topic, so we try to stick to our core competencies.

> 7) Especially, liked the section on debugging and the
> earlier mention on cobtura !

Great, thanks.

Sorry again for the delayed response. If you respond to this message, email me too so I can double check to see if notifications are indeed working. Thanks.

-> richard

> Cheers,
> Morten Christensen (www.41concepts.com)