Cant retrieve Bean by it's id via BeanFactory

[ray.frid]

Gotcha.

(heh love your sarcasm comments)

your second point is nice. I can use the container to create for me beans. and If I remember right prototype beans can be dispose by me(I mean they must be disposed by me the container wont dispose them)

BUT how will I retrieve specific instances of running-prototype beans form the container in order to dispose them? I know I shouldnt use getBean.. it's a memory killer.

[Marten Deinum]

You should hold on to that bean somewhere in memory (it BeanFactory doesn't know it!) and after you unsubscribe from the channel it isn't referenced anymore and as such will eventually be GC'ed. How and where depends on your creation/destroy logic (is it a button press, tied to the session etc.).

[ray.frid]

Ok I have process your posts over and over here and I just need your blessing.

I have rid of the Singletons and now I am creating dynamiclly/programaticlly prototype beans using application context this way:

                              FixSessionDTO fixSessionDTO = new FixSessionDTO();
				fixSessionDTO.setInetrnalSessionId(internalSessionId);
                               SessionMDB sessionMDB = (SessionMDB) context.getBean("sessionMDB");

				sessionMDB.setFixSessionDTO(fixSessionDTO);
				sessionMDB.setTopicDestination(topicDestination);
				sessionMDB.init();

now SessionMdb looks like this:

@Scope(value="prototype")
@Component("sessionMDB")
public class SessionMDB extends AbstractSessionBean
{

private SubscribableChannel channel;

public SessionMDB(FixSessionDTO fixSessionDTO, Topic topicDestination)
{
super(fixSessionDTO, topicDestination);
}



public SessionMDB()
{
super();
// TODO Auto-generated constructor stub
}



private final static Logger log = Logger.getLogger(SessionMDB.class);

@Override
public void onMessage(Message message)
{

}
}

@ManagedResource
public abstract class AbstractSessionBean implements MessageListener//, AbstractSessionBeanManagedOperations// 																											
{

	protected FixSessionDTO fixSessionDTO;
	
	protected static Logger log = Logger.getLogger(AbstractSessionBean.class);;

	@Autowired
	ConnectionFactory connectionFactory;

	DefaultMessageListenerContainer messageListeners;

	private Topic topicDestination;

	public Topic getTopicDestination()
	{
		return topicDestination;
	}
	
	
	

	public AbstractSessionBean()
	{
		super();
		// TODO Auto-generated constructor stub
	}




	public void setTopicDestination(Topic topicDestination)
	{
		this.topicDestination = topicDestination;
	}

	
	public AbstractSessionBean(FixSessionDTO fixSessionDTO, Topic topicDestination)
	{
		super();
		this.fixSessionDTO = fixSessionDTO;
		this.topicDestination = topicDestination;
	}

	
	public FixSessionDTO getFixSessionDTO()
	{
		return fixSessionDTO;
	}

	public void setFixSessionDTO(FixSessionDTO fixSessionDTO)
	{
		this.fixSessionDTO = fixSessionDTO;
	}

	//@PostConstruct
	public void init()
	{

		try
		{
			System.out.println("AbstractSessionBean.init()." + fixSessionDTO.toString());
			messageListeners = new DefaultMessageListenerContainer();
			CachingConnectionFactory cacheFactory = new CachingConnectionFactory();
			cacheFactory.setTargetConnectionFactory(connectionFactory);
			cacheFactory.setReconnectOnException(true);
			cacheFactory.setExceptionListener(new ExceptionListener()
			{

				public void onException(JMSException e)
				{
					log.error("Error", e);
				}
			});
			cacheFactory.setSessionCacheSize(1);

			messageListeners.setConnectionFactory(connectionFactory);
			messageListeners.setDestinationName(topicDestination.getTopicName());
			messageListeners.setMaxConcurrentConsumers(1);
			messageListeners.setSessionAcknowledgeModeName("AUTO_ACKNOWLEDGE");
			messageListeners.setMessageListener(this);
			messageListeners.setPubSubDomain(true);
			messageListeners.setAcceptMessagesWhileStopping(false);
			messageListeners.setConcurrentConsumers(1);
			messageListeners.setSessionTransacted(false);
			messageListeners.setReceiveTimeout(1000);
			messageListeners.setMaxMessagesPerTask(300);
			messageListeners.initialize();
			messageListeners.start();

		}
		catch (Exception e)
		{
			e.printStackTrace();
		}
	}

	@PreDestroy
	public void destroy()
	{
		try
		{
			log.debug("Destroying MDB. details=" + fixSessionDTO.toString());
			if (messageListeners != null)
			{
				messageListeners.stop();
				messageListeners.shutdown();
				messageListeners.destroy();
			}
		}
		catch (Exception e)
		{
			log.error("Couldnt destroy MDB. details=" + fixSessionDTO.toString(), e);
		}

	}

	@ManagedOperation
	public void stop()
	{
		messageListeners.stop();
	}

	@ManagedOperation
	public void start()
	{
		messageListeners.start();
	}

two questions:
1. I thought if I need to use Spring integration in order to have it's Messages mechanisem why couldnt I use the same topic I am already subscribed to retrieve "adminisitartion" messages to do administration things like 'stop','start','die'..

2. incase you like idea 1. how will I destroy the prototype bean. just called this.destroy() and close all connections and hope the GC will do the rest for me?

[Marten Deinum]

I still don't see why you need them on demand but that probably is just me.

The problem I see with this implementation is that each MessageListenerContainer uses its own thread pool, own threads etc. With the Spring Integration approach you would only have a single listener which dispatches to several consumers. You now create a new one, attach it to the topic and receive messages.

To cleanup call the destroy method and make sure that the other beans used (fixSessionDTO) aren't referenced some where else.

[ray.frid]

You dont see why I need them on demand since this is only part of the architecture.

The big picture is that each subscriber has it's own "life" exactly like new web session.

As soon as users connect to my application(not via web. but via diff protocol) I get from them specific inputs and I have to subscribe them to a topic when the users leave I need to unsubscribe thier "session" which means the listener.

Thats why I need it "on demand" each subscriber has it's own parameters.

Now each subscriber is also associated to a group(which get different messages). So I have also different topics. that's

why I made MessageListenerContainer programticly because each subscriber will have specific topic destination which will get on runtime.

are you getting me or a sarcastic comment is on the way?:P

[ray.frid]

So what do you think?