How to specify/make a bean as immutable in beanfactory

[mperham]

Spring 1.1 has support for factory methods so you can prevent "new" access.

[jasonchen_nj]

The final 1.1 is out.

However, I couldn't find any announcement or documentation regarding this issue.

Is it not so important for most of the people those are using SpringFramework out there? :?

Jason

[Colin Sampaleanu]

Factory methods have been fully documented in the beans chapter since about 1.1RC1....

[jasonchen_nj]

Let me quote myself here and open the topic again.

The flexibility provided by Spring Framework is good. However, as I start introducing it into our project, my tech lead did ask me the following questions,

If it's a "spring singleton" defined in Spring Context, how do you prevent the other developers from doing a "new" manually? :?:

If it's not a "spring singleton”, again, how can you prevent people from just trying the "new" but not “getBean” from the framework? :?:

I think a constructor injection is a necessary. We are also considering making a "non-spring" singleton to access the Spring context in order to prevent this from happening.

Any other suggestion is all welcome.

I checked the documentation. The "factory method" is mainly for the purpose to define some old type of factory class to be hanlded by the Spring Context. I don't think it can solve the issue. When you provide a "getInstance" instead of "new", the same issue is still there. (in my quote)

Am I right?

The point is how do you prevent them from using a "new" or "getInstance" without using "getBean" to create the bean? Any one else here has the similar concern?

Jason

[jbetancourt]

Sounds like a valid concern. If you own and control the developers and users of your beans (that sounds funny) there is no issue, I guess; they have to follow the process and framework.

But, in the real world and in crunch mode, people take shortcuts and stuff.

I don't see any easy solution unless the classes themselves are written to probe their environment.

class FooInContext  extends ContextAware......
    public FooInContext(){
            if(  ctx == null) { throw new CreateOutsideContainerException("..."); }

That seems a code smell, now everything is dependent on its environment. Could AOP help here? Use a constructor aspect on a classes' constructors, and this does the context origination check somehow.

Let me quote myself here and open the topic again.

The flexibility provided by Spring Framework is good. However, as I start introducing it into our project, my tech lead did ask me the following questions,

If it's a "spring singleton" defined in Spring Context, how do you prevent the other developers from doing a "new" manually? :?:

If it's not a "spring singleton”, again, how can you prevent people from just trying the "new" but not “getBean” from the framework? :?:

I think a constructor injection is a necessary. We are also considering making a "non-spring" singleton to access the Spring context in order to prevent this from happening.

Any other suggestion is all welcome.

I checked the documentation. The "factory method" is mainly for the purpose to define some old type of factory class to be hanlded by the Spring Context. I don't think it can solve the issue. When you provide a "getInstance" instead of "new", the same issue is still there. (in my quote)

Am I right?

The point is how do you prevent them from using a "new" or "getInstance" without using "getBean" to create the bean? Any one else here has the similar concern?

Jason

[feester]

The point is how do you prevent them from using a "new" or "getInstance" without using "getBean" to create the bean?

First, you can't prevent them from using new or a factory getInstance directly. Don't worry about it, because you can easily refactor a bean to instead receive what objects it needs.

Second, why do you think the way you get a reference to an object is via applicationContext.getBean()????

I have a small web application with maybe 70 or so beans and the only time I have used getBean is a few times in my integration testing code. (In production, none of the beans I created have any knowledge of Spring's core APIs) I get impression that you are not using inversion of control--and Spring's capabilities--to it's fullest yet. It appears that your beans are passed an ApplicationContext--why?

The construction of your beans and 'injection' of their dependencies is defined in the context xml files! A bean doesn't have to have any knowledge that it is in a Spring environment. (If you pass the ApplicationContext to it then it would have knowledge of Spring interfaces) All a bean has to know is the interfaces of the objects it needs. Also a bean only has to provide a means for an outside agent--the Spring enviroment--to pass it the object instances it needs. This is done via a constructor or setter methods.

Have you been passing your object dependencies in your xml files? For example:

<property name="velocityEngine">
   <refbean="velocityEngine"/>
</property>

In this case there is a property on some bean that has a method called setVelocityEngine( VelocityEngine ) And there is a bean defined somewhere else in context files that has the name or id of "velocityEngine" that is of type VelocityEngine.

The bean in question doesn't know how the object it needs is constructed all it knows is it has a reference to an object of a certain type and knows how to call that objects interface.

Your developers might follow a rule something like following:
"Make sure your primary objects/services provide a means to receive all their dependencies"

The actual construction/instantiation of these beans is handled by a third party--the IOC framework. The Spring framework wires all your system's objects together for you.

While there might be situations where passing ApplicationContext make sense, I think passing an ApplicationContext should be done rarely.

Regards, Jim