We Keep Coding

ATG Nucleus - EJB Relationship

I'm not closely familiar niether with ATG nor with EJB, only have a rough notion about the latter. Have just started to read about ATG, and it seems that one of its components (namely Nucleus) uses EJBs. It also seems like everything else in ATG is based on Nucleus.
I'll maybe have to work with ATG soon, so:
1) What is the relationship between ATG Nucleus and EJB?
2) Are EJBs that nucleus use usual EJBs?
3) Are EJBs necessary for Nucleus? Can I use something else instead?
4) Does Nucleus use full functionality of EJB or replaces it somewhere?
5) Can the functionality provided by Nucleus be fully replaced by EJBs?
6) Do I need to study EJB to use Nucleus? Will it improve my understanding of Nucleus?
Sorry if these questions are stupid, I'm just trying to speed up my studying.
Have also found an article about some DataNucleus (formerly known as Java Persistent Objects JPOX) on wikepedia. Is it the same Nucleus?

The Nucleus is not an EJB and does not use EJBs.
The Nucleus is a bean container, somewhat akin to a Spring Bean Factory or Application Context.
More specifically, it is a registry and a container for managing the lifecycle of and the binding between components.
In that sense, you may consider it to be similar to an EJB container, but it is a lot less complex.
The components it manages are simple JavaBeans (POJOs), though convention dictates that they are usually subclasses of an ATG-provided class (such as GenericService).
When you package up an ATG application, it is assembled into an EAR.
When this EAR is deployed and instantiated in a Java EE application server, it is the Nucleus that is started up. The Nucleus, in turn, instantiates the components it is responsible for.
You can package your application alongside EJBs, and you can deploy other EARs into the same application server, but these are not ATG applications. These do not use the Nucleus, and vice versa.
So, to answer your questions
1) What is the relationship between ATG Nucleus and EJB?
None.
2) Are EJBs that nucleus use usual EJBs?
No. The Nucleus does not use EJBs. It uses POJOs
3) Are EJBs necessary for Nucleus?
No.
Can I use something else instead?
Yes. I recommend you use the ATG-provided base classes and then extend those components you need to or create new ones as you need
4) Does Nucleus use full functionality of EJB or replaces it somewhere?
It replaces it in almost all respects.
The Nucleus is a registry as well as a component container. Every component managed by the Nucleus has a unique name in a Nucleus namespace. The Nucleus exposes these components via JNDI and Java name-resolution API methods.
You can also expose Nucleus components as web services (SOAP) and REST services (JSON over HTTP). ATG as a platform (technically not the Nucleus, but ATG-provided components running within the Nucleus) also provides a message-driven event framework for developing message-driven logic via JMS.
Further, the ATG platform (again not the Nucleus but ATG-provided components running within the Nucleus) provides a Repository framework which is an ORM layer, but not just for relational database data sources, but also LDAP, XML and other file data sources.
5) Can the functionality provided by Nucleus be fully replaced by EJBs?
At a technical level, yes.
However, EJBs (especially before EJB3) are very clunky and seem overly complex. Dependency injection, managed entities (ORM), etc. are just much less effort ATG, and also in some other frameworks (Spring Hibernate etc.)
Moreover, ATG as a platform (again, not technically just the Nucleus), provides a lot of sophisticated business functionality for personalisation and commerce.
6) Do I need to study EJB to use Nucleus?
No. Not at all
Will it improve my understanding of Nucleus?
Yes. But only in a very limited way. Any learning or understanding is a journey from the known to the unknown. The greater the base of the known is, the easier it is to move towards the unknown as you have many more jumping-off points.
If you already know Java EE very well, then you will be able to relate to what the ATG platform is doing under the hood and therefore will understand it easier. However, if you do not know EJB at all, then learning it for the sake of understanding ATG better will actually have a detrimental effect.
On the other hand, I think it it imperative that you know and understand Java EE web applications (JSP, Servlets, Filters, etc.) in order to work with ATG best.
Have also found an article about some DataNucleus (formerly known as Java Persistent Objects JPOX) on wikepedia. Is it the same Nucleus?
No. It is completely unrelated

ATG packages a stateless session EJB in every ear produced by its assembler, unless you exclude the DafEar module. The DafEar EJB is required for cross-application session functionality in ATG, including the dyn/admin web console and the ACC.
Each ATG EAR consists of multiple war files and one EJB jar file. You can see the EJB jar in and referenced by any of the ears that an ATG assembler produces:
atg_foo.ear/META-INF/application.xml:
<module>
<ejb>atg_bootstrap_ejb.jar</ejb>
</module>
The EJB is sourced at app assembly time from the DafEar module of the ATG install used to build the ear, e.g.: ${ATG_HOME}/DafEar/base/j2ee-components/
It is possible to build an ATG ear without an EJB, but without the dyn/admin and ACC. In some cases, such as the BCC/merch, it would be too impractical to exclude DafEar and access to critical admin components in dyn/admin such as DeploymentServer, so DafEar is most always deployed in ATG / Oracle Commerce apps.

Dependency Injection in OSGI environments

First some background:
I'm working on some webapp prototype code based on Apache Sling which is OSGI based and runs on Apache Felix. I'm still relatively new to OSGI even though I think I've grasped most concepts by now. However, what puzzles me is that I haven't been able to find a "full" dependency injection (DI) framework. I've successfully employed rudimentary DI using Declarative Services (DS). But my understanding is that DS are used to reference -- how do I put this? -- OSGI registered services and components together. And for that it works fine, but I personally use DI frameworks like Guice to wire entire object graphs together and put objects on the correct scopes (think #RequestScoped or #SessionScoped for example). However, none of the OSGI specific frameworks I've looked at, seem to support this concept.
I've started reading about OSGI blueprints and iPOJO but these frameworks seem to be more concerned with wiring OSGI services together than with providing a full DI solution. I have to admit that I haven't done any samples yet, so my impression could be incorrect.
Being an extension to Guice, I've experimented with Peaberry, however I found documentation very hard to find, and while I got basic DI working, a lot of guice-servlet's advanced functionality (automatic injection into filters, servlets, etc) didn't work at all.
So, my questions are the following:
How do declarative services compare to "traditional" DI like Guice or Spring? Do they solve the same problem or are they geared towards different problems?
All OSGI specific solutions I've seen so far lack the concept of scopes for DI. For example, Guice + guice-servlet has request scoped dependencies which makes writing web applications really clean and easy. Did I just miss that in the docs or are these concerns not covered by any of these frameworks?
Are JSR 330 and OSGI based DI two different worlds? iPOJO for example brings its own annotations and Felix SCR Annotations seem to be an entirely different world.
Does anybody have experience with building OSGI based systems and DI? Maybe even some sample code on github?
Does anybody use different technologies like Guice and iPOJO together or is that just a crazy idea?
Sorry for the rather long question.
Any feedback is greatly appreciated.
Updates
Scoped injection: scoped injection is a useful mechanism to have objects from a specific lifecycle automatically injected. Think for example, some of your code relies on a Hibernate session object that is created as part of a servlet filter. By marking a dependency the container will automatically rebuild the object graph. Maybe there's just different approaches to that?
JSR 330 vs DS: from all your excellent answers I see that these are a two different things. That poses the question, how to deal with third party libraries and frameworks that use JSR 330 annotations when used in an OSGI context? What's a good approach? Running a JSR 330 container within the Bundle?
I appreciate all your answers, you've been very helpful!

Overall approach
The simplest way to have dependency injection with Apache Sling, and the one used throughout the codebase, is to use the maven-scr-plugin .
You can annotate your java classes and then at build time invoke the SCR plugin, either as a Maven plugin, or as an Ant task.
For instance, to register a servlet you could do the following:
#Component // signal that it's OSGI-managed
#Service(Servlet.class) // register as a Servlet service
public class SampleServlet implements Servlet {
#Reference SlingRepository repository; // get a reference to the repository
}
Specific answers
How do declarative services compare to "traditional" DI like Guice or Spring? Do they solve the same problem or are they geared towards different problems?
They solve the same problem - dependency injection. However (see below) they are also built to take into account dynamic systems where services can appear or disappear at any time.
All OSGI specific solutions I've seen so far lack the concept of scopes for DI. For example, Guice + guice-servlet has request scoped dependencies which makes writing web applications really clean and easy. Did I just miss that in the docs or are these concerns not covered by any of these frameworks?
I haven't seen any approach in the SCR world to add session-scoped or request-scoped services. However, SCR is a generic approach, and scoping can be handled at a more specific layer.
Since you're using Sling I think that there will be little need for session-scoped or request-scoped bindings since Sling has builtin objects for each request which are appropriately created for the current user.
One good example is the JCR session. It is automatically constructed with correct privileges and it is in practice a request-scoped DAO. The same goes for the Sling resourceResolver.
If you find yourself needing per-user work the simplest approach is to have services which receive a JCR Session or a Sling ResourceResolver and use those to perform the work you need. The results will be automatically adjusted for the privileges of the current user without any extra effort.
Are JSR 330 and OSGI based DI two different worlds? iPOJO for example brings its own annotations and Felix SCR Annotations seem to be an entirely different world.
Yes, they're different. You should keep in mind that although Spring and Guice are more mainstream, OSGi services are more complex and support more use cases. In OSGi bundles ( and implicitly services ) are free come and go at any time.
This means that when you have a component which depends on a service which just became unavailable your component is deactivated. Or when you receive a list of components ( for instance, Servlet implementations ) and one of them is deactivated, you are notified by that. To my knowledge, neither Spring nor Guice support this as their wirings are static.
That's a great deal of flexibility which OSGi gives you.
Does anybody have experience with building OSGI based systems and DI? Maybe even some sample code on github?
There's a large number of samples in the Sling Samples SVN repository . You should find most of what you need there.
Does anybody use different technologies like Guice and iPOJO together or is that just a crazy idea?
If you have frameworks which are configured with JSR 330 annotations it does make sense to configure them at runtime using Guice or Spring or whatever works for you. However, as Neil Bartlett has pointed out, this will not work cross-bundles.

I'd just like to add a little more information to Robert's excellent answer, particularly with regard to JSR330 and DS.
Declarative Services, Blueprint, iPOJO and the other OSGi "component models" are primarily intended for injecting OSGi services. These are slightly harder to handle than regular dependencies because they can come and go at any time, including in response to external events (e.g. network disconnected) or user actions (e.g. bundle removed). Therefore all these component models provide an additional lifecycle layer over pure dependency injection frameworks.
This is the main reason why the DS annotations are different from the JSR330 ones... the JSR330 ones don't provide enough semantics to deal with lifecycle. For example they say nothing about:
When should the dependency be injected?
What should we do when the dependency is not currently available (i.e., is it optional or mandatory)?
What should we do when a service we are using goes away?
Can we dynamically switch from one instance of a service to another?
etc...
Unfortunately because the component models are primarily focused on services -- that is, the linkages between bundles -- they are comparatively spartan with regard to wiring up dependencies inside the bundle (although Blueprint does offer some support for this).
There should be no problem using an existing DI framework for wiring up dependencies inside the bundle. For example I had a customer that used Guice to wire up the internal pieces of some Declarative Services components. However I tend to question the value of doing this, because if you need DI inside your bundle it suggests that your bundle may be too big and incoherent.
Note that it is very important NOT to use a traditional DI framework to wire up components between bundles. If the DI framework needs to access a class from another bundle then that other bundle must expose its implementation details, which breaks the encapsulation that we seek in OSGi.

I have some experience in building applications using Aries Blueprint. It has some very nice features regarding OSGi services and config admin support.
If you search for some great examples have a look at the code of Apache Karaf which uses blueprint for all of its wiring.
See http://svn.apache.org/repos/asf/karaf/
I also have some tutortials for Blueprint and Apache Karaf on my website:
http://www.liquid-reality.de/display/liquid/Karaf+Tutorials
In your environment with the embedded felix it will be a bit different as you do not have the management features of Karaf but you simply need to install the same bundles and it should work nicely.

I can recommend Bnd and if you use Eclipse IDE sepcially Bndtools as well. With that you can avoid describing DS in XML and use annotations instead. There is a special Reference annotation for DI. This one has also a filter where you can reference only a special subset of services.

I am using osgi and DI for current my project, I've choosed gemini blueprint because it is second version of SPRING DYNAMIC MODULES, Based on this information I suggest you to read Spring Dynamic Modules in Action. This book will help you to understand some parts and points how to build architecture and why is it good :)

Running into a similar architecture problem here - as Robert mentioned above in his answer:
If you find yourself needing per-user work the simplest approach is to
have services which receive a JCR Session or a Sling ResourceResolver
and use those to perform the work you need. The results will be
automatically adjusted for the privileges of the current user without
any extra effort.
Extrapolating from this (and what I am currently coding), one approach would be to add #param resourceResolver to any #Service methods so that you can pass the appropriately request-scoped object to be used down the execution chain.
Specifically we've got a XXXXService / XXXXDao layer, called from XXXXServlet / XXXXViewHelper / JSP equivalents. So managing all of these components via the OSGI #Service annotations, we can easily wire up the entire stack.
The downside here is that you need to litter your interface design with ResourceResolver or Sessions params.
Originally we tried to inject ResourceResolverFactory into the DAO layer, so that we could easily access the session at will via the factory. However, we are interacting with the session at multiple points in the hierarchy, and multiple times per request. This resulted in session-closed exceptions.
Is there a way to get at that per-request ResourceResolver reliably without having to pass it into every service method?
With request-scoped injection on the Service layers, you could instead just pass the ResourceResolver as a constructor arg & use an instance variable instead. Of course the downside here is you'd have to think about request-scope vs. prototype-scope service code and separate out accordingly.
This seems like it would be a common problem where you want to separate out concerns into service/dao code, leaving the JCR interactions in the DAO, analogous to Hibernate how can you easily get at the per-request Session to perform repo operataions?

java spring starter question

I am looking into Spring and I want to ask the following:
I see that there is Spring2 and Spring3.
My question is, should I ignore Spring2, or If I read on Spring2 the concepts are the same in Spring3?
I ask this, because when starting to look into EJB2 I found out that it is obsolete (replaced completely by EJB3) and I wasted my time.
Thank you

You can consider them to be the same. EJB2 to EJB3 was an incredible step forward. Spring 3 is more functionality and tons of marketing.

EJB and Spring have nothing to do with one another. Versions numbers are just numbers.
Spring 3 is an incremental imporvement on Spring 2, and works in much the same way.
EJB3 was a complete redesign of EJB 2 (and, clearly, is "inspired by" Spring).

Information about Spring2 will apply to Spring3, but some portion will be replaced with changed and/or new functionality.
Knowledge about EJB2 is not obsolete, there still exist EJB2 implementations that will need developers to maintain them. Learning EJB3 seems (to me anyway) like the way to go vs learning EJB2.
For Spring3, there is a reasonable reference document available online here.

EJB3 with Spring

I have understood that if I use EJB in Spring context, I get all the same benefits as if I was using it in "pure" EJB3 environment, is this true? I have googled but can't find a definitive, clear answer.
For example, let's say I have a session bean that updates some tables in the database and it throws a System Exception. In "pure" EJB3 environment the transaction is rolled back. What if I for example #Autowire this bean using Spring, does Spring take care of the transaction handling same way as does the EJB3 container? Or what? Does it maybe require some specific configuration or is it fully "automatic"?

I have understood that if I use EJB in
Spring context, I get all the same
benefits as if I was using it in
"pure" EJB3 environment, is this true?
You usually use either POJO + Spring or EJB3. I'm a bit confused by what you mean by "EJB in Spring"...
POJO + Spring and EJB3 are quite close now, and have the same facilities when it comes to declarative transaction management.
I don't know all the details about security, but I would say that both technologies are also very similar.
Actually both Spring and EJB3 rely on other specifications. The important ones are: JPA (persistence), JTA (distributed transaction), JMS (messaging), JDBC (data sources). Good support for that exist in the two technology stacks.
Both technologies have become very flexible and you can choose what to use or not. So you can have EJB3 in an app. server and be very light. Or you can use Spring with all modules which is almost as heavy as a full-fledged app. server.
I think the EJB3 model is still a bit richer, with things like remoting, stateful session beans (SFSB), container-managed transactions, and extended persistence context. Plus the possible support of clustering depending on the app. server. But these are advanced features which are use seldom (and IMO require expertise).
See EJB3 vs Spring

spring has many features, one of which is transaction management, which uses a common abstraction accross all different orm implementations (jpa, raw hibernate, jdbc, jdo etc). The default behavior is that in a transactional method, a runtime exception causes a rollback (which is probably what you want), but you can also fine-tune the rollback rules.
However, none of this requires EJB. If you don't use EJBs (stateless, stateful, mdbs), JPA will be enough for that, and the spring jpa support is excellent. In 90% of the cases spring will provide everything you need without EJBs.
EDIT:
read this about Spring EJB integration

You can have Spring handle transactions and roll back accordingly. You have to configure it to do so, but that's also true of EJBs.
Nothing in life is truly "automatic". You have to tell the code what you want sometime.
The real question is: Why do you think you need both EJBs and Spring? Anything you can do with EJBs can be done using POJOs with Spring. What are EJBs buying you here?

I got very good answers with links to articles, and from those I compiled my understanding that yes, the session beans work the same way regardless of if they are used with Spring or without, as long as the beans are defined in the Spring context with <jee:jndi-lookup>. Also found a good, simple article about this: http://java.dzone.com/articles/ejb-30-and-spring-25
However I can't accept just one answer because to me they are all equally good, but none of them exactly in point :) Could be that my question was not clear enough to start with...
(It was suggested that I post this as an answer to my own question)

Why is the Spring framework called "non-intrusive"?

Spring framework is NON - INTRUSIVE.
Can you please elaborate this?
Thank You :)

Here, "non-intrusive" means that your application code doesn't need to depend on the Spring framework directly. Anything that can inject the appropriate dependencies will (theoretically) work just as well.

The main appeal of a nonintrusive framework is that it stays out of the way of your design and modelling activities. It stays completely out of the way until you need it.

It is perfectly possible to use Spring without any direct dependencies on the spring framework in your application code. That doesn't mean the code will continue to function without spring, since the functionality provided by spring will need to be replaced by another IoC container or code which directly instantiates all objects in a dependency chain, but it does mean that you can choose to wire things up with spring, or via some other mechanism.
However, to be really unintrusive with spring, you need to keep all of your configuration outside of your code, which means using XML for everything. This works beautifully in spring, but its a pain in the neck for developers and, since the advent of the widespread use of annotations in Java 5, isn't really the java way. So spring provides lots of annotations for wiring things together directly in your code. This can obviously create dependencies on Spring within the code, although all of the Spring tags are resolved at compile time, so you can still execute your classes outside of a spring context without any dependencies on spring jars and such. Also, wherever possible, custom spring annotations have been replaced with generic JEE annotations. With Spring 3, it is really pretty easy to use only JEE annotations plus a limited quantity of XML to initialize the application context.
The beauty of the spring way of doing things is that the underlying functionality which implements a feature can often be selected at runtime. If you are using an ORM system in a non-managed container for development, using a native session manager, you can easily switch to container managed sessions in production without changing any code whatsoever if you have configured the app to let spring handle transaction management. Methods that are marked as #Transactional will pick up a session and transaction automatically, regardless of the source, without any changes to the code. In fact, you can trivially switch to an entirely different ORM framework, if you are so inclined, though that's a pretty rare use case, in truth, so most applications will tend to have ORM framework specific code and/or queries in their data access code.
The difference between spring and an old-fashioned 'intrusive' framework is that intrusive frameworks often require you to implement particular interfaces or, even worse, force you to inherit from particular base classes, in order to access framework functionality. In the latter case, not only do you have a dependency on the framework you are using, but it severely limits your class hierarchy structure, too - in a language which only allows single inheritance. Recent versions of EJB learned from the elegance of Spring's (and others') less-intrusive model and EJB itself has since become much less intrusive (It's all about the POJOs).
I don't really see any support for irreputable's argument that spring is now a billion dollar beast that locks users in. Spring is, if anything, less intrusive than it has ever been while offering ever more functionality. It is certainly possible to lock yourself into spring, and a lot of devs are perfectly willing to do so precisely because the runtime overhead of using spring is so trivially small that most of us can't imagine a lot of scenarios in which we might remove spring from a project. If I want a fully managed JEE environment, I can configure for that (and run in the container of any available vendor). If I want to run in tomcat or jetty with 100% of configuration and runtime management coming from spring, I can do that, too. So I'm generally perfectly happy to use spring-specific functionality at the risk of lock-in unless the project requirements specifically forbid it. Spring adds very little overhead at runtime, so it is a low risk choice.
When push comes to shove, I find Spring to be far easier to learn than EJB. I can accomplish the same things with either methodology, but it is easier to bring in devs who are inexperienced if I'm using Spring compared to EJB, so hiring is easier, long term maintenance costs are lower, and release cycles are shorter.

No matter what the language direction, generally speaking, a framework is too intrusive, which is a voice of criticism, so I guess it is not because of this that non intrusiveness has become a "selling point" of publicity.
For example, spring and struts 2 use annotations, configuration files, conventions or reflection (other languages may be other ways) to achieve non-invasive, and the compilation and operation does not have formal dependence on the framework API.
But in essence, without this framework, our program simply cannot run correctly. These so-called annotations are customized. When and how they are processed are different. Think about the migration from gson to Jackson. The migration has costs and risks. Do you need users to write a new one?
In addition, how high is the probability of real migration? It feels very small.

years ago, there was this EJB beast, which was very "intrusive". Spring was touted to be a much simpler set of helper classes, and it was more like libraries than frameworks.
today, Spring becomes the new beast. As a billion dollar business, it is in their best interest to lock people in. Yeah, sure, you don't have a dependency problem, and you can quit Spring anytime.
With EJB, at least you have a few vendors to choose from.