Merge Beans and Services now that AOPAdapter is functional

[jamoore]

Now that the Beans (/ejb) all configure themselves from Spring (injection and aop), it is no longer necessary to do delegation. We can merge the entire /ejb component into /server.

While doing this:

• #91 can change the Spring bean names
• can rename server to services (re #39)

[jmoore]

The JAAS security infrastructure (sessionContext.getCallerPrincipal) may have to be mocked to make this work. Alternatively, the SecurityManager? (#178) can internally use the method it sees best fit for determining the current user.

[jmoore]

r903 perhforms this merge. The entire /ejb directory has been removed. This complicates the ome.logic classes (lots of annotations) but makes overall development easier. The classes themselves need more documentation, but this needed to be put in place to have the canonical documentation (#306) simplified.

[jmoore]

Though #194 / #330 seem to prove that this merge isn't 100% (perhaps after #334), this is working well. There may be lacking documentation on why the change happened, but future developers should never really run into it. But for the record:

(10:46:54) chris: Can you give me a brief rationale as to the deletion of the EJB component?
(10:47:31) Josh: Pure duplication, I thought. Are you needing it?
(10:47:45) chris: No, no. Just curious how it's working now. :)
(10:47:53) Josh: Basically the goal was to reduce the number of things one had to touch (in general) when creating a service. (editor: see #306)
(10:48:05) chris: I didn't particular like the way it was working before either, heh.
(10:48:11) chris: Cool.
(10:48:18) Josh: There are still cases like RenderingBean where you're just wrapping something lower level, but the /ejb component was from the get-go a huge spring workaround.
(10:48:27) chris: Okay.
(10:48:36) chris: To avoid using Spring for that?
(10:48:57) Josh: Well, now the ome.logic.*Impl classes serve as both our internal spring classes and as our remoting beans. 
(10:49:20) Josh: when you're working without the container (no jboss) then you're working with the spring bean that you get out of the application context.
(10:49:22) Josh: only one.
(10:49:36) chris: Fair enough.
(10:50:14) Josh: when you're in jboss, the container creates it's own instance of the class (spring has one too), but the container instance (the bean) asks the spring context to configure it. So both are for all intents and purposes the same. 
(10:50:33) Josh: All that happens in AbstractBean.
(10:50:46) chris: Makes sense.
(10:51:24) chris: In a very odd, J2EE sort of way but making sense all the same.
(10:51:54) Josh: ;)