Intellij license
by Julien Viet
It should expire next week.
I asked for a one year renewal.
I'll keep you informed.
Julien
10 years, 7 months
JCR error when starting GateIn with postgresql
by Christophe Laprun
Hi all,
I'm getting tthe following error when starting GateIn master with
postgresql 9.1 on JBoss EAP 6.1. Any idea what that might come from or
what's going on?
14:58:26,339 ERROR [exo.jcr.component.core.RepositoryContainer] (MSC
service thread 1-4) Repository error:
org.exoplatform.services.jcr.impl.storage.JCRInvalidItemStateException:
[system] ADD NODE. Parent not found. Item
[]:1[http://www.jcp.org/jcr/1.0]system:1, ID:
00exo0jcr0system0uuid00000000000, ParentID:
00exo0jcr0root0uuid0000000000000. Cause >>>> ERROR: insert or update on
table "jcr_isystem" violates foreign key constraint "jcr_fk_isystem_parent"
Detail: Key (parent_id)=(00exo0jcr0root0uuid0000000000000) is not
present in table "jcr_isystem".: ERROR: insert or update on table
"jcr_isystem" violates foreign key constraint "jcr_fk_isystem_parent"
Detail: Key (parent_id)=(00exo0jcr0root0uuid0000000000000) is not
present in table "jcr_isystem".: ERROR: insert or update on table
"jcr_isystem" violates foreign key constraint "jcr_fk_isystem_parent"
Detail: Key (parent_id)=(00exo0jcr0root0uuid0000000000000) is not
present in table "jcr_isystem".
Thanks in advance.
--
Cordialement / Best,
Chris
Principal Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
Follow GateIn: http://blog.gatein.org / http://twitter.com/gatein
Follow me: http://metacosm.info/metacosm / http://twitter.com/metacosm
11 years
GateIn Component Releases
by Bolesław Dawidowicz
As part of the schedule we should release all components next week to
include in comming 3.6.0.Beta02. All released versions should be .CR0X
or .Final at this point.
gatein-parent remains the same - 1.2.0.Final - I don't see anything
worth upgrading at this point
I have just released gatein-dev 1.2.1.CR01. Would be great if everyone
check for anything worth upgrading there. Stuff that we override in
<dependencyManagement> sections in other poms including it and etc.
I will start releasing components one by one next week to include needed
dependency upgrades. Likely around Wednesday/Thursday. Let me know about
the ones that need more time.
Bolek
11 years
TestSimpleGeneratorService
by Julien Viet
Hi,
I had an issue with the TestSimpleGeneratorService that can randomly fail and I suspect it could be related to the "Thread.sleep(1000)" statement:
https://github.com/gatein/gatein-portal/blob/master/component/web/securit...
can someone give me the reason of this and if there is a possible track for improving this ?
The observed issue with Jenkins (exo private instance) was:
java.lang.NullPointerException
at org.exoplatform.web.security.TestSimpleGeneratorService.testDuplicatedTokenGeneration(TestSimpleGeneratorService.java:80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at junit.framework.TestCase.runTest(TestCase.java:168)
at junit.framework.TestCase.runBare(TestCase.java:134)
at org.exoplatform.component.test.AbstractGateInTest.runBare(AbstractGateInTest.java:81)
at junit.framework.TestResult$1.protect(TestResult.java:110)
at junit.framework.TestResult.runProtected(TestResult.java:128)
at junit.framework.TestResult.run(TestResult.java:113)
at junit.framework.TestCase.run(TestCase.java:124)
at junit.framework.TestSuite.runTest(TestSuite.java:243)
at junit.framework.TestSuite.run(TestSuite.java:238)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:234)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:133)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:114)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:188)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:166)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:86)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:101)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
Julien
11 years
Determining the type of PortletRequest from a Servlet Request Listener
by Ken Finnigan
Does anyone know if its possible to determine what kind of PortletRequest (Action/Render/etc) is being triggered from the raw ServletRequest? Before the Portlet Container interceptors have fired.
If it's not possible, does anyone have any objections to modifying PC to set a value onto the request to make it identifiable?
An initial thought is to modify ContextDispatcherInterceptor.invoke() from
CallableImpl callable = new CallableImpl(invocation);
reqCtx.dispatch(targetCtx, invocation.getRequest(), invocation.getResponse(), callable);
return callable.response;
to
CallableImpl callable = new CallableImpl(invocation);
invocation.getRequest().setAttribute("cdi.portlet.invocation", invocation);
reqCtx.dispatch(targetCtx, invocation.getRequest(), invocation.getResponse(), callable);
return callable.response;
The actual attribute name I've just set to anything to illustrate the code at present.
If not the invocation itself, then can we set an Enum or integer value to indicate the portlet request type?
Thanks
Ken
========================
Senior Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
11 years, 1 month
CDI Injection for GateIn
by Ken Finnigan
All,
The work to have CDI injection into portlets and filters is almost complete, but a difference has been discovered between AS7 and Tomcat.
In essence, the ApplicationDispatcher for Tomcat never fires the ServletRequestEvent on includes, but the ApplicationDispatcher in AS7 has been modified to fire the event when the current TCCL is different to the classloader on the Context.
I'm proposing that in the Tomcat specific bits of WCI, I create an extended CommandServlet that performs the same check and fires the events as desired.
Any concerns or better approaches are most welcome.
Ken
========================
Senior Software Engineer / JBoss Enterprise Middleware Red Hat, Inc.
11 years, 1 month
Re: [gatein-dev] enable/disable users
by Luca Stancapiano
Ok I update the page in
https://community.jboss.org/wiki/GateInSpecifications
On Fri, Apr 12, 2013 at 1:51 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: gatein-dev Digest, Vol 43, Issue 8 (Luca Stancapiano)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 12 Apr 2013 13:51:12 +0200
> From: Luca Stancapiano <l.stancapiano(a)sourcesense.com>
> Subject: Re: [gatein-dev] gatein-dev Digest, Vol 43, Issue 8
> To: gatein-dev(a)lists.jboss.org
> Message-ID:
> <CAO3WqDXn_gDwqbfRBkW6=J4JapS6JX=
> xG-QLoArFuA9uAozYQQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Ok I see now the new page
> has it to add in the index page?
> https://community.jboss.org/wiki/GateInSpecifications
>
>
> On Fri, Apr 12, 2013 at 1:49 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: enable/disable users (Julien Viet)
> > 2. Re: gatein-dev Digest, Vol 43, Issue 7 (Luca Stancapiano)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Fri, 12 Apr 2013 13:18:11 +0200
> > From: Julien Viet <julien(a)julienviet.com>
> > Subject: Re: [gatein-dev] enable/disable users
> > To: Boles?aw Dawidowicz <bdawidow(a)redhat.com>
> > Cc: gatein-dev(a)lists.jboss.org
> > Message-ID: <0EAB4969-4317-449B-9EC2-92D6D8F8970A(a)julienviet.com>
> > Content-Type: text/plain; charset=utf-8
> >
> > Hi Luca,
> >
> > I started this spec page about this feature :
> >
> > https://community.jboss.org/wiki/DisabledUser
> >
> > would you mind to use it instead of the new page you created ?
> >
> > thanks
> >
> > Julien
> >
> >
> >
> > On Apr 12, 2013, at 12:28 PM, Boles?aw Dawidowicz <bdawidow(a)redhat.com>
> > wrote:
> >
> > > 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
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Fri, 12 Apr 2013 13:49:00 +0200
> > From: Luca Stancapiano <l.stancapiano(a)sourcesense.com>
> > Subject: Re: [gatein-dev] gatein-dev Digest, Vol 43, Issue 7
> > To: gatein-dev(a)lists.jboss.org
> > Message-ID:
> > <
> > CAO3WqDXQbm3zeLkekoZsVo67F01R9hpH4TFA9NVfP7zvgEj5mQ(a)mail.gmail.com>
> > Content-Type: text/plain; charset="iso-8859-1"
> >
> > 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
> > > *****************************************
> > >
> > -------------- next part --------------
> > An HTML attachment was scrubbed...
> > URL:
> >
> http://lists.jboss.org/pipermail/gatein-dev/attachments/20130412/aee4fb29...
> >
> > ------------------------------
> >
> > _______________________________________________
> > 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 8
> > *****************************************
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/gatein-dev/attachments/20130412/0bdeccb4...
>
> ------------------------------
>
> _______________________________________________
> 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 9
> *****************************************
>
11 years, 1 month
enable/disable users
by Luca Stancapiano
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?
11 years, 1 month
Re: [gatein-dev] gatein-dev Digest, Vol 43, Issue 8
by Luca Stancapiano
Ok I see now the new page
has it to add in the index page?
https://community.jboss.org/wiki/GateInSpecifications
On Fri, Apr 12, 2013 at 1:49 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: enable/disable users (Julien Viet)
> 2. Re: gatein-dev Digest, Vol 43, Issue 7 (Luca Stancapiano)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 12 Apr 2013 13:18:11 +0200
> From: Julien Viet <julien(a)julienviet.com>
> Subject: Re: [gatein-dev] enable/disable users
> To: Boles?aw Dawidowicz <bdawidow(a)redhat.com>
> Cc: gatein-dev(a)lists.jboss.org
> Message-ID: <0EAB4969-4317-449B-9EC2-92D6D8F8970A(a)julienviet.com>
> Content-Type: text/plain; charset=utf-8
>
> Hi Luca,
>
> I started this spec page about this feature :
>
> https://community.jboss.org/wiki/DisabledUser
>
> would you mind to use it instead of the new page you created ?
>
> thanks
>
> Julien
>
>
>
> On Apr 12, 2013, at 12:28 PM, Boles?aw Dawidowicz <bdawidow(a)redhat.com>
> wrote:
>
> > 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
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 12 Apr 2013 13:49:00 +0200
> From: Luca Stancapiano <l.stancapiano(a)sourcesense.com>
> Subject: Re: [gatein-dev] gatein-dev Digest, Vol 43, Issue 7
> To: gatein-dev(a)lists.jboss.org
> Message-ID:
> <
> CAO3WqDXQbm3zeLkekoZsVo67F01R9hpH4TFA9NVfP7zvgEj5mQ(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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
> > *****************************************
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://lists.jboss.org/pipermail/gatein-dev/attachments/20130412/aee4fb29...
>
> ------------------------------
>
> _______________________________________________
> 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 8
> *****************************************
>
11 years, 1 month
