Portlet instantiated twice

[leolo]

Hi,

interesting phenomenon on GateIn-3.0.0-CR01. My portlets are instantiated twice:

Portlet-Code:

public class MyPortlet extends GenericPortlet {

    static int counter = 0;
   
    @Override
    public void init() throws PortletException {
        super.init();
        System.out.println("### Portlet-Init Called "+counter+" ###");
        System.out.println("this: "+this);
        counter++;
    }

[...]

}

Console-Output:

16:14:35,187 INFO  [TomcatDeployment] deploy, ctxPath=/TestPortlet
16:14:35,296 INFO  [STDOUT] ########### Portlet-Init Called 0 ##############
16:14:35,296 INFO  [STDOUT] this: my.test.portlet.MyPortlet@18d47e9
16:14:35,296 INFO  [STDOUT] ########### Portlet-Init Called 1 ##############
16:14:35,296 INFO  [STDOUT] this: my.test.portlet.MyPortlet@1b11657

Bug?

Regards,

LeoLo

[leolo]

I've created a test-war. Can someone confirm the issue?

My system: GateIn 3.0.0 CR1 with JBoss AS 5.1.0 JDK6 (zip) on Windows XP.

[theute]

Excellent, thanks.

If you have some time, can you try after you delete server/default/gatein-sample* ? And see if you have the same behaviour

[leolo]

Hi,

I've deleted

\GateIn-3.0.0-CR01\server\default\deploy\gatein-sample-extension.ear

and

\GateIn-3.0.0-CR01\server\default\deploy\gatein-sample-portal.ear

It's okay now!

[theute]

I didn't think of it first, but that's expected.

gatein-sample-portal is a completely disconnected context for portals.

By default it's accessible through http://localhost:8080/sample-portal

[leolo]

Is this sample-portal-context just a testing-thingi or is the "gatein-standard-technology" used for it, to manage multiple portal-contexts in parallel? (like virtual hosts/portals)

If the latter is the case, all deployed war-files will get deployed in all available portal-contexts? I can't say warfile1 goes only to context 1?

[theute]

It's a new feature, not a test.

It's 1 app server so the app is deployed in the app server and can be available to all portal contexts.

Now, there is 1 application registry per portal context, so the admin can decide which portlets are made available for people who create the pages. It gives you that flexibility.  That said you cannot (yet) limit per portal context what applications the admin can add to the application registry.

To summarize:

All portlets are deployed and mae available in all portal contexts --> Admins filter what they want to make available to page editors for their portal context -> Page editors see a limited set of applications and can build a page with those.

(Yes this needs to be documented, if someone wants to help we have unauthored/unpublished doc  to translate into docbook please ping me (requires to filter out info about internal details, to make a developer friendly doc))

I hope this answers your question.

[leolo]

Yes, that answers my question. Thanks!