Announcement Announcement Module
No announcement yet.
Creating a bean from the code of an existing bean. Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Creating a bean from the code of an existing bean.

    I have a prototype bean.
    This bean is instantiated by Spring.

    Inside this bean I do something like this:
    public String myMethod() {
    List<Item> items;
    items = ...;
    for (Item item : items) {
         WannabeBean wannabeBean = new WannabeBean(item);
    I want to make "WannabeBean" a bean correcly handled by Spring, since inside "doSomething()" I want to use the entityManager and the transactional annotation of Spring.

    Have you any idea?
    Thank you.

  • #2
    If the WannabeBean cannot be changed, I would create another Spring managed bean the wraps the execution of WannabeBean.doSomething (Iike a command). Then the command can be marked with the Transactional Annotation. Also, instantiation via a factory might work. Check out the Spring reference manual in chapter 3 on bean instantiation.


    • #3
      Is WannabeBean a service bean of some sort? Can you just define it in the app context and change WannabeBean.doSomething() to WannabeBean.doSomething(Item)?


      • #4
        WannabeBean is something like this:

        public class WannabeBean {
        private Item item;
        public WannabeBean(Item item) {
        this.item = item;
        public void doSomething() {
        private void doSomething1() {
        // works on item...
        private void doSomething2() {
        // works on item...
        private void doSomething3() {
        // works on item...
        If I make WannabeBean a singleton, i would need to pass Item to each of its private method.. and i don't like it very much.
        On the other hand if I keep Item as a singleton I can store Item as an object property, and I don't need to pass it to each private method.

        Finally a thing i still don't understand very well about Spring..
        is it required that I create a "interface WannabeBean" and then create "class WannabeBeanImpl" ?



        • #5
          If you go the route of making the WannabeBean as a Spring managed bean, it is a good practice, but not required, to have an interface and a concrete implementation. It gives you the ability to swap out implementations of the WannabeBean which to me is most useful in unit testing.

          Again, if you don't want the WannabeBean to be Spring managed, you could create some Spring managed bean (e.g. a WannabeBeanManager) that collaborates with your WannabeBean to acheive what you want (like defining a transactional method using @Transactional and referencing an injected entityManager).


          • #6
            To me it sounds like WannabeBean should be a service bean. I agree with the suggestion to use the interface and concrete implementation as well since that supports testing.

            As to having to pass the Item around--the main thing to focus on is the single public method where you're passing the Item in. Your WannabeBean clients really only have to pass the item in one time, and in that respect it's the same as your original approach. (Only here you're passing the Item into a method instead of the constructor.) As far as repeatedly passing the Item to a bunch of private methods, I don't myself see any problem with that from an API design perspective (they're private methods so they're not part of the API), and not even from an implementation perspective. Seems legit to me. You're just breaking down the work.

            The alternative you mentioned--storing a local copy of Item--is probably the wrong way to go. If this is a service bean then presumably multiple clients will interact with it concurrently and you'll have threadsafety issues to contend with. You could synchronize access to that Item but that's both more complicated and less performant (your service essentially becomes singlethreaded.) I'd just pass the Item to the private methods.