Send gatein-dev mailing list submissions to
gatein-dev@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@lists.jboss.org
You can reach the person managing the list at
gatein-dev-owner@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@redhat.com>
Subject: Re: [gatein-dev] PortletApplicationDeployer listeners
To: Julien Viet <julien@julienviet.com>
Cc: gatein-dev@lists.jboss.org
Message-ID: <734306130.3082080.1365696209274.JavaMail.root@redhat.com>
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@julienviet.com>
> To: "Ken Finnigan" <kfinniga@redhat.com>
> Cc: gatein-dev@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@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@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/attachment-0001.html
------------------------------
Message: 2
Date: Thu, 11 Apr 2013 21:25:35 +0200
From: Julien Viet <julien@julienviet.com>
Subject: Re: [gatein-dev] PortletApplicationDeployer listeners
To: Ken Finnigan <kfinniga@redhat.com>
Cc: gatein-dev@lists.jboss.org
Message-ID: <5D2D0218-7B8E-4DBE-92B1-8E410391EC28@julienviet.com>
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@redhat.com> 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@julienviet.com>
> To: "Ken Finnigan" <kfinniga@redhat.com>
> Cc: gatein-dev@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@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@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/attachment-0001.html
------------------------------
Message: 3
Date: Fri, 12 Apr 2013 12:21:41 +0200
From: Luca Stancapiano <l.stancapiano@sourcesense.com>
Subject: [gatein-dev] enable/disable users
To: gatein-dev@lists.jboss.org
Message-ID:
<CAO3WqDVOGgig5AdjEf=cNA5dOFmiY5HTppGX+4Sf=+ASF+Rc7w@mail.gmail.com>
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/attachment-0001.html
------------------------------
Message: 4
Date: Fri, 12 Apr 2013 12:28:40 +0200
From: Boles?aw Dawidowicz <bdawidow@redhat.com>
Subject: Re: [gatein-dev] enable/disable users
To: gatein-dev@lists.jboss.org
Message-ID: <5167E1D8.9030803@redhat.com>
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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/gatein-dev
>
------------------------------
_______________________________________________
gatein-dev mailing list
gatein-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/gatein-dev
End of gatein-dev Digest, Vol 43, Issue 7
*****************************************