Java Reference
In-Depth Information
Listing 2.7
The RomanticChocolateOffer class
package fancyfoods.chocolate;
import java.util.Calendar;
import fancyfoods.offers.SpecialOffer;
public class RomanticChocolateOffer implements SpecialOffer {
public String getDescription() {
return "A wonderful surprise for someone you want to impress.";
public Food getOfferFood() {
if (isNearValentinesDay()) {
return new HeartShapedChocolates();
} else {
return new SquareChocolates();
What's on offer depends
on time of year.
Is it early
private boolean isNearValentinesDay() {
Calendar today = Calendar.getInstance();
return today.get(Calendar.MONTH) == Calendar.FEBRUARY
&& today.get(Calendar.DAY_OF_MONTH) <= 14;
There's no need to export the fancyfoods.department.chocolate.offers package,
because nothing else in the application should depend on it. It's not always possible,
but a good goal in application design is to try to divide bundles into those with
exported packages but no package dependencies (like fancyfoods.api ) and those
with imported packages but no externals (like fancyfoods.department.chocolate ).
A bundle that both exports a lot of packages and imports a lot of packages is highly
coupled, and therefore fragile. The ideal dependency graph should look more like a
fork than like spaghetti.
How will other code get hold of the RomanticChocolateOffer if the package isn't
exported? To make the class available for dependency injection, you need to provide
metadata for the Blueprint service.
Blueprint metadata should live in a folder called OSGI-INF /blueprint. (If for some
reason you need to use a different folder, you can point Blueprint to your files by list-
ing them in an optional Bundle-Blueprint: header.) The filename doesn't matter,
but blueprint.xml is a popular choice.
Listing 2.8
A simple blueprint.xml file
<?xml version="1.0" encoding="UTF-8"?>
Namespace is important!
Search WWH ::

Custom Search