[orchestra] getting ready for a release

[simon <sk...@apache.org>]

Hi All,

A little bird told me that an Orchestra release is very near (the core
module at least). Actually, it was Mario and as he is Mr Orchestra I
think it's quite likely to happen :-)

I've therefore gone through orchestra-core again, and am personally
happy with the current API. I think that it is in a good state for a
freeze, ie that after a release we should be able to keep binary
compatibility without any major headaches.

Sorry for the incompatibilities I caused while doing this (and the flood
of commits) but better to break stuff that needs breaking now than to
release stuff that will cause problems later. In particular, the
incompatible changes that might affect users are:
* dont end conversation on null return from action
* renamed the FrameworkAdapterServletFilter
* removed a config param from the OrchestraServletFilter
* moved the JpaPersistenceContextFactory class into the spring package.
* when using the LocalFrameworkAdapter a ConversationMessager class must
now be explicitly specified.

There was other stuff, but I very much doubt anyone was using those
methods (yet).

If anyone wants to suggest API changes for Orchestra, I suggest you do
it in the very near future...

I've also updated the docs to match the latest changes (I hope). They
are not perfect, but will have to do for now. Any proofreading would be
appreciated.

Regards,

Simon

Re: [orchestra] Using LocalFrameworkAdapter (was: getting ready for a release)

[simon <si...@chello.at>]

Hi Dan,

The LocalFrameworkAdapter is not created via a variable lookup;
instances are just created via a call to "new" from the corresponding
servlet filter. There is therefore no way to do dependency-injection
into it. It would not be nice to have the filters use Spring, as we
would then need a different filter implementation for each DI framework
we support.

So the "localFrameworkAdapter" bean you show below will never be used.
See the class LocalFrameworkAdapterFilter for details.

The conversationMessager setup you show below is what I had intended.
However as Mario notes, there is a problem: we only allow one
conversationMessager bean definition, but each of the frameworks should
use a different class. There is no way to currently express this. Your
config below for the conversationMessager will set it globally -
including for JSF requests.

I suggest instead you either remove this setting, or use
  o.a.m.o.conversation.jsf.JsfConversationMessager
as the class. This is technically wrong when your background thread is
running, but as long as nothing tries to actually use the messager
everything should run ok. And I guess nothing does, otherwise the old
orchestra code would have failed too.

Regards,

Simon

On Sat, 2007-10-06 at 20:35 -0700, Dan Tran wrote:
> 
> Simon, below is my LocalFrameworkAdatper configuration due your latest
> changes
> 
>   <bean id="localFrameworkAdapter"
> class="org.apache.myfaces.orchestra.frameworkAdapter.local.LocalFrameworkAdapter"
> autowire="byName"
>     scope="prototype" />
>     
>   <!-- ConversationMessager def needed because we are using the special
> LocalFrameworkAdapter. -->
>   <bean
> name="org.apache.myfaces.orchestra.conversation.ConversationMessager"
>    
> class="org.apache.myfaces.orchestra.conversation.basic.BasicConversationMessager"/>
> 
> 
> is there another more nature way ? like some thing I can inject into
> LocalFrameworkAdapater?

Re: [orchestra] getting ready for a release

[simon <si...@chello.at>]

Hmm. There is only ever one ConversationManager for a user session. It
is the ConversationManager that holds a reference to the appropriate
ConversationMessager to use when reporting problems. This ref is
initialised just once, when the conversationManager for a user session
is created.

However Dan wants to be able to run two different frameworks
concurrently - the JSF one for normal requests, and the "basic" one for
his background threads. Each framework needs a different
ConversationMessager:
* for JSF framework, add messages to faces error list
* for basic framework, write to local logfile.

It's a more generic problem, though. Anyone running mixed JSF and JSP
pages will also have this problem; when running a JSF request we want to
report problems via a FacesMessage, and for JSP do something else.

I think the old code was always broken - previously in the
background-thread case we used the JSF messager, which would presumably
crash horribly if the messager was ever used because no FacesContext
exists.

I see two problems to resolve:
1. What object should hold the reference to the conversationMessager,
and
2. The user needs to be able to specify a different class to use for
each different framework.

Sorry, but I don't understand how your suggestions below solve these
issues. Could you perhaps explain a little further?

I see the following options for problem 1:

A. Just retrieve the conversationMessager from the framework adapter
whenever it is needed.

The problem here is that there is only one framework adapter instance of
each type per webapp. Either we return a new instance each time, we
return a shared (ie app-scoped messager) or the framework adapter is
responsible for caching the object in the user session.

B. Leave the ref on ConversationMessager and make stuff running as a
background thread see a different HTTP Session, and therefore a
different ConversationManager.

This makes sense for the background thread case; is really not running
in the context of any particular user. However for cases where JSP and
JSF pages are being mixed this does not make sense; we need two
different messagers but should use the same conversationManager.

3. Make the ConversationManager aware of framework subtypes and have it
keep a map of conversationMessagers.

None of these are really tempting approaches. Can anyone come up with a
different suggestion?

For issue 2, we could change the framework adapter so that it checks for
"magic bean names" before trying to resolve the variable, and if it is a
special name then map it to a new name. For example, a call to 
  adapter.getBean("conversationMessager") 
would be mapped to
  resolveVariable(
   "org.apache.myfaces.orchestra.
    frameworkAdapter.jsf.messager")

That isn't entirely obvious, perhaps, but decent javadoc on the getBean
method should make that clear. I cannot think of any other simple way to
do this - except maybe using filter init params, as each framework has
its own filter config.

Comments?

Regards,

Simon

On Sun, 2007-10-07 at 09:40 +0200, Mario Ivankovits wrote:
> Hi!
> 
> Yep, I think we've overseen something here.
> 
> Simon, the ConversationManager to use depends on the used 
> FrameworkAdapter, but you can have multiple FrameworkAdapters in use in 
> your application.
> e.g. one for the local stuff, one for JSF, and in an mixed environment, 
> one for Servlets/JSP which means, we can't have a global configuration here.
> 
> I tried to allow to inject the instance of a ConversationMessager into 
> the FrameworkAdapter by introducing an AbstractFrameworkAdapter and fill 
> in the required configuration using injection. I've tried it by keeping 
> our magicBeans map, but I think now it comes a little bit complicated to 
> achive all this. At least the code no longer looks that nice.
> 
> I'd ask if we couldn't switch to the already discussed abstract basis 
> class for the FrameworkAdapter stuff where we could have a simple 
> get/setConversationMessager pair with an default value setted up by the 
> inherited class.
> Still, it might be required to go back to the ConversationMessager init 
> parameter to configure the default as we can't inject something into the 
> e.g. JsfFramworkAdapter.
> 
> Ciao,
> Mario
> 
> > Simon, below is my LocalFrameworkAdatper coniguration due your latest
> > changes
> >
> >   <bean id="localFrameworkAdapter"
> > class="org.apache.myfaces.orchestra.frameworkAdapter.local.LocalFrameworkAdapter"
> > autowire="byName"
> >     scope="prototype" />
> >     
> >   <!-- ConversationMessager def needed because we are using the special
> > LocalFrameworkAdapter. -->
> >   <bean
> > name="org.apache.myfaces.orchestra.conversation.ConversationMessager"
> >    
> > class="org.apache.myfaces.orchestra.conversation.basic.BasicConversationMessager"/>
> >
> >
> > is there another more nature way ? like some thing I can inject into
> > LocalFrameworkAdapater?
> >
> >
> >
> > Mario Ivankovits wrote:
> >   
> >> Hi Simon!
> >>
> >> Thanks for the hard work on stabilizing the api and cleanup the 
> >> documentation.
> >>
> >> Well, I'll start flying for a release in the next few hours ... if 
> >> everything went fine.
> >>
> >>
> >> Ciao,
> >> Mario
> >>
> >>
> >>
> >>     
> >
> >   
> 

Re: [orchestra] getting ready for a release

[Mario Ivankovits <ma...@ops.co.at>]

Hi!

Yep, I think we've overseen something here.

Simon, the ConversationManager to use depends on the used 
FrameworkAdapter, but you can have multiple FrameworkAdapters in use in 
your application.
e.g. one for the local stuff, one for JSF, and in an mixed environment, 
one for Servlets/JSP which means, we can't have a global configuration here.

I tried to allow to inject the instance of a ConversationMessager into 
the FrameworkAdapter by introducing an AbstractFrameworkAdapter and fill 
in the required configuration using injection. I've tried it by keeping 
our magicBeans map, but I think now it comes a little bit complicated to 
achive all this. At least the code no longer looks that nice.

I'd ask if we couldn't switch to the already discussed abstract basis 
class for the FrameworkAdapter stuff where we could have a simple 
get/setConversationMessager pair with an default value setted up by the 
inherited class.
Still, it might be required to go back to the ConversationMessager init 
parameter to configure the default as we can't inject something into the 
e.g. JsfFramworkAdapter.

Ciao,
Mario

> Simon, below is my LocalFrameworkAdatper configuration due your latest
> changes
>
>   <bean id="localFrameworkAdapter"
> class="org.apache.myfaces.orchestra.frameworkAdapter.local.LocalFrameworkAdapter"
> autowire="byName"
>     scope="prototype" />
>     
>   <!-- ConversationMessager def needed because we are using the special
> LocalFrameworkAdapter. -->
>   <bean
> name="org.apache.myfaces.orchestra.conversation.ConversationMessager"
>    
> class="org.apache.myfaces.orchestra.conversation.basic.BasicConversationMessager"/>
>
>
> is there another more nature way ? like some thing I can inject into
> LocalFrameworkAdapater?
>
>
>
> Mario Ivankovits wrote:
>   
>> Hi Simon!
>>
>> Thanks for the hard work on stabilizing the api and cleanup the 
>> documentation.
>>
>> Well, I'll start flying for a release in the next few hours ... if 
>> everything went fine.
>>
>>
>> Ciao,
>> Mario
>>
>>
>>
>>     
>
>   

Re: [orchestra] getting ready for a release

[Dan Tran <da...@gmail.com>]

Simon, below is my LocalFrameworkAdatper configuration due your latest
changes

  <bean id="localFrameworkAdapter"
class="org.apache.myfaces.orchestra.frameworkAdapter.local.LocalFrameworkAdapter"
autowire="byName"
    scope="prototype" />
    
  <!-- ConversationMessager def needed because we are using the special
LocalFrameworkAdapter. -->
  <bean
name="org.apache.myfaces.orchestra.conversation.ConversationMessager"
   
class="org.apache.myfaces.orchestra.conversation.basic.BasicConversationMessager"/>


is there another more nature way ? like some thing I can inject into
LocalFrameworkAdapater?



Mario Ivankovits wrote:
> 
> Hi Simon!
> 
> Thanks for the hard work on stabilizing the api and cleanup the 
> documentation.
> 
> Well, I'll start flying for a release in the next few hours ... if 
> everything went fine.
> 
> 
> Ciao,
> Mario
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-orchestra--getting-ready-for-a-release-tf4577820.html#a13079664
Sent from the My Faces - Dev mailing list archive at Nabble.com.

Re: [orchestra] getting ready for a release

[Mario Ivankovits <ma...@ops.co.at>]

Hi Simon!

Thanks for the hard work on stabilizing the api and cleanup the 
documentation.

Well, I'll start flying for a release in the next few hours ... if 
everything went fine.


Ciao,
Mario