Re: [gatein-dev] gatein-dev Digest, Vol 43, Issue 7
by Luca Stancapiano
done:
https://community.jboss.org/wiki/EnableDisableUsers
On Fri, Apr 12, 2013 at 12:28 PM, <gatein-dev-request(a)lists.jboss.org>wrote:
> 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>
> Subject: Re: [gatein-dev] PortletApplicationDeployer listeners
> To: Julien Viet <julien(a)julienviet.com>
> Cc: gatein-dev(a)lists.jboss.org
> Message-ID: <734306130.3082080.1365696209274.JavaMail.root(a)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(a)julienviet.com>
> > To: "Ken Finnigan" <kfinniga(a)redhat.com>
> > 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>
> Subject: Re: [gatein-dev] PortletApplicationDeployer listeners
> To: Ken Finnigan <kfinniga(a)redhat.com>
> Cc: gatein-dev(a)lists.jboss.org
> Message-ID: <5D2D0218-7B8E-4DBE-92B1-8E410391EC28(a)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(a)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(a)julienviet.com>
> > To: "Ken Finnigan" <kfinniga(a)redhat.com>
> > 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/c126ae7b...
>
> ------------------------------
>
> Message: 3
> Date: Fri, 12 Apr 2013 12:21:41 +0200
> From: Luca Stancapiano <l.stancapiano(a)sourcesense.com>
> Subject: [gatein-dev] enable/disable users
> To: gatein-dev(a)lists.jboss.org
> Message-ID:
> <CAO3WqDVOGgig5AdjEf=cNA5dOFmiY5HTppGX+4Sf=+
> ASF+Rc7w(a)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...
>
> ------------------------------
>
> Message: 4
> Date: Fri, 12 Apr 2013 12:28:40 +0200
> From: Boles?aw Dawidowicz <bdawidow(a)redhat.com>
> Subject: Re: [gatein-dev] enable/disable users
> To: gatein-dev(a)lists.jboss.org
> Message-ID: <5167E1D8.9030803(a)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(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
> *****************************************
>
11 years
PortletApplicationDeployer listeners
by Ken Finnigan
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.
11 years
Code clean-up - EOL markers
by Viliam Rockai
Hi all,
I've bumped into a code-style issue recently. It's about the newline/EOL
marker [1]. Some files in the GateIn source code are using windows-style
and some are using unix-style EOL marker. Some of the files are even
using both in single file. For example this file:
web/eXoResources/src/main/webapp/skin/DefaultSkin/portal/webui/component/customization/UIAccountSettingForm/Stylesheet.css
is using LF (unix) in the copyright section and CR+LF (windows) in the
rest of the file.
Editing and saving such file in "regular" editor (like gedit or
NetBeans; on the other hand vim seems to preserve the existing EOL
markers) leads to big diff caused only because of the change of the EOL
marker.
Is it OK, if I use only the unix-style EOL marker from now on (which
means one-shot unnecessary big diffs)? Do we want to do some bigger
clean-up to unify the EOL markers in all files?
Viliam
---
[1] http://en.wikipedia.org/wiki/Newline
11 years
