Salut,
apology for the delay.
gustav trede wrote:
> Hello,
>
> My personal needs made me implement a custom cometcontext.
> Im using this in my localy patched GF v2.1b58.
> It might be of interest for others too.
>
> By not using static strings to define what class to use (as done in
> other parts of comet..) , we are not limiting ourselfes to one specified
> implementation per static context in a threadafe way.
>
>
> the first method is the existing one, calling the new flexible version:
>
> /**
> * Register a context path with this {_at_link CometEngine}. The
> * {_at_link CometContext} returned will be of type
> * <code>type</code>.
> * @param topic the context path used to create the
> * {_at_link CometContext}
> * @return CometContext a configured {_at_link CometContext}.
> */
> public synchronized CometContext register(String topic, int type){
> return register(topic, type,CometContext.class);
> }
>
> public synchronized CometContext register(String topic, int type,
> Class<? extends CometContext> contextclass ) {
> CometContext cometContext = activeContexts.get(topic);
> if (cometContext == null){
> cometContext = cometContexts.poll();
> if (cometContext == null){
> try{
> cometContext =
> contextclass.getConstructor(String.class, int.class).newInstance(topic,
> type);
> } catch (Throwable t) {
> logger.log(Level.SEVERE,"Invalid CometContext class
> : ",t);
> cometContext = new CometContext(topic, type);
> }
> cometContext.setCometSelector(cometSelector);
> NotificationHandler notificationHandler
> = loadNotificationHandlerInstance
> (notificationHandlerClassName);
> cometContext.setNotificationHandler(notificationHandler);
> if (notificationHandler != null && (notificationHandler
> instanceof DefaultNotificationHandler)){
> ((DefaultNotificationHandler)notificationHandler)
> .setPipeline(pipeline);
> }
> }
> activeContexts.put(topic,cometContext);
> }
> return cometContext;
> }
>
> cometcontext needs changes too, to allow for inherited classes to do
> their things.
> thats in seperate email to not confuse.
> several performance improvements dueto strange iterations used in
> current code, where hasmap lookups are used for every iteration where
> its not needed, can use entryset instead.. also in following emails.
OK so far I'm +1 for that API changes. Can you attach to:
https://grizzly.dev.java.net/issues/show_bug.cgi?id=294
The complete svn diff so I can apply the patch?
Many thanks!
-- Jeanfrancois
>
> regards
> gustav trede