3:14 p.m.
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.
7:12 p.m.
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
11:03 a.m.
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
2:25 p.m.
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
4290
days inactive
4292
days old
3 comments
2 participants
participants (2)
-
Julien Viet -
Ken Finnigan