I have to check the method out for what it does out for now nothing is
done in this regard.
My code works currently that way that over all jsf artefacts which can
be set via the faces-config proxies are wrapped around and the proxies
basically
dynamically reload the groovy classes if the file dates change (hence
the classloader).
So what we get are dynamically reloadable beans, phase listeners,
etc... pretty much everything from the faces-config.
I am not sure how well this mixes with the new annotations.
Werner
Leonardo Uribe schrieb:
2009/8/11 Werner Punz <[email protected] <mailto:[email protected]>>
I dont think it will conflict, the reason for this is, I want to add
the option as web.xml override.
Which means a user who wants to use the groovy bindings has to add a
context param. If this param is not set nothing is done and the code
defaults to the code currently in existence.
Hi
Ok, I understand. In ViewDeclarationLanguage class there is a method
called getScriptComponentResource. Do you have any plan to write this
method, so users can write jsf components in groovy?
regards
Leonardo Uribe
The groovy bindings are a plugin like extval.
Werner
Leonardo Uribe schrieb:
Hi
+1. I suppose this code conflict with MYFACES-2290 Add OSGi
bundle information and bundle classloader / activator, but we
can see it in deep later when we have committed this one.
regards
Leonardo Uribe
2009/8/11 Matthias Wessendorf <[email protected]
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]>>>
+1 for adding that to 2.0 only.
looking forward :-)
On Tue, Aug 11, 2009 at 10:17 PM, Werner
Punz<[email protected] <mailto:[email protected]>
<mailto:[email protected]
<mailto:[email protected]>>> wrote:
> Hello everyone. I am sort of overdue with my promised
commit of
the myfaces
> groovy bindings, the reason simply was life itself.
>
> Anway to make things finally clear I want to propose
following.
> I want to commit the bindings this week, but I want to opt for
myfaces 2.0
> instead of still going with 1.2.
>
> The reason simply is following:
> I need to add a mechanism which allows to replace the
classloader
> during initialisation which means following we have to add
code
> to our initialisation code in our servlet context which
allows this.
> Now that 2.0 still is in development this is less critical
than
to add it to
> a stable 1.2.
>
> And to be honest I do not want to support two versions of
myfaces
for the
> initial stage.
> So here is the deal, I will commit the codebase this week,
which
still has
> the dirty initialisation and add the needed extensions asap in
the 2.0
> codebase and I will work on make it running so that we
have the
extension up
> and running when we hit final, sort of a goody to have
> if you use myfaces.
>
> Werner
>
>
>
>
>
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
