[
https://issues.apache.org/jira/browse/ORCHESTRA-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598279#action_12598279
]
Scott O'Bryan commented on ORCHESTRA-25:
----------------------------------------
Trinidad was able to get this working with it's "configurator" framework. I've
got a version of the "configurator" framework on my laptop ready for commons.
If you guys are interested in using it let me know and I'll get it checked in
ASAP. Before it's released, though, I'm going to need help getting some tests
written.
Here is the lowdown. The configurator infrastructure is a prioritized
service-based system. Each configurator contains init, beginRequest,
getExternalContext, endRequest, and destroy methods. By default the
configurator system is run by registering a custom FacesContextFactory and
ensures a consistent set of logic between servlet and portlet environments. In
servlet environments it can also be configured to run from a filter (either by
the orchestra filter or by the filter included with the package).
When using WSRP alone, though, your filters will not run. The producer would
need to be the one servicing the request and your filter would have to be set
up at the web-service layer. Configurators, however, would run so long as you
are using a compatible bridge.
I'd have to double check but I don't think the current bridge implementation is
bridge dependent yet, but the code I've written for commons is for JSF 1.2
only. Trinidad has both a 1.1 and a 1.2 version.
Anyway, how I foresee this working with Orchestra is that Orchestra can
abstract it's filter logic into an implementation similar to the configurator
system. The filter would check to see if the commons-configurator library is
in the classpath and if it is, it can defer running it's logic to that
framework, otherwise it can call into its initialization logic itself.
Orchestra would then implement a Configurator which calls into this
initialization logic as well and configure it by adding a file to it's
META-INF/services directory. When the configurators are present, this logic
will run in both Portal and WSRP environments without configuration. Otherwise
it will run in the filter environment without the configurator system in the
classpath.
Of course if you include the configurators as a dependency then this logic even
becomes simpler..
So would you be willing to help me try to bring the faces-commons-configurators
to a beta release? If so, I can check in the code I have now and let you pound
on it. The piece I've been waiting on is that I was hoping to include a
multi-part form handler (file download) configurator with the package, but I
don't have that done yet.
> Orchestra does not work within BEA WebLogic JSF portlet - FacesContextFactory
> related problem
> ---------------------------------------------------------------------------------------------
>
> Key: ORCHESTRA-25
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-25
> Project: MyFaces Orchestra
> Issue Type: Bug
> Components: FrameworkAdapter
> Affects Versions: 1.1
> Environment: BEA WebLogic Portal 9.2, BEA WebLogic JSF portlets,
> Sun JSF RI 1.1_01, MyFaces Orchestra 1.2 snapshot
> Reporter: Gautam Marwaha
> Attachments: stacktrace_1.txt, stacktrace_2.txt
>
>
> I have read about the Orchestra's support for conversation scope and think it
> is very promising for an application we're building that needs to support 1)
> updates in wizard kind of screens where users submit changes made in multiple
> tabs and 2) have this working in scenarios where users do a ctrl+n / open new
> browser windows (=> session scope is ruled out)
> To get things started I am trying to get an Orchestra example (multiBean)
> working on our tech stack - BEA WebLogic Portal 9.2, BEA WebLogic JSF
> portlets, Sun JSF RI 1.1_01 and MyFaces Orchestra 1.2 snapshot. We are not
> going to have any non-JSF functionality in our application.
> So far I have been successful in running the example on BEA WebLogic Portal
> 9.2 *without* wrapping the JSPs within a JSF portlet. However, as soon as I
> wrap the JSP within a JSF portlet, I get the following error on the examples
> home page (/start.jsp):
> java.lang.ClassCastException:
> com.sun.faces.context.MyHttpServletRequestWrapper
> at
> com.bea.portlet.adapter.faces.lifecycle.LifecycleImpl.restore(LifecycleImpl.java:308)
> at
> com.bea.portlet.adapter.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:199)
> at
> com.bea.portlet.adapter.faces.FacesContentStubImpl.render(FacesContentStubImpl.java:224)
> at
> com.bea.netuix.servlets.controls.content.FacesContent.beginRender(FacesContent.java:312)
> This issue is showing up because
> myfaces-orchestra-core-1.2-SNAPSHOT.jar!faces-config.xml contains Orchestra
> related FacesContextFactory classes that are loaded by Faces Servlet upon
> startup. Looks like these factories
> (org.apache.myfaces.orchestra.lib.jsf.OrchestraFacesContextFactory is one of
> them) are not returning valid FacesContext objects (they're returning an
> object meant for servlet / non-portlet environments) and cause a
> ClassCastException in BEA Portal's classes that appear to be casting the
> request to FacesRequest, something like:
> (FacesRequest)context.getExternalContext().getRequest();
> To fix this problem, I added the BEA Portal specific FacesContextFactory
> (present in their faces-adapter.jar!faces-config.xml) into my applications's
> faces-config.xml. i.e. the following lines:
> <factory>
> ....
>
> <faces-context-factory>com.bea.portlet.adapter.faces.context.FacesContextFactoryImpl</faces-context-factory>
>
> ....
> </factory>
> This atleast got me to the examples home page (/start.jsp) since the server
> appears to have picked up the factory it last loaded. But, there is a side
> effect of this change. Now I find that FrameworkAdapter has not been
> initialized properly. The error is:
> Caused by: java.lang.IllegalStateException: FrameworkAdapter not found
> at
> org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:111)
> at
> org.apache.myfaces.orchestra.conversation.ConversationManager.getInstance(ConversationManager.java:86)
> at
> org.apache.myfaces.orchestra.conversation.spring.AbstractSpringOrchestraScope.getRealBean(AbstractSpringOrchestraScope.java:311)
> at
> org.apache.myfaces.orchestra.conversation.spring.ScopedBeanTargetSource.getTarget(ScopedBeanTargetSource.java:71)
> at
> org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.getTarget(Cglib2AopProxy.java:666)
> at
> org.springframework.aop.framework.Cglib2AopProxy$DynamicAdvisedInterceptor.intercept(Cglib2AopProxy.java:616)
> at
> org.apache.myfaces.examples.multibean.Multibean$$EnhancerByCGLIB$$510f5a89.getBeanName()Ljava.lang.String;(:???)
> BEA Portal seems to be over-riding the Orchestra FacesContextFactory impl and
> not letting it do its per-request operations.
> I have looked around for a way of getting the same thing done via Orchestra
> filters. The following Orchestra filters are in my web.xml and haven't helped:
> -
> org.apache.myfaces.orchestra.frameworkAdapter.basic.BasicFrameworkAdapterFilter
> -
> org.apache.myfaces.orchestra.requestParameterProvider.RequestParameterServletFilter
> Even tried adding the
> org.apache.myfaces.orchestra.conversation.jsf.filter.OrchestraServletFilter
> filter but it did not help.
> I am not expecting BEA to fix/change anything on their side. Any chance this
> can be fixed in Orchestra?
> Thanks,
> Gautam
> PS - will attach full stacktraces after I create this JIRA item
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
