Application Initialization

[Aino Andriessen]

Hi all,

I'm looking for some best practices to retrieve information from the
database on entering the application, or what you can call
initialization. The ServletContextListener could be an option but it's
fairly low level. It would be nice to create a taskflow and call that
(have that called) upon initialization.

What are your suggestions?

We're currently on 11gPS3 but hopefully on R2 soon.

Ciao
Aino

[Jean-Marc Desvaux]

Hi Aino,

If you have at least one AM in your application, which is usually the case, our approach is to extend AMImpl and overwrite prepareSession and call a initSession that does the database init needed :

In Example below we set some User session parameters and set client Identifier in the database, double check for security reason that use has access to this module and log an application access event in the database:

public class BaseApplicationModuleImpl extends ApplicationModuleImpl {

    public BaseApplicationModuleImpl() {

    }

    protected void prepareSession(Session session) {

        […]

        super.prepareSession(session);

        initSession();

    }

    protected void initSession() {

        storeUserSessionParameters();

        setClientIdentifier();

        if (!checkUserAccess()) {

            throw new oracle.jbo.JboException("You may not access this Module for this Project.");

        }

        logAppsConnectionAudit((String)getSession().getUserData().get(GCCConstants.PARAM_ADD_CONNECTION_DESC));

    }

Jean-Marc

[Aino]

Hi Jean-Marc,

Thanx for the suggestion. But actually we need it the other way around. We need to retrieve some information from the database and use that for and in our pages, either in the un as the bounded taskflows. Preferably we'd like to retrieve it once and make it available as a managed bean.

Ciao

  Aino

--
You received this message because you are subscribed to the ADF Enterprise Methodology Group (http://groups.google.com/group/adf-methodology). To unsubscribe send email to adf-methodolo...@googlegroups.com
 
All content to the ADF EMG lies under the Creative Commons Attribution 3.0 Unported License (http://creativecommons.org/licenses/by/3.0/). Any content sourced must be attributed back to the ADF EMG with a link to the Google Group (http://groups.google.com/group/adf-methodology).

[Jean-Marc Desvaux]

Aino,

Well we do both in our initSession. With storeUserSessionParameters() for example, we retrieve user data from the database and store it in a session bean to make it available in pages.

Jean-Marc

[Jean-Marc Desvaux]

Maybe I should add that data is passed from the AM session to the Bean, using beforePhase prepare model  to create a new session bean (if not already done), get the parameters from the AM session and set them in the bean (if not already done).

Jean-Marc

[Aino]

Hi Jean-Marc,

But this solution doesn't work without binding. Our first page, actually multiple, might be 'plain' Faces pages, that don't access the Model.

Currently we use an HttpSessionListener with direct AM access. But I'm not entirely happy with using such a solution.

By the way, the bookmark method could also be (mis)used for this purpose. Although it must be defined on all callable pages and interferes with actual bookmark methods. So I wouldn't recommend this practice.

However, although all these methods would kind of fulfill the job, they are in my opinion still workarounds. It would be great to comprehensibly and declaratively (with a taskflow) define session or application initialization actions.

Am I missing something?

Is this a common requirement or not and how do others handle this?

Ciao

  Aino

On Thu, Jul 14, 2011 at 4:20 PM, Jean-Marc Desvaux <jm.de...@gcc.mu> wrote:

Maybe I should add that data is passed from the AM session to the Bean, using beforePhase prepare model  to create a new session bean (if not already done), get the parameters from the AM session and set them in the bean (if not already done).

Jean-Marc

[Jean-Marc Desvaux]

Aino,

Sure you need a model. You mentioned initial database access to load some data in a managed bean and use it, so an AM makes sense ..

I agree with you these are workarounds and a clean and declarative way to define initialization actions would be great to have.

Maybe if there was something like an unbounded taskflow default activity ?

Jean Marc

[luc...@gmail.com]

Aino, Jean-Marc,

A (currently not existing) Unbound taskflow initializer would be even more appropriate for this kind of use case. And while we are at it why not also file an ER for an Unbound taskflow finalizer.
If we could have these two, it would be very obvious where to implement application initialization.

I discussed the initialization issue with Aino yesterday, and I think that is difficult (without the workarounds mentioned) to do proper initialization.

Regards Luc

[Jean-Marc Desvaux]

Hi Luc,

Let's file one then !

Can we leave it to Aino ? 

Remember to add it to "The official ADF EMG "bug" and "ER" thread" ... 

Pence down ! (same TZ only)

Have a nice week-end.

Jean Marc

[Aino]

Good suggestion.

I'll go with it next week. Weekends starts.......... about now :-) !

Ciao

  Aino

[Nick Haralabidis]

Aino,

check out this OTN thread to see it helps you: http://forums.oracle.com/forums/thread.jspa?messageID=9669478

Sounds like you are looking for something like it,

Nick

[fnimphiu]

One option is to start your application with a bounded task flow
instead using a page in an unbounded task flow. You can enable the
task flow for URL invoke and then start the application from it (don't
use the "calculated" default setting). This way the initializer should
be called.

The finalizer is a different topic as you don't want to use a return
activity on this task flow as the return would most likely send the
browser to nirvana. For the same reason it does not make sense to have
a finalizer on an unbounded task flow as you wont exit this unbounded
task flow other than browsing away from the application.

Another thought: If you use a page in an unbounded task flow to start
your application, then this can only have JSPX documents in it. So why
not using the f:view before and after listener to initialize beans?
You can check if the bean you use to store information in exists
before querying the data. This way even if people hit refresh on the
browser or just navigate back and forth no extra query is issued

Frank

[Jan Vervecken]

hi Frank

The way you describe suggestions/solutions/workarounds here, it
doesn't look like "application initialization" is currently an
"explicit framework feature".

Would you agree that it might be a good idea to make "application
initialization" a more explicit framework feature (maybe as an
"unbound taskflow initializer" as suggested by Luc)?

regards
Jan Vervecken

[Jan Vervecken]

hi Aino

Have you already been able to file an enhancement request about
"application initialization"?

regards
Jan Vervecken

On Jul 15, 3:14 pm, Aino <aino.andries...@gmail.com> wrote:
> Good suggestion.
> I'll go with it next week. Weekends starts.......... about now :-) !
>
> Ciao
>   Aino
>

[fnimphiu]

If you need an initializer for an unbounded task flow, isn't this what
phase listeners or the after / before phase methods on f:view are
for ? Given that ADF page phase listeners can be programmatically
added and removed from an ADF application, I would think this to be an
option. This also allows you to handle the case where someone access a
page to then navigate off to another.

btw, what is an application ? Is it only what is started from a
specific context root, or is it something that could spread across
Java EE context roots ? I don't mind filing an ER for an application
initializer if we can specify what an application is, and why the
requirement cannot be implemented differently ?

Frank

[Jan Vervecken]

Thanks for your reply Frank.

For the moment I am not in need of "application initialization", so I
currently can't provide real use-case specifics related to your "what
is an application" question or about "why the requirement cannot be
implemented differently" in this context.

Maybe Aino can give feedback, as he wrote earlier in this thread "It

would be great to comprehensibly and declaratively (with a taskflow)
define session or application initialization actions."

Or maybe Luc can give feedback, as he wrote earlier in this thread "I

discussed the initialization issue with Aino yesterday, and I think
that is difficult (without the workarounds mentioned) to do proper
initialization."

regards
Jan Vervecken