Context class

classic Classic list List threaded Threaded
6 messages Options
hash source hash source
Reply | Threaded
Open this post in threaded view
|

Context class

Hi all,

I am still at the stage of understanding the architecture before I can start efficiently contributing. I have a question about Context class and Spring. I understand that the ServiceContext for example has the actual implementations of the services injected via spring. However, I still don't understand why some functionalities that can be provided by spring is re-implemented in the Context class. I'm sure there is a reason behind this, I'm just trying to understand.

Currently, if Object o1 would like to access the PatientService, a call is made to Context.getPatientService() which in turns calls ServiceContext which finally looks up the class name in a map Object service = services.get(cls); (whose instinces are injected through spring).
First question, am I correct about how it works?

Second question. As i mentioned about is explained in question 1 is actually a re-implementation of Spring functionality (factories). In a standard spring app, we would just have a reference from the class c1
PatientService patientService;

and simply call patientService.foo() since the actual implementation is injected through spring.

Like i said, I'm sure there is a ratioinal behind how it is, and I'm not trying to correct anything at this point... just explain to me the logic behind how it's done please :)


Finally, I did not introduce myself in the previous email: I am a software developer with around 7-8 years of experience mainly in Java/Spring/Hibernate/etc... I live in Cleveland Heights, OH.
I have great interest in the culture of open source and the mentality behind it; also intewrested in the OpenMRS project in particular because of its humanitarian benefit and benefit potential.

Thanks!
hashsource

[hidden email] from OpenMRS Developers' mailing list
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|

Re: Context class

Hiya,

Off the top of my head and without looking at the code, I think you're correct about how it works.

As far as I remember, the reasons we did it this way are historic: when we first started out we were not sure we wanted to tie our API irrevocably to Spring. (It ended up happening anyway.)

Also, I think that in the earlier versions of Spring you couldn't do autowiring by annotation. We wanted to be able to call the API from anywhere without having to make the classes be ApplicationContextAware, and having to do xml-based dependency injection of services into controllers, etc, seemed very un-fun.

As I understand it the correct way of doing things today would be something like this:

interface PatientService { ... }

interface PatientDAO { ... }

@Service
class PatientServiceImp implements PatientService {
    @Autowired PatientDAO dao;
    ...
}

@Repository
class HibernatePatientDAO implements PatientDAO { ... }

Then to use the service, we'd do:

class ApiConsumer {
    @Autowired PatientService patientService;
    ...
}

But in that case wouldn't we only be able to access the API through spring-loaded beans (because only those could have their dependencies autowired)? I guess we could get around that by keeping Context.getPatientService() and have that return an autowired bean...

-Darius

On Fri, Aug 27, 2010 at 6:44 PM, hash source <[hidden email]> wrote:
Hi all,

I am still at the stage of understanding the architecture before I can start efficiently contributing. I have a question about Context class and Spring. I understand that the ServiceContext for example has the actual implementations of the services injected via spring. However, I still don't understand why some functionalities that can be provided by spring is re-implemented in the Context class. I'm sure there is a reason behind this, I'm just trying to understand.

Currently, if Object o1 would like to access the PatientService, a call is made to Context.getPatientService() which in turns calls ServiceContext which finally looks up the class name in a map Object service = services.get(cls); (whose instinces are injected through spring).
First question, am I correct about how it works?

Second question. As i mentioned about is explained in question 1 is actually a re-implementation of Spring functionality (factories). In a standard spring app, we would just have a reference from the class c1
PatientService patientService;

and simply call patientService.foo() since the actual implementation is injected through spring.

Like i said, I'm sure there is a ratioinal behind how it is, and I'm not trying to correct anything at this point... just explain to me the logic behind how it's done please :)


Finally, I did not introduce myself in the previous email: I am a software developer with around 7-8 years of experience mainly in Java/Spring/Hibernate/etc... I live in Cleveland Heights, OH.
I have great interest in the culture of open source and the mentality behind it; also intewrested in the OpenMRS project in particular because of its humanitarian benefit and benefit potential.

Thanks!
hashsource

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list
Brent Atkinson Brent Atkinson
Reply | Threaded
Open this post in threaded view
|

Re: Context class

Hi Hashsource,

I also was surprised by the fact that module developers couldn't use DI to inject resources like service instances and instead have to use the registry pattern to look them up. Additionally, the manual openmrs session management makes things complicated when you want one service method to call another service method that already opened a session.  These things ends up cluttering the module code with a lot of boilerplate and makes maintenance and testing in isolation a bit of a nightmare.

For the project that I'm working on, we ended up using annotations and AOP to allow declarative openmrs session demarcation (and authentication) similar to spring's transaction demarcation. This allowed us to just mark methods that required an openmrs session and allow the advisors to sort out when one was open and when a new one was necessary. This pulled out a lot of the manual open/close code out of the classes.

We also created a service that simply delegates to the static Context.getService calls. We injected that service via normal Spring dependency injection which enabled us to use mocks to feign those calls. We could then test in isolation and enabled us to do true unit-style tests.

So, you're definitely not alone.

Brent Atkinson
[hidden email]



On Fri, Aug 27, 2010 at 7:27 PM, Darius Jazayeri <[hidden email]> wrote:
Hiya,

Off the top of my head and without looking at the code, I think you're correct about how it works.

As far as I remember, the reasons we did it this way are historic: when we first started out we were not sure we wanted to tie our API irrevocably to Spring. (It ended up happening anyway.)

Also, I think that in the earlier versions of Spring you couldn't do autowiring by annotation. We wanted to be able to call the API from anywhere without having to make the classes be ApplicationContextAware, and having to do xml-based dependency injection of services into controllers, etc, seemed very un-fun.

As I understand it the correct way of doing things today would be something like this:

interface PatientService { ... }

interface PatientDAO { ... }

@Service
class PatientServiceImp implements PatientService {
    @Autowired PatientDAO dao;
    ...
}

@Repository
class HibernatePatientDAO implements PatientDAO { ... }

Then to use the service, we'd do:

class ApiConsumer {
    @Autowired PatientService patientService;
    ...
}

But in that case wouldn't we only be able to access the API through spring-loaded beans (because only those could have their dependencies autowired)? I guess we could get around that by keeping Context.getPatientService() and have that return an autowired bean...

-Darius


On Fri, Aug 27, 2010 at 6:44 PM, hash source <[hidden email]> wrote:
Hi all,

I am still at the stage of understanding the architecture before I can start efficiently contributing. I have a question about Context class and Spring. I understand that the ServiceContext for example has the actual implementations of the services injected via spring. However, I still don't understand why some functionalities that can be provided by spring is re-implemented in the Context class. I'm sure there is a reason behind this, I'm just trying to understand.

Currently, if Object o1 would like to access the PatientService, a call is made to Context.getPatientService() which in turns calls ServiceContext which finally looks up the class name in a map Object service = services.get(cls); (whose instinces are injected through spring).
First question, am I correct about how it works?

Second question. As i mentioned about is explained in question 1 is actually a re-implementation of Spring functionality (factories). In a standard spring app, we would just have a reference from the class c1
PatientService patientService;

and simply call patientService.foo() since the actual implementation is injected through spring.

Like i said, I'm sure there is a ratioinal behind how it is, and I'm not trying to correct anything at this point... just explain to me the logic behind how it's done please :)


Finally, I did not introduce myself in the previous email: I am a software developer with around 7-8 years of experience mainly in Java/Spring/Hibernate/etc... I live in Cleveland Heights, OH.
I have great interest in the culture of open source and the mentality behind it; also intewrested in the OpenMRS project in particular because of its humanitarian benefit and benefit potential.

Thanks!
hashsource

[hidden email] from OpenMRS Developers' mailing list


[hidden email] from OpenMRS Developers' mailing list



--
---
Brent Atkinson
[hidden email]

[hidden email] from OpenMRS Developers' mailing list
Ben Wolfe (openmrs) Ben Wolfe (openmrs)
Reply | Threaded
Open this post in threaded view
|

Re: Context class

Can you share that code Brent?  Is it hosted somewhere?

I think the only thing keeping us from switching to completely DI
services is the random use of Context.get*Service in places that don't
accept DI.  (like some pojos or util methods) This is bad design and
should be cleaned up, but at the time we didn't know of an alternative.

Ben

On 08/28/2010 09:32 AM, Brent Atkinson wrote:

> Hi Hashsource,
>
> I also was surprised by the fact that module developers couldn't use DI
> to inject resources like service instances and instead have to use the
> registry pattern to look them up. Additionally, the manual openmrs
> session management makes things complicated when you want one service
> method to call another service method that already opened a session.
> These things ends up cluttering the module code with a lot of
> boilerplate and makes maintenance and testing in isolation a bit of a
> nightmare.
>
> For the project that I'm working on, we ended up using annotations and
> AOP to allow declarative openmrs session demarcation (and
> authentication) similar to spring's transaction demarcation. This
> allowed us to just mark methods that required an openmrs session and
> allow the advisors to sort out when one was open and when a new one was
> necessary. This pulled out a lot of the manual open/close code out of
> the classes.
>
> We also created a service that simply delegates to the static
> Context.getService calls. We injected that service via normal Spring
> dependency injection which enabled us to use mocks to feign those calls.
> We could then test in isolation and enabled us to do true unit-style tests.
>
> So, you're definitely not alone.
>
> Brent Atkinson
> [hidden email] <mailto:[hidden email]>
>
>
>
> On Fri, Aug 27, 2010 at 7:27 PM, Darius Jazayeri
> <[hidden email] <mailto:djazayeri%[hidden email]>> wrote:
>
>     Hiya,
>
>     Off the top of my head and without looking at the code, I think
>     you're correct about how it works.
>
>     As far as I remember, the reasons we did it this way are
>     historic: when we first started out we were not sure we wanted to
>     tie our API irrevocably to Spring. (It ended up happening anyway.)
>
>     Also, I think that in the earlier versions of Spring you couldn't do
>     autowiring by annotation. We wanted to be able to call the API from
>     anywhere without having to make the classes be
>     ApplicationContextAware, and having to do xml-based dependency
>     injection of services into controllers, etc, seemed very un-fun.
>
>     As I understand it the correct way of doing things today would be
>     something like this:
>
>         interface PatientService { ... }
>
>         interface PatientDAO { ... }
>
>         @Service
>         class PatientServiceImp implements PatientService {
>             @Autowired PatientDAO dao;
>             ...
>         }
>
>         @Repository
>         class HibernatePatientDAO implements PatientDAO { ... }
>
>
>     Then to use the service, we'd do:
>
>         class ApiConsumer {
>             @Autowired PatientService patientService;
>             ...
>         }
>
>
>     But in that case wouldn't we only be able to access the API through
>     spring-loaded beans (because only those could have their
>     dependencies autowired)? I guess we could get around that by keeping
>     Context.getPatientService() and have that return an autowired bean...
>
>     -Darius
>
>
>     On Fri, Aug 27, 2010 at 6:44 PM, hash source <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         Hi all,
>
>         I am still at the stage of understanding the architecture before
>         I can start efficiently contributing. I have a question about
>         Context class and Spring. I understand that the ServiceContext
>         for example has the actual implementations of the services
>         injected via spring. However, I still don't understand why some
>         functionalities that can be provided by spring is re-implemented
>         in the Context class. I'm sure there is a reason behind this,
>         I'm just trying to understand.
>
>         Currently, if Object o1 would like to access the PatientService,
>         a call is made to Context.getPatientService() which in turns
>         calls ServiceContext which finally looks up the class name in a
>         map Object service = services.get(cls); (whose instinces are
>         injected through spring).
>         First question, am I correct about how it works?
>
>         Second question. As i mentioned about is explained in question 1
>         is actually a re-implementation of Spring functionality
>         (factories). In a standard spring app, we would just have a
>         reference from the class c1
>         PatientService patientService;
>
>         and simply call patientService.foo() since the actual
>         implementation is injected through spring.
>
>         Like i said, I'm sure there is a ratioinal behind how it is, and
>         I'm not trying to correct anything at this point... just explain
>         to me the logic behind how it's done please :)
>
>
>         Finally, I did not introduce myself in the previous email: I am
>         a software developer with around 7-8 years of experience mainly
>         in Java/Spring/Hibernate/etc... I live in Cleveland Heights, OH.
>         I have great interest in the culture of open source and the
>         mentality behind it; also intewrested in the OpenMRS project in
>         particular because of its humanitarian benefit and benefit
>         potential.
>
>         Thanks!
>         /hashsource/
>         ------------------------------------------------------------------------
>         Click here to unsubscribe
>         <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>         from OpenMRS Developers' mailing list
>
>
>     ------------------------------------------------------------------------
>     Click here to unsubscribe
>     <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>     from OpenMRS Developers' mailing list
>
>
>
>
> --
> ---
> Brent Atkinson
> [hidden email] <mailto:[hidden email]>
> ------------------------------------------------------------------------
> Click here to unsubscribe
> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
> OpenMRS Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
Brent Atkinson Brent Atkinson
Reply | Threaded
Open this post in threaded view
|

Re: Context class

Yes certainly,

My personal feeling is that it isn't quite distilled enough to call it ready-to-wear for OpenMRS, but the code is open source. I'll send you a link and some background on it later on tonight when I have a little more time.

Brent

On Sat, Aug 28, 2010 at 11:19 AM, Ben Wolfe <[hidden email]> wrote:
Can you share that code Brent?  Is it hosted somewhere?

I think the only thing keeping us from switching to completely DI
services is the random use of Context.get*Service in places that don't
accept DI.  (like some pojos or util methods) This is bad design and
should be cleaned up, but at the time we didn't know of an alternative.

Ben

On 08/28/2010 09:32 AM, Brent Atkinson wrote:
> Hi Hashsource,
>
> I also was surprised by the fact that module developers couldn't use DI
> to inject resources like service instances and instead have to use the
> registry pattern to look them up. Additionally, the manual openmrs
> session management makes things complicated when you want one service
> method to call another service method that already opened a session.
> These things ends up cluttering the module code with a lot of
> boilerplate and makes maintenance and testing in isolation a bit of a
> nightmare.
>
> For the project that I'm working on, we ended up using annotations and
> AOP to allow declarative openmrs session demarcation (and
> authentication) similar to spring's transaction demarcation. This
> allowed us to just mark methods that required an openmrs session and
> allow the advisors to sort out when one was open and when a new one was
> necessary. This pulled out a lot of the manual open/close code out of
> the classes.
>
> We also created a service that simply delegates to the static
> Context.getService calls. We injected that service via normal Spring
> dependency injection which enabled us to use mocks to feign those calls.
> We could then test in isolation and enabled us to do true unit-style tests.
>
> So, you're definitely not alone.
>
> Brent Atkinson
> [hidden email] <mailto:[hidden email]>
>
>
>
> On Fri, Aug 27, 2010 at 7:27 PM, Darius Jazayeri
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hiya,
>
>     Off the top of my head and without looking at the code, I think
>     you're correct about how it works.
>
>     As far as I remember, the reasons we did it this way are
>     historic: when we first started out we were not sure we wanted to
>     tie our API irrevocably to Spring. (It ended up happening anyway.)
>
>     Also, I think that in the earlier versions of Spring you couldn't do
>     autowiring by annotation. We wanted to be able to call the API from
>     anywhere without having to make the classes be
>     ApplicationContextAware, and having to do xml-based dependency
>     injection of services into controllers, etc, seemed very un-fun.
>
>     As I understand it the correct way of doing things today would be
>     something like this:
>
>         interface PatientService { ... }
>
>         interface PatientDAO { ... }
>
>         @Service
>         class PatientServiceImp implements PatientService {
>             @Autowired PatientDAO dao;
>             ...
>         }
>
>         @Repository
>         class HibernatePatientDAO implements PatientDAO { ... }
>
>
>     Then to use the service, we'd do:
>
>         class ApiConsumer {
>             @Autowired PatientService patientService;
>             ...
>         }
>
>
>     But in that case wouldn't we only be able to access the API through
>     spring-loaded beans (because only those could have their
>     dependencies autowired)? I guess we could get around that by keeping
>     Context.getPatientService() and have that return an autowired bean...
>
>     -Darius
>
>
>     On Fri, Aug 27, 2010 at 6:44 PM, hash source <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         Hi all,
>
>         I am still at the stage of understanding the architecture before
>         I can start efficiently contributing. I have a question about
>         Context class and Spring. I understand that the ServiceContext
>         for example has the actual implementations of the services
>         injected via spring. However, I still don't understand why some
>         functionalities that can be provided by spring is re-implemented
>         in the Context class. I'm sure there is a reason behind this,
>         I'm just trying to understand.
>
>         Currently, if Object o1 would like to access the PatientService,
>         a call is made to Context.getPatientService() which in turns
>         calls ServiceContext which finally looks up the class name in a
>         map Object service = services.get(cls); (whose instinces are
>         injected through spring).
>         First question, am I correct about how it works?
>
>         Second question. As i mentioned about is explained in question 1
>         is actually a re-implementation of Spring functionality
>         (factories). In a standard spring app, we would just have a
>         reference from the class c1
>         PatientService patientService;
>
>         and simply call patientService.foo() since the actual
>         implementation is injected through spring.
>
>         Like i said, I'm sure there is a ratioinal behind how it is, and
>         I'm not trying to correct anything at this point... just explain
>         to me the logic behind how it's done please :)
>
>
>         Finally, I did not introduce myself in the previous email: I am
>         a software developer with around 7-8 years of experience mainly
>         in Java/Spring/Hibernate/etc... I live in Cleveland Heights, OH.
>         I have great interest in the culture of open source and the
>         mentality behind it; also intewrested in the OpenMRS project in
>         particular because of its humanitarian benefit and benefit
>         potential.
>
>         Thanks!
>         /hashsource/
>         ------------------------------------------------------------------------
>         Click here to unsubscribe
>         <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>         from OpenMRS Developers' mailing list
>
>
>     ------------------------------------------------------------------------
>     Click here to unsubscribe
>     <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>     from OpenMRS Developers' mailing list
>
>
>
>
> --
> ---
> Brent Atkinson
> [hidden email] <mailto:[hidden email]>
> ------------------------------------------------------------------------
> Click here to unsubscribe
> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
> OpenMRS Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]



--
---
Brent Atkinson
[hidden email]

[hidden email] from OpenMRS Developers' mailing list
Brent Atkinson Brent Atkinson
Reply | Threaded
Open this post in threaded view
|

Re: Context class

Ben,

I apologize for the delay on this. I did want to get this information to you in case it's of interest. The background is basically that we fought back to getting some of the DI capabilities for our module. We couldn't get there fully because of limitations with some parts of the system, namely the job scheduler and the activator. It did allow us to more easily keep all the various resources accounted for and sorted out and got enabled us to write fast, isolated tests. I've included links to the various points of interest in our project. Feel free to poke around if it helps to understand things better. Also, if you have any questions about some of the more... esoteric details feel free to pose them to either Matt or myself.

Brent

--------

The context wrapper service we used to re-enable testing in isolation using DI:

https://motech.rcg.usm.maine.edu/redmine/repositories/entry/motech/tags/0.7.2/motech-server-omod/src/main/java/org/motechproject/server/omod/impl/ContextServiceImpl.java

An example annotation:

https://motech.rcg.usm.maine.edu/redmine/repositories/entry/motech/tags/0.7.2/motech-server-core/src/main/java/org/motechproject/server/annotation/RunWithContextSession.java

The corresponding AOP interceptor:

https://motech.rcg.usm.maine.edu/redmine/repositories/entry/motech/tags/0.7.2/motech-server-omod/src/main/java/org/motechproject/server/omod/advice/ContextSessionAdvice.java

The spring config configuring the interceptors for our service beans (registrarBeanProxy is the one you should be looking at):

https://motech.rcg.usm.maine.edu/redmine/repositories/entry/motech/tags/0.7.2/motech-server-omod/src/main/resources/registrar-bean.xml#L12


On Sat, Aug 28, 2010 at 1:36 PM, Brent Atkinson <[hidden email]> wrote:
Yes certainly,

My personal feeling is that it isn't quite distilled enough to call it ready-to-wear for OpenMRS, but the code is open source. I'll send you a link and some background on it later on tonight when I have a little more time.

Brent


On Sat, Aug 28, 2010 at 11:19 AM, Ben Wolfe <[hidden email]> wrote:
Can you share that code Brent?  Is it hosted somewhere?

I think the only thing keeping us from switching to completely DI
services is the random use of Context.get*Service in places that don't
accept DI.  (like some pojos or util methods) This is bad design and
should be cleaned up, but at the time we didn't know of an alternative.

Ben

On 08/28/2010 09:32 AM, Brent Atkinson wrote:
> Hi Hashsource,
>
> I also was surprised by the fact that module developers couldn't use DI
> to inject resources like service instances and instead have to use the
> registry pattern to look them up. Additionally, the manual openmrs
> session management makes things complicated when you want one service
> method to call another service method that already opened a session.
> These things ends up cluttering the module code with a lot of
> boilerplate and makes maintenance and testing in isolation a bit of a
> nightmare.
>
> For the project that I'm working on, we ended up using annotations and
> AOP to allow declarative openmrs session demarcation (and
> authentication) similar to spring's transaction demarcation. This
> allowed us to just mark methods that required an openmrs session and
> allow the advisors to sort out when one was open and when a new one was
> necessary. This pulled out a lot of the manual open/close code out of
> the classes.
>
> We also created a service that simply delegates to the static
> Context.getService calls. We injected that service via normal Spring
> dependency injection which enabled us to use mocks to feign those calls.
> We could then test in isolation and enabled us to do true unit-style tests.
>
> So, you're definitely not alone.
>
> Brent Atkinson
> [hidden email] <mailto:[hidden email]>
>
>
>
> On Fri, Aug 27, 2010 at 7:27 PM, Darius Jazayeri
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hiya,
>
>     Off the top of my head and without looking at the code, I think
>     you're correct about how it works.
>
>     As far as I remember, the reasons we did it this way are
>     historic: when we first started out we were not sure we wanted to
>     tie our API irrevocably to Spring. (It ended up happening anyway.)
>
>     Also, I think that in the earlier versions of Spring you couldn't do
>     autowiring by annotation. We wanted to be able to call the API from
>     anywhere without having to make the classes be
>     ApplicationContextAware, and having to do xml-based dependency
>     injection of services into controllers, etc, seemed very un-fun.
>
>     As I understand it the correct way of doing things today would be
>     something like this:
>
>         interface PatientService { ... }
>
>         interface PatientDAO { ... }
>
>         @Service
>         class PatientServiceImp implements PatientService {
>             @Autowired PatientDAO dao;
>             ...
>         }
>
>         @Repository
>         class HibernatePatientDAO implements PatientDAO { ... }
>
>
>     Then to use the service, we'd do:
>
>         class ApiConsumer {
>             @Autowired PatientService patientService;
>             ...
>         }
>
>
>     But in that case wouldn't we only be able to access the API through
>     spring-loaded beans (because only those could have their
>     dependencies autowired)? I guess we could get around that by keeping
>     Context.getPatientService() and have that return an autowired bean...
>
>     -Darius
>
>
>     On Fri, Aug 27, 2010 at 6:44 PM, hash source <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>         Hi all,
>
>         I am still at the stage of understanding the architecture before
>         I can start efficiently contributing. I have a question about
>         Context class and Spring. I understand that the ServiceContext
>         for example has the actual implementations of the services
>         injected via spring. However, I still don't understand why some
>         functionalities that can be provided by spring is re-implemented
>         in the Context class. I'm sure there is a reason behind this,
>         I'm just trying to understand.
>
>         Currently, if Object o1 would like to access the PatientService,
>         a call is made to Context.getPatientService() which in turns
>         calls ServiceContext which finally looks up the class name in a
>         map Object service = services.get(cls); (whose instinces are
>         injected through spring).
>         First question, am I correct about how it works?
>
>         Second question. As i mentioned about is explained in question 1
>         is actually a re-implementation of Spring functionality
>         (factories). In a standard spring app, we would just have a
>         reference from the class c1
>         PatientService patientService;
>
>         and simply call patientService.foo() since the actual
>         implementation is injected through spring.
>
>         Like i said, I'm sure there is a ratioinal behind how it is, and
>         I'm not trying to correct anything at this point... just explain
>         to me the logic behind how it's done please :)
>
>
>         Finally, I did not introduce myself in the previous email: I am
>         a software developer with around 7-8 years of experience mainly
>         in Java/Spring/Hibernate/etc... I live in Cleveland Heights, OH.
>         I have great interest in the culture of open source and the
>         mentality behind it; also intewrested in the OpenMRS project in
>         particular because of its humanitarian benefit and benefit
>         potential.
>
>         Thanks!
>         /hashsource/
>         ------------------------------------------------------------------------
>         Click here to unsubscribe
>         <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>         from OpenMRS Developers' mailing list
>
>
>     ------------------------------------------------------------------------
>     Click here to unsubscribe
>     <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l>
>     from OpenMRS Developers' mailing list
>
>
>
>
> --
> ---
> Brent Atkinson
> [hidden email] <mailto:[hidden email]>
> ------------------------------------------------------------------------
> Click here to unsubscribe
> <mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from
> OpenMRS Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]



--
---

Brent Atkinson
[hidden email]



--
---
Brent Atkinson
[hidden email]

[hidden email] from OpenMRS Developers' mailing list