Hi there, I just commited the changes.. See:
https://issues.apache.org/jira/browse/MAILBOX-22 Let me know if it work out for you. We want to release a new version of mailbox project soon.... Bye, Norman 2010/12/24 Norman Maurer <[email protected]>: > I will have a look at it the next days, so stay tuned... > > Bye > Norman > > > Am Freitag, 24. Dezember 2010 schrieb Wojciech Strzałka <[email protected]>: >> >> Sounds perfect >> >>> Hi there, >> >>> ok I see your point now. In fact I thought about make the >>> "DelegatingMailboxListener" pluggable so it would be possible to >>> better support clustering etc. So you would create one instance of the >>> DelegatingMailboxListener (or subclass) and inject it into the >>> MailboxManager. Then you could create a new instance of >>> MailboxEventDispatcher and register ther previous created >>> DelegatingMailboxListener to it. This would then make it easy to fire >>> events from outside..... >> >>> WDYT ? >> >>> Bye, >>> Norman >> >>> 2010/12/24 Wojciech Strzałka <[email protected]>: >>>> >>>> Hi >>>> >>>> Thanks for quick response. >>>> >>>> So - as I wrote before - James IMAP is only one of the possibilities >>>> for email to entry my store (it's separate application in fact and >>>> I've implemented custom store to support it). >>>> When email enters the system in some other way then through IMAP, I'd >>>> like to notice IMAP clients that there is new email. >>>> At the moment 2 crucial command processors rely on this heavily - one >>>> is NoopProcesor - which checks via MailboxEventAnalyser if the mailbox >>>> size has >>>> changed. Without pushing event to dispatcher it returns with no change >>>> notification. >>>> >>>> The second command - commited recently to trunk is IDLE - it adds own >>>> listener to be able to notify IDLing clients immediately about changes, >>>> those relies on the dispatcher data also. >>>> >>>> MailboxManager/MessageManager have possibilities to operate on items >>>> and register the changes made but in my use case, changes are >>>> performed externally and the only thing I want to do, is push an event >>>> to dispatcher. >>>> >>>> I'm not 100% sure direct access to dispatcher is right way to do is, >>>> I'm open to any suggestions. >>>> Simplest solutions seems to be looking for dispatcher in the >>>> ImapProcessorFactory - I could easily override it and do any magic I >>>> need :) >>>> >>>> >>>> Best regards >>>> Wojtek Strzalka >>>> >>>>> Hi there, >>>> >>>>> at the moment its not possible to get the MailboxEventDispatcher >>>>> instance. But if you can make me understand why you want to manipulate >>>>> without using the MailboxManager/MessageManager we can see if it would >>>>> make sense to make it accessable. >>>> >>>>> Thx, >>>>> Norman >>>> >>>> >>>>> 2010/12/22 Wojciech Strzałka <[email protected]>: >>>>>> >>>>>> Hi >>>>>> >>>>>> >>>>>> >>>>>> I'm trying to implement my own IMAP solution based on James v3 >>>>>> The messages can be pushed to the store bypasing the James - in >>>>>> such a case I'd like to inform IMAP clients that something hava >>>>>> changed. >>>>>> >>>>>> I was looking at the code a little bit and it looks like I should >>>>>> push an event to MailboxEventDispatcher (so the NOOP will notify >>>>>> mailbox size has changed and inform client about the fact) but I >>>>>> can not find a way to get the MailboxEventDispatcher instance from >>>>>> externall code. >>>>>> I think about smth like registering an JMS listener to listen for >>>>>> external mailbox changes and push the events to dispatcher but I have >>>>>> no idea where my start point >>>>>> should be. >>>>>> >>>>>> Any suggestions how (if it's possible at all) can I achieve what I >>>>>> described? >>>>>> >>>>>> Wojtek >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >> -- >> Pozdrowienia, >> Wojciech Strzałka >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
