迁移CDI应用至Karaf：blueprint-maven-plugin对EE注解的处理及编码建议

Let’s tackle your questions one by one, drawing on practical experience with Talend’s blueprint approach and cross-container Java/OSGi deployments:

1. How does blueprint-maven-plugin handle @Stateful, @Stateless, and CDI scope annotations? #

The blueprint-maven-plugin is built to generate OSGi Blueprint XML descriptors, which align with OSGi’s native dependency injection model—it doesn’t natively process Java EE EJB or CDI annotations out of the box.

For CDI scope annotations like @ApplicationScoped, @SessionScoped, etc., you’ll need additional integration layers (such as Pax CDI or Apache DeltaSpike) to bridge CDI and OSGi Blueprint. These tools can translate CDI annotations into Blueprint-compatible configurations, but the plugin itself won’t handle this automatically.

As for EJB annotations (@Stateful, @Stateless), the plugin ignores them entirely by default. To replicate EJB-like behavior in Karaf, you’d need to either:

• Use CDI-based replacements for EJB features (like DeltaSpike’s transaction and pooling extensions)
• Deploy an EJB container implementation in Karaf (which adds significant complexity to your deployment stack)

2. How to write new CDI code that works for both Java EE containers and Karaf? #

Stick to portable, standard CDI annotations to maximize compatibility across environments:

• Use @Inject for dependency injection (instead of EJB-specific lookup mechanisms)
• Prefer CDI’s @Named for bean naming, paired with standard CDI scopes (@ApplicationScoped, @RequestScoped)
• Avoid EJB-exclusive annotations like @Stateful and @Stateless unless you’re willing to add bridge layers for Karaf.

If you need transaction management or pooling (features EJBs provide), use CDI extensions like DeltaSpike’s @Transactional annotation—this works seamlessly in both Java EE containers and Karaf (with the DeltaSpike extension installed).

Also, ensure your code uses Jakarta EE APIs (not legacy Java EE) and avoids container-specific APIs (e.g., Wildfly’s proprietary classes) to keep it truly portable.

3. How does Karaf interpret these "irrelevant" annotations? #

If your code includes @Stateful, @Stateless, or other Java EE-specific annotations that Karaf doesn’t recognize:

• The annotations are completely ignored by the default Karaf OSGi container. Karaf won’t create EJB instances, apply transaction management, or handle pooling as these annotations dictate.
• If your code relies on the behavior these annotations provide (e.g., automatic transaction demarcation for @Stateless beans), your application will fail at runtime in Karaf because those expected features aren’t present.

The safest path is to either remove these annotations from code intended for cross-container deployment, or add the necessary OSGi extensions to support their functionality in Karaf.

内容的提问来源于stack exchange，提问作者SoBeRich