Send gatein-dev mailing list submissions to gatein-dev(a)lists.jboss.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.jboss.org/mailman/listinfo/gatein-dev or, via email, send a message with subject or body 'help' to gatein-dev-request(a)lists.jboss.org You can reach the person managing the list at gatein-dev-owner(a)lists.jboss.org When replying, please edit your Subject line so it is more specific than "Re: Contents of gatein-dev digest..." Today's Topics: 1. Re: PortletApplicationDeployer listeners (Ken Finnigan) 2. Re: PortletApplicationDeployer listeners (Julien Viet) 3. enable/disable users (Luca Stancapiano) 4. Re: enable/disable users (Boles?aw Dawidowicz) ---------------------------------------------------------------------- Message: 1 Date: Thu, 11 Apr 2013 12:03:29 -0400 (EDT) From: Ken Finnigan <kfinniga(a)redhat.com&gt; Subject: Re: [gatein-dev] PortletApplicationDeployer listeners To: Julien Viet <julien(a)julienviet.com&gt; Cc: gatein-dev(a)lists.jboss.org Message-ID: <734306130.3082080.1365696209274.JavaMail.root(a)redhat.com&gt; Content-Type: text/plain; charset="utf-8" That's fine, initially it didn't seem like the same listener instances would be applied to all deployments, not a problem. In terms of retrieving the portlet filter instance to actually perform injection on, is there a cleaner way to get it than this: filterClasses.add(ActionFilter.class); filterClasses.add(EventFilter.class); filterClasses.add(RenderFilter.class); filterClasses.add(ResourceFilter.class); ManagedPortletFilter managedPortletFilter = (ManagedPortletFilter) managedObject; PortletFilterImpl portletFilterImpl = (PortletFilterImpl) managedPortletFilter.getPortletFilter(); PortletFilter portletFilterInstance; for (Class type : filterClasses) { portletFilterInstance = (PortletFilter) portletFilterImpl.instance(type); // If not null, then use it and skip rest of loop } Thanks Ken ----- Original Message ----- > From: "Julien Viet" <julien(a)julienviet.com&gt; > To: "Ken Finnigan" <kfinniga(a)redhat.com&gt; > Cc: gatein-dev(a)lists.jboss.org > Sent: Tuesday, April 9, 2013 8:12:20 PM > Subject: Re: [gatein-dev] PortletApplicationDeployer listeners > Yes it is expected. > The listener may want to be aware of all deployments (for maintaining a > registry of all portlets with a single listener instead of adding/removing N > listeners where N is the number of deployments). > This is similar to the JMX JMImplementation MBean that send notifications > about MBean life cycle for any MBean added/removed from the MBeanServer as > the intent is originally the same. > What is wrong with having a single listener if you can associate the CDI meta > data with the deployed portlets ? > I would proceed in two steps : > 1/ upon deployment : prepare the CDI info for all portlets and add to a map a > list of portlet id -> cdi meta data for the portlet (injection etc?) > 2/ upon portlet created event : lookup for cdi work to do from portlet id and > if it exists then honour the cdi integration > On Apr 9, 2013, at 10:14 PM, Ken Finnigan < kfinniga(a)redhat.com > wrote: > > All, > > > In implementing CDI injection into GenericPortlet and PortletFilter > > instances, I had assumed that I could add a > > ManagedObjectRegistryEventListener, specifically for CDI processing, and > > add > > it to the broadcaster in PortletApplicationDeployer for only those > > PortletApplicationDeployment's that needed CDI injection. ie. the listener > > would be added before creating a PortletApplicationDeployment and then > > removed straight afterwards to ensure that portlet deployments that had > > nothing to do with CDI, were not calling the listener for all event > > notifications for no reason. > > > An unexpected consequence of this is that I've discovered the broadcaster > > list of listeners is the exact same instance across all > > PortletApplicationDeployment instances. So when I removed the CDI listener > > from broadcaster on PortletApplicationDeployer, it also removed that > > listener from the PortletApplicationDeployment that had just been created. > > > Is that expected? I'd find it unusual that its not possible to add a > > listener > > specific to a deployment that should not be applied to all of them. > > > Wondering if ManagedObjectRegistryEventBroadcaster needs to support cloning > > to facilitate this functionality? > > > Any other thoughts on a better way to do this are appreciated, as I > > certainly > > feel it unnecessary to defensively code my listener for all types of > > portlets it can be attached to when it doesn't need to. > > > Ken > > > ======================== > > > Senior Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. > > > _______________________________________________ > > > gatein-dev mailing list > > > gatein-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/gatein-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/gatein-dev/attachments/20130411/47f5d991... ------------------------------ Message: 2 Date: Thu, 11 Apr 2013 21:25:35 +0200 From: Julien Viet <julien(a)julienviet.com&gt; Subject: Re: [gatein-dev] PortletApplicationDeployer listeners To: Ken Finnigan <kfinniga(a)redhat.com&gt; Cc: gatein-dev(a)lists.jboss.org Message-ID: <5D2D0218-7B8E-4DBE-92B1-8E410391EC28(a)julienviet.com&gt; Content-Type: text/plain; charset="windows-1252" no there is not (because there was no need to expose such internal things until we work out this integration). you should add a Filter getFilter() on the class that returns the instance. On Apr 11, 2013, at 6:03 PM, Ken Finnigan <kfinniga(a)redhat.com&gt; wrote: > That's fine, initially it didn't seem like the same listener instances would be applied to all deployments, not a problem. > > In terms of retrieving the portlet filter instance to actually perform injection on, is there a cleaner way to get it than this: > > filterClasses.add(ActionFilter.class); > filterClasses.add(EventFilter.class); > filterClasses.add(RenderFilter.class); > filterClasses.add(ResourceFilter.class); > > ManagedPortletFilter managedPortletFilter = (ManagedPortletFilter) managedObject; > > PortletFilterImpl portletFilterImpl = (PortletFilterImpl) managedPortletFilter.getPortletFilter(); > > PortletFilter portletFilterInstance; > > for (Class type : filterClasses) { > portletFilterInstance = (PortletFilter) portletFilterImpl.instance(type); > > // If not null, then use it and skip rest of loop > > } > > > Thanks > Ken > > From: "Julien Viet" <julien(a)julienviet.com&gt; > To: "Ken Finnigan" <kfinniga(a)redhat.com&gt; > Cc: gatein-dev(a)lists.jboss.org > Sent: Tuesday, April 9, 2013 8:12:20 PM > Subject: Re: [gatein-dev] PortletApplicationDeployer listeners > > Yes it is expected. > > The listener may want to be aware of all deployments (for maintaining a registry of all portlets with a single listener instead of adding/removing N listeners where N is the number of deployments). > > This is similar to the JMX JMImplementation MBean that send notifications about MBean life cycle for any MBean added/removed from the MBeanServer as the intent is originally the same. > > What is wrong with having a single listener if you can associate the CDI meta data with the deployed portlets ? > > I would proceed in two steps : > > 1/ upon deployment : prepare the CDI info for all portlets and add to a map a list of portlet id -> cdi meta data for the portlet (injection etc?) > 2/ upon portlet created event : lookup for cdi work to do from portlet id and if it exists then honour the cdi integration > > > > On Apr 9, 2013, at 10:14 PM, Ken Finnigan <kfinniga(a)redhat.com&gt; wrote: > > All, > > In implementing CDI injection into GenericPortlet and PortletFilter instances, I had assumed that I could add a ManagedObjectRegistryEventListener, specifically for CDI processing, and add it to the broadcaster in PortletApplicationDeployer for only those PortletApplicationDeployment's that needed CDI injection. ie. the listener would be added before creating a PortletApplicationDeployment and then removed straight afterwards to ensure that portlet deployments that had nothing to do with CDI, were not calling the listener for all event notifications for no reason. > > An unexpected consequence of this is that I've discovered the broadcaster list of listeners is the exact same instance across all PortletApplicationDeployment instances. So when I removed the CDI listener from broadcaster on PortletApplicationDeployer, it also removed that listener from the PortletApplicationDeployment that had just been created. > > Is that expected? I'd find it unusual that its not possible to add a listener specific to a deployment that should not be applied to all of them. > > Wondering if ManagedObjectRegistryEventBroadcaster needs to support cloning to facilitate this functionality? > > Any other thoughts on a better way to do this are appreciated, as I certainly feel it unnecessary to defensively code my listener for all types of portlets it can be attached to when it doesn't need to. > > Ken > ======================== > Senior Software Engineer / JBoss Enterprise Middleware Red Hat, Inc. > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/gatein-dev/attachments/20130411/c126ae7b... ------------------------------ Message: 3 Date: Fri, 12 Apr 2013 12:21:41 +0200 From: Luca Stancapiano <l.stancapiano(a)sourcesense.com&gt; Subject: [gatein-dev] enable/disable users To: gatein-dev(a)lists.jboss.org Message-ID: <CAO3WqDVOGgig5AdjEf=cNA5dOFmiY5HTppGX+4Sf=+ ASF+Rc7w(a)mail.gmail.com&gt; Content-Type: text/plain; charset="iso-8859-1" Hi, I've seen there is not still the workflow for the enabling or disabling of the users. It was in the old jboss portal. Are there developements in progress? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/gatein-dev/attachments/20130412/a30e28a6... ------------------------------ Message: 4 Date: Fri, 12 Apr 2013 12:28:40 +0200 From: Boles?aw Dawidowicz <bdawidow(a)redhat.com&gt; Subject: Re: [gatein-dev] enable/disable users To: gatein-dev(a)lists.jboss.org Message-ID: <5167E1D8.9030803(a)redhat.com&gt; Content-Type: text/plain; charset=UTF-8; format=flowed Could you start a specification for this? https://community.jboss.org/wiki/GateInSpecifications After you write down requirements you have in mind we could discuss and agree on how it should look in final form. On 04/12/2013 12:21 PM, Luca Stancapiano wrote: > Hi, I've seen there is not still the workflow for the enabling or > disabling of the users. It was in the old jboss portal. Are there > developements in progress? > > > _______________________________________________ > gatein-dev mailing list > gatein-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/gatein-dev > ------------------------------ _______________________________________________ gatein-dev mailing list gatein-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/gatein-dev End of gatein-dev Digest, Vol 43, Issue 7 *****************************************