On Mon, Aug 18, 2008 at 7:48 AM, Michael Sparer <[EMAIL PROTECTED]>wrote:

>
> I looked a bit more into the code and came to the conclusion that having to
> depend on the order the servlets and services are loaded is kind of a Bad
> Thing (tm). A user shouldn't have to care about such things. I had a look
> at
> the CometdService and I think one could circumvent the problem if we use
> the
> CometdService as a facade to the BayeuxService (rather than a subclass).
> This way we could initialise the BayeuxService lazily (which will be on
> first subscription to a channel) and wouln't have to depend on servlet
> orders or the time the ServletContext gets initialised. And as the only two
> methods used from the Bayeuxservice are getClient() and getBayeux() it
> wouldn't be too difficult. What do you, wicketstuff-push-commiters, or
> Rodolfo, think about that? Wouldn't be work at all for you as I have commit
> access - but I rather ask you first as you did the upgrade to 1.3.4 ;-)


Yes, that is the better option.

I'm still in a bit in a hurry to get the RemoveListener functionality for
another project I was working on.




>
>
> regards,
> Michael
>
> Michael Sparer wrote:
> >
> >> 2. The CometD servlet now has to be loaded before the CometDService can
> >> be
> >> instanciated.
> >> So you would have to initialize it on demand in your application.
> >
> > I ran into that this morning. Can't this be avoided? I didn't look into
> > the code thoroughly yet, but I saw that CometdService is now extending
> > jetty's Bayeux Service which needs the Bayeux in the constructor. Having
> > the ServletContext initialised at the time my Beans are instantiated is
> > kinda tricky for me, as I can't initialise the services lazily as there
> is
> > a whole lot of cross-dependencies.
> > I could do it the hard way and remove the service from my springcontext,
> > let it be instantiated by the application and add the application as
> > reference-bean to the services that formerly needed the ChannelService -
> > but this sounds like a workaround, doesn't it?
> > When jetty implemented their new BayeuxService they must have thought
> > about such a problem, haven't they?
> > How did you go about this?
> >
> > regards,
> > Michael
> >
> > On Fri, Aug 15, 2008 at 1:29 PM, Michael Sparer
> > <[EMAIL PROTECTED]>wrote:
> >
> >>
> >> As the recent change from wicketstuff-push 1.3.0-SNAPSHOT to 1.3.4
> >> involved
> >> major changes (see
> >> http://www.nabble.com/wicketstuff-push-update-to18765345.html) as far
> as
> >> dependencies are concerned (new version of jetty-cometd with major API
> >> changes), I'd suggest a 1.3.0 branch.
> >> I do have commit rights but don't have permission to do the branch. So
> >> please either branch wicketstuff-push from version 3267 or give me
> >> permission to do so (my username is msparer).
> >>
> >> thanks in advance
> >>
> >> regards,
> >> Michael
> >>
> >> -----
> >> Michael Sparer
> >> http://talk-on-tech.blogspot.com
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/Permission-for-branching-wicketstuff-push-tp19002588p19002588.html
> >> Sent from the Wicket - Dev mailing list archive at Nabble.com.
> >>
> >>
> >
> >
>
>
>
>
> -----
> Michael Sparer
> http://talk-on-tech.blogspot.com
> --
> View this message in context:
> http://www.nabble.com/Permission-for-branching-wicketstuff-push-tp19002588p19029986.html
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>

Reply via email to