Re: @PreDestroy, Servlet API,
There were a few of us that wanted to push back on the WebTier EG around annotation support over the fact that there wasn't a clear API provided-- yet oddly enough, everyone is ending up with basically the same API :-) My hope is that the WebBeans JSR can bring some solidarity around this through an injection API which other 'legacy' APIs can simply defer to (Similar to ELResolver). It is tricky from a JSF standpoint, especially with session clustering-- but would WeakReference with your own ReferenceQueue fix this problem of associating the @PreDestroy event? -- Jacob Remy Maucherat wrote: Bernd Bohmann wrote: The AnnotationProcessor/InjectionProvider are very similar. I don't like to define a new myfaces Interface for this use case. I would prefer the org.apache.AnnotationProcessor because is not tomcat specific and an apache implementation. Until we find a final solution we should only copy the code. I just had a look at InjectionProvider, and somehow the API is identical to AnnotationProcessor. It did not start that way, and I did not look at InjectionProvider at all (so I suppose it means the API makes sense :D). The interface is used by Catalina (the Servlet container) and also Jasper (Jasper gets the implementation using a specific context attribute). Unfortunately, I don't see a way to do non proprietary annotation/injection processing, since the component that has to do it (JSP or JSF) cannot possibly get the configuration (which could define overrides, etc). Since I suppose you'll want to support all containers, that's a problem. (It would have been solved if the servlet spec had defined an interface like InjectionProvider in javax.servlet, of course.) It's no problem to use the annotation name instead of using the class. But personal i prefer the class. Rémy
[Facelets][JSF 1.2][jsCookMenu] hidden jscook_action input hack still required?
Came across this today -- For facelets and JSF RI 1.2, you have to manually add the following to your form in order for an action to be triggered by a navigationMenuItem enclosed in a jscookMenu component. Does anyone know if this is fixed in the latest trunk? It's broken in the MyFaces 1.1.4 core release + my Tomahawk 1.1.4 snapshot from Aug 24, 2006. Maybe a JSF 1.2 or facelets user could test this for me (you don't need to define the backing bean -- if you don't get an error, it's still broke). And the fix to test is to add in the following in the form.
[jira] Created: (TOMAHAWK-916) jslistener.jsf example no longer works
jslistener.jsf example no longer works
--
Key: TOMAHAWK-916
URL: https://issues.apache.org/jira/browse/TOMAHAWK-916
Project: MyFaces Tomahawk
Issue Type: Bug
Components: JsValueChangeListener
Affects Versions: 1.1.3, 1.1.4-SNAPSHOT, 1.1.5-SNAPSHOT
Reporter: Mike Kienenberger
Priority: Critical
The jslistener.jsf example no longer works. Not sure when it broke.
http://www.irian.at/myfaces/jslistener.jsf
http://example.irian.at/example-simple-20070303/jslistener.jsf
MyFaces encountered an error.
Message: Value binding '#{jsListenerModel.optionItems}'of UISelectItems with
component-path {Component-Path : [Class:
javax.faces.component.UIViewRoot,ViewId: /jslistener.jsp][Class:
javax.faces.component.html.HtmlForm,Id: _idJsp0][Class:
javax.faces.component.html.HtmlPanelGrid,Id: _idJsp1][Class:
javax.faces.component.html.HtmlSelectOneMenu,Id: selone_menu_options][Class:
javax.faces.component.UISelectItems,Id: _idJsp13]} does not reference an Object
of type SelectItem, SelectItem[], Collection or Map but of type : null
java.lang.IllegalArgumentException: Value binding
'#{jsListenerModel.optionItems}'of UISelectItems with component-path
{Component-Path : [Class: javax.faces.component.UIViewRoot,ViewId:
/jslistener.jsp][Class: javax.faces.component.html.HtmlForm,Id: _idJsp0][Class:
javax.faces.component.html.HtmlPanelGrid,Id: _idJsp1][Class:
javax.faces.component.html.HtmlSelectOneMenu,Id: selone_menu_options][Class:
javax.faces.component.UISelectItems,Id: _idJsp13]} does not reference an Object
of type SelectItem, SelectItem[], Collection or Map but of type : null
at
org.apache.myfaces.shared_impl.util.SelectItemsIterator.hasNext(SelectItemsIterator.java:144)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.internalGetSelectItemList(RendererUtils.java:439)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getSelectItemList(RendererUtils.java:417)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.internalRenderSelect(HtmlRendererUtils.java:294)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.renderMenu(HtmlRendererUtils.java:267)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlMenuRendererBase.encodeEnd(HtmlMenuRendererBase.java:59)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:539)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.renderChild(RendererUtils.java:408)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGridRendererBase.renderChildren(HtmlGridRendererBase.java:229)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlGridRendererBase.encodeEnd(HtmlGridRendererBase.java:101)
at
javax.faces.component.UIComponentBase.encodeEnd(UIComponentBase.java:539)
at javax.faces.webapp.UIComponentTag.encodeEnd(UIComponentTag.java:498)
at javax.faces.webapp.UIComponentTag.doEndTag(UIComponentTag.java:366)
at
org.apache.myfaces.shared_impl.taglib.UIComponentBodyTagBase.doEndTag(UIComponentBodyTagBase.java:57)
at
org.apache.jsp.jslistener_jsp._jspx_meth_h_panelGrid_0(jslistener_jsp.java:335)
at
org.apache.jsp.jslistener_jsp._jspx_meth_h_form_0(jslistener_jsp.java:255)
at
org.apache.jsp.jslistener_jsp._jspx_meth_f_view_0(jslistener_jsp.java:200)
at org.apache.jsp.jslistener_jsp._jspService(jslistener_jsp.java:145)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:672)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:463)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:398)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:301)
at
org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatch(ServletExternalContextImpl.java:419)
at
org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspViewHandlerImpl.java:211)
at
org.apache.myfaces.lifecycle.RenderResponseExecutor.execute(RenderResponseExecutor
Re: @PreDestroy, Servlet API,
Unfortunately, I don't see a way to do non proprietary annotation/injection processing, since the component that has to do it (JSP or JSF) cannot possibly get the configuration (which could define overrides, etc). Since I suppose you'll want to support all containers, that's a problem. (It would have been solved if the servlet spec had defined an interface like InjectionProvider in javax.servlet, of course.) This is going to go down in the same category as inter Portlet communication and j2ee 1.4 web services deployment. It's no problem to use the annotation name instead of using the class. > But personal i prefer the class. Rémy -- Dennis Byrne
Re: @PreDestroy, Servlet API,
Bernd Bohmann wrote: The AnnotationProcessor/InjectionProvider are very similar. I don't like to define a new myfaces Interface for this use case. I would prefer the org.apache.AnnotationProcessor because is not tomcat specific and an apache implementation. Until we find a final solution we should only copy the code. I just had a look at InjectionProvider, and somehow the API is identical to AnnotationProcessor. It did not start that way, and I did not look at InjectionProvider at all (so I suppose it means the API makes sense :D). The interface is used by Catalina (the Servlet container) and also Jasper (Jasper gets the implementation using a specific context attribute). Unfortunately, I don't see a way to do non proprietary annotation/injection processing, since the component that has to do it (JSP or JSF) cannot possibly get the configuration (which could define overrides, etc). Since I suppose you'll want to support all containers, that's a problem. (It would have been solved if the servlet spec had defined an interface like InjectionProvider in javax.servlet, of course.) It's no problem to use the annotation name instead of using the class. But personal i prefer the class. Rémy
Re: MyFaces interview
I'm certainly happy to do the interview - but whoever wants to join in is very welcome. We might also not forget about Mario as an option for doing the interview, he has been very active in the last year with new ideas for MyFaces as well... Well, it's hard to decide who is supposed to do an interview for a true community project! If nothing else, this discussion proves we are not a community relying too much on any one member anymore ;)) regards, Martin On 3/2/07, Cagatay Civici <[EMAIL PROTECTED]> wrote: Martin, Matthias, Bruno. On 3/2/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > I'm not really heavily involved at this time. I'd be a poor choice. > > On 3/2/07, Werner Punz <[EMAIL PROTECTED]> wrote: > > Kito D. Mann schrieb: > > > Hello everyone, > > > > > > I'd like to conduct a new e-mail interview with one or two people from > > > the MyFaces Core team. The last one was in 2004 > > > ( http://www.jsfcentral.com/articles/geiler-04-04.html), and at that > > > time, it made sense to interview Manfred, since he is the founder and > > > was very heavily involved at the time. Who would be a good choice this > > > time around? > > > > > Thomas, Martin, Sean or Mike? > > > > > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Status of subForm: time for promotion?
my +1 for promoting this comp up to tomahawk. It's very useful, and I use it in several production level apps. I have never had any issues with its javascript either, but I don't have time to try to reproduce the bug. regards, Martin On 3/2/07, Jeff Bischoff <[EMAIL PROTECTED]> wrote: Does that bug even still exist? I'm using subForm successfully in app that is nearing production. :D Mike Kienenberger wrote: > Other than a volunteer, is there anything holding up the promotion of > subForm? > > I went through the issue tracker and created a subForm component > category and moved relevent issues into it. > > I only see one open issue for subForm, and I don't consider it a > blocker to promotion: > > http://issues.apache.org/jira/browse/TOMAHAWK-445 > > It has documentation: > > http://issues.apache.org/jira/browse/TOMAHAWK-445 > > It has an example: > > http://example.irian.at/example-sandbox-20070301/subForm.jsf > > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: MyFaces-API issue: getValue of UIInput
I forwarded the thread to Ed, as neither Adam, Craig, Kito or Manfred
had anything to say on this... or do they?
There is an alternative workaround: I checked it in RendererUtils
yesterday - for you to review. However, I think it makes the value
lookup code in the renderer very complicated. It might cause less
issues with compatibility to the RI behaviour, though.
regards,
Martin
On 3/2/07, Cagatay Civici <[EMAIL PROTECTED]> wrote:
> Yeah, exactly. Did you read my mail from before? Plus my new
issue-evaluation?
No, I read your mail after sending a reply about the converter, anyway
you're right about the bug Martin.
> In this case, I'd strongly recommend that you run this by the spec
> folks. If nothing else, we should get a clarification for the next
> revision.
I agree with Mike
On 3/2/07, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> In this case, I'd strongly recommend that you run this by the spec
> folks. If nothing else, we should get a clarification for the next
> revision.
>
> On 3/1/07, Martin Marinschek < [EMAIL PROTECTED]> wrote:
> > I didn't find anything in the spec.
> >
> > JavaDoc of getValue in UIOutput says:
> >
> > Gets the value of this UIComponent. First, consult the local value
> > property of this component. If non-null return it. If non-null, see if
> > we have a ValueBinding for the value property. If so, return the
> > result of evaluating the property, otherwise return null.
> >
> > This description is obviously wrong (two times "If non-null.."), but
> > if you correct this obvious mistake, it speaks against my solution.
> >
> > But then, reading the spec on a more general level it says:
> >
> > 3.1.4 Value Binding Expressions
> >
> > Properties and attributes of standard concrete component classes may be
value
> > binding enabled. This means that, rather than specifying a literal value
as the
> > parameter to a property or attribute setter, the caller instead
associates a
> > ValueBinding (see Section 5.3.3 "ValueBinding") whose getValue() method
must
> > be called (by the property getter) to return the actual property value
> > to be returned
> > if no value has been set via the corresponding property setter. If a
property or
> > attribute value has been set, that value must be returned by the
property getter
> > (shadowing any associated value binding expression for this property).
> >
> > and this would clearly indicate I'm on the right track. Properly
> > reading this would mean we are wrong-doers for every component
> > attribute of every component, even if the chance is rather small that
> > the issue arises for normal attributes (it might definitely happen
> > though).
> >
> > regards,
> >
> > Martin
> >
> > On 3/1/07, Mike Kienenberger < [EMAIL PROTECTED]> wrote:
> > > What's the spec say about UIInput's getValue()? If it's silent, I'd
> > > say your solution makes sense.
> > >
> > >
> > > On 3/1/07, Martin Marinschek < [EMAIL PROTECTED]> wrote:
> > > > Wanted to discuss a small thing with you:
> > > >
> > > > UIOutput currently has the following code:
> > > >
> > > > public Object getValue()
> > > > {
> > > > if (_value != null) return _value;
> > > > ValueBinding vb = getValueBinding("value");
> > > > return vb != null ?
(Object)vb.getValue(getFacesContext()) : null;
> > > > }
> > > >
> > > > UIInput has the following code:
> > > >
> > > > public void setValue(Object value)
> > > > {
> > > > setLocalValueSet(true);
> > > > super.setValue(value);
> > > > }
> > > >
> > > > My problem (pseudo code):
> > > >
> > > > 1) user enters an empty string in an input-component: ""
> > > > 2) conversion and validation phase: "" --> setValue(null);
> > > > isLocalValueSet = true; setSubmittedValue(null);
> > > > 3) validation fails in some component on the page --> update model
> > > > phase is skipped
> > > > 4) renderer calls getValue(); --> getValue() evaluates the
> > > > value-binding, as the local-value is 'null', and I get the
> > > > default-value of the bean shown again
> > > >
> > > > proposed solution:
> > > >
> > > > UIInput overwrites getValue of UIOutput:
> > > >
> > > > public Object getValue()
> > > > {
> > > > if (isLocalValueSet()) return _value;
> > > > ValueBinding vb = getValueBinding("value");
> > > > return vb != null ?
(Object)vb.getValue(getFacesContext()) : null;
> > > > }
> > > >
> > > > everyone d'accord?
> > > >
> > > > regards,
> > > >
> > > > Martin
> > > >
> > > > --
> > > >
> > > > http://www.irian.at
> > > >
> > > > Your JSF powerhouse -
> > > > JSF Consulting, Development and
> > > > Courses in English and German
> > > >
> > > > Professional Support for Apache MyFaces
> > > >
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
--
http://www.iria
Re: @PreDestroy, Servlet API,
Hello Dennis,
should i readd the other possible implementation? :-)
But I should write my own TestCases.
I think it should be possible to use the PostConstruct and PreDestroy
Annotations with tomcat 5.5 and facelets. When a InitialContext is
available we should try resource injection, too. But it should be
possible to add a own Provider for a container.
The AnnotationProcessor/InjectionProvider are very similar. I don't like
to define a new myfaces Interface for this use case. I would prefer the
org.apache.AnnotationProcessor because is not tomcat specific and an
apache implementation. Until we find a final solution we should only
copy the code.
It's no problem to use the annotation name instead of using the class.
But personal i prefer the class.
Regards
Bernd
Dennis Byrne wrote:
On 3/3/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
No code in myfaces (or any other apache project) is owned by someone.
That is important for a healthy and moving community. Bernds
submission was a little bit fast but sometimes a complex issue is
better understand if we can look at the code - no matter if that is
the solution we finally have.
I hope you did not get the idea that this was about territory here.
How about this solution:
We define a myfaces specific interface of an
AnnotationProcessor/InjectionProvider which will be used throughout
the code in myfaces. The initialization code lookups an implementation
for that interface. If there is nothing found (through context param,
META-INF/service, etc.) we implement some fallback strategies to
either looking for a InjectionProvider implementation for suns RI or
if that also fails we try to lookup container specific implementations
like tomcats AnnotationProcessor implementation. If all fails we
supply a default implementation which only handles @PostConstruct and
@PreDestroy annotations - I don't think that it is possible to inject
any resource w/o knowing how to lookup these.
This sounds very similar to what Ryan just talked about in his blog.
Bernd,
if are happy w/ this and still interested, feel free to go forward with
this. If you still want to, I ask that the default implementation uses the
annotation name, rather than the annotation. This gives Tomcat
5.5/Facelets
users fewer headaches.
Do either of you have a problem w/ the context listener doing a classpath
search for well known injection providers? I meet a lot of devs who find
JSF too configuration heavy.
Bernd if you don't get around to doing this, I will just end up doing it
sometime next week.
2007/3/3, Bernd Bohmann <[EMAIL PROTECTED]>:
> Sorry,
> I ask you if it's ok to add the code.
> I get no answer then I asume it's ok to add my idea.
>
> It's only a different possible implementation.
> If you don't like it you can remove it.
> Is anything wrong with the code?
>
> Bernd
>
>
>
> Dennis Byrne wrote:
> > Mathias, me and Paul were discussing the future of this feature. For
the
> > most part we were in agreement. I appreciate your input, but it did
not
> > gain traction w/ anyone. You then went ahead and committed a
bunch of
> > code.
> >
> >
> > IMO, you have not been a good team member today Bernd. Please assign
the
> > issue to yourself.
> >
> > Thank you very much for your interest in getting us closer to a
> > 1.2implementation.
> >
> > Dennis Byrne
> >
> > On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
> >>
> >> ??? Yes, I know it.
> >>
> >> Dennis Byrne wrote:
> >> > Are you under the impression that our 1.2 branch didn't already
handle
> >> > @PostConstruct and @PreDestroy? Looks like the left hand doesn't
know
> >> what
> >> > the right hand is doing here.
> >> >
> >> > Dennis Byrne
> >> >
> >> > On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> Just added an implementation of the annotation handling based on
the
> >> >> tomcat implementation.
> >> >>
> >> >> Bernd
> >> >>
> >> >> Dennis Byrne wrote:
> >> >> > I added a comment
> >> >> >
> >> >>
> >>
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023.
> >> >> >
> >> >> > Two more ideas. Ryan mentions applications using facelets, jsf
> >> 1.2and
> >> >> > servlet 2.4. Unless I'm missing something, there's one reason
to
> >> use
> >> >> > annotation.getName().equals("javax.annotation.PostConstruct")
rather
> >> >> than
> >> >> > annotation.class == PostConstruct.class. Also, the tomcat guys
are
> >> >> > processing annotations even when the method is marked private.
> >> >> >
> >> >> > Dennis Byrne
> >> >> >
> >> >> > On 3/3/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
> >> >> >>
> >> >> >> OK, I think the RI also recently added the META-INF/services
> >> >> >> technique. But I don't know how reliable this sun blog entry
is:
> >> >> >> http://tinyurl.com/yrrjs2
> >> >> >>
> >> >> >> Best wishes,
> >> >> >> Paul
> >> >> >>
> >> >> >> On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]>
wrote:
> >> >> >> > The RI uses two ways to lookup the implementation
Re: @PreDestroy, Servlet API,
On 3/3/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
No code in myfaces (or any other apache project) is owned by someone.
That is important for a healthy and moving community. Bernds
submission was a little bit fast but sometimes a complex issue is
better understand if we can look at the code - no matter if that is
the solution we finally have.
I hope you did not get the idea that this was about territory here.
How about this solution:
We define a myfaces specific interface of an
AnnotationProcessor/InjectionProvider which will be used throughout
the code in myfaces. The initialization code lookups an implementation
for that interface. If there is nothing found (through context param,
META-INF/service, etc.) we implement some fallback strategies to
either looking for a InjectionProvider implementation for suns RI or
if that also fails we try to lookup container specific implementations
like tomcats AnnotationProcessor implementation. If all fails we
supply a default implementation which only handles @PostConstruct and
@PreDestroy annotations - I don't think that it is possible to inject
any resource w/o knowing how to lookup these.
This sounds very similar to what Ryan just talked about in his blog. Bernd,
if are happy w/ this and still interested, feel free to go forward with
this. If you still want to, I ask that the default implementation uses the
annotation name, rather than the annotation. This gives Tomcat 5.5/Facelets
users fewer headaches.
Do either of you have a problem w/ the context listener doing a classpath
search for well known injection providers? I meet a lot of devs who find
JSF too configuration heavy.
Bernd if you don't get around to doing this, I will just end up doing it
sometime next week.
2007/3/3, Bernd Bohmann <[EMAIL PROTECTED]>:
> Sorry,
> I ask you if it's ok to add the code.
> I get no answer then I asume it's ok to add my idea.
>
> It's only a different possible implementation.
> If you don't like it you can remove it.
> Is anything wrong with the code?
>
> Bernd
>
>
>
> Dennis Byrne wrote:
> > Mathias, me and Paul were discussing the future of this feature. For
the
> > most part we were in agreement. I appreciate your input, but it did
not
> > gain traction w/ anyone. You then went ahead and committed a bunch of
> > code.
> >
> >
> > IMO, you have not been a good team member today Bernd. Please assign
the
> > issue to yourself.
> >
> > Thank you very much for your interest in getting us closer to a
> > 1.2implementation.
> >
> > Dennis Byrne
> >
> > On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
> >>
> >> ??? Yes, I know it.
> >>
> >> Dennis Byrne wrote:
> >> > Are you under the impression that our 1.2 branch didn't already
handle
> >> > @PostConstruct and @PreDestroy? Looks like the left hand doesn't
know
> >> what
> >> > the right hand is doing here.
> >> >
> >> > Dennis Byrne
> >> >
> >> > On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
> >> >>
> >> >> Just added an implementation of the annotation handling based on
the
> >> >> tomcat implementation.
> >> >>
> >> >> Bernd
> >> >>
> >> >> Dennis Byrne wrote:
> >> >> > I added a comment
> >> >> >
> >> >>
> >>
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023.
> >> >> >
> >> >> > Two more ideas. Ryan mentions applications using facelets, jsf
> >> 1.2and
> >> >> > servlet 2.4. Unless I'm missing something, there's one reason
to
> >> use
> >> >> > annotation.getName().equals("javax.annotation.PostConstruct")
rather
> >> >> than
> >> >> > annotation.class == PostConstruct.class. Also, the tomcat guys
are
> >> >> > processing annotations even when the method is marked private.
> >> >> >
> >> >> > Dennis Byrne
> >> >> >
> >> >> > On 3/3/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
> >> >> >>
> >> >> >> OK, I think the RI also recently added the META-INF/services
> >> >> >> technique. But I don't know how reliable this sun blog entry
is:
> >> >> >> http://tinyurl.com/yrrjs2
> >> >> >>
> >> >> >> Best wishes,
> >> >> >> Paul
> >> >> >>
> >> >> >> On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]>
wrote:
> >> >> >> > The RI uses two ways to lookup the implementation of the
vendor
> >> >> >> > specific implementation of the InjectionProvider. They first
try
> >> to
> >> >> >> > use a web context init param and if that is not configured
they
> >> >> simply
> >> >> >> > use a system property. Both keyed by the class name of the
> >> >> >> > InjectionProvider interface.
> >> >> >> >
> >> >> >> > 2007/3/2, Paul McMahan <[EMAIL PROTECTED]>:
> >> >> >> > > I think Mathias' suggestion is right on. I haven't looked
at
> >> the
> >> >> RI
> >> >> >> > > code but I read somewhere that it passes the name of
> >> >> >> > > InjectionProviders via entries in META-INF/services. If
> >> MyFaces
> >> >> used
> >> >> >> > > a similar approach I think it should work OK for Geronimo
and
> >> just
> >> >> >> > > about any other container that supports injection, And it
> >> should
> >> >
Re: @PreDestroy, Servlet API,
I don't hold anything against you. Ultimately I feel like this is a
lose-lose situation for MyFaces because where things stand now, you are
likely to feel as though your efforts on that branch are not appreciated.
They are.
Ryan has responded ...
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192000
Dennis Byrne
On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
Sorry,
I ask you if it's ok to add the code.
I get no answer then I asume it's ok to add my idea.
It's only a different possible implementation.
If you don't like it you can remove it.
Is anything wrong with the code?
Bernd
Dennis Byrne wrote:
> Mathias, me and Paul were discussing the future of this feature. For
the
> most part we were in agreement. I appreciate your input, but it did not
> gain traction w/ anyone. You then went ahead and committed a bunch of
> code.
>
>
> IMO, you have not been a good team member today Bernd. Please assign
the
> issue to yourself.
>
> Thank you very much for your interest in getting us closer to a
> 1.2implementation.
>
> Dennis Byrne
>
> On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
>>
>> ??? Yes, I know it.
>>
>> Dennis Byrne wrote:
>> > Are you under the impression that our 1.2 branch didn't already
handle
>> > @PostConstruct and @PreDestroy? Looks like the left hand doesn't
know
>> what
>> > the right hand is doing here.
>> >
>> > Dennis Byrne
>> >
>> > On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Just added an implementation of the annotation handling based on the
>> >> tomcat implementation.
>> >>
>> >> Bernd
>> >>
>> >> Dennis Byrne wrote:
>> >> > I added a comment
>> >> >
>> >>
>> http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023.
>> >> >
>> >> > Two more ideas. Ryan mentions applications using facelets, jsf
>> 1.2and
>> >> > servlet 2.4. Unless I'm missing something, there's one reason to
>> use
>> >> > annotation.getName().equals("javax.annotation.PostConstruct")
rather
>> >> than
>> >> > annotation.class == PostConstruct.class. Also, the tomcat guys
are
>> >> > processing annotations even when the method is marked private.
>> >> >
>> >> > Dennis Byrne
>> >> >
>> >> > On 3/3/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >> OK, I think the RI also recently added the META-INF/services
>> >> >> technique. But I don't know how reliable this sun blog entry is:
>> >> >> http://tinyurl.com/yrrjs2
>> >> >>
>> >> >> Best wishes,
>> >> >> Paul
>> >> >>
>> >> >> On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]>
wrote:
>> >> >> > The RI uses two ways to lookup the implementation of the vendor
>> >> >> > specific implementation of the InjectionProvider. They first
try
>> to
>> >> >> > use a web context init param and if that is not configured they
>> >> simply
>> >> >> > use a system property. Both keyed by the class name of the
>> >> >> > InjectionProvider interface.
>> >> >> >
>> >> >> > 2007/3/2, Paul McMahan <[EMAIL PROTECTED]>:
>> >> >> > > I think Mathias' suggestion is right on. I haven't looked at
>> the
>> >> RI
>> >> >> > > code but I read somewhere that it passes the name of
>> >> >> > > InjectionProviders via entries in META-INF/services. If
>> MyFaces
>> >> used
>> >> >> > > a similar approach I think it should work OK for Geronimo and
>> just
>> >> >> > > about any other container that supports injection, And it
>> should
>> >> >> also
>> >> >> > > make MyFaces more interchangeable with the RI.
>> >> >> > >
>> >> >> > > Best wishes,
>> >> >> > > Paul
>> >> >> > >
>> >> >> > > On 3/2/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
>> >> >> > > > Similar to what Mathias mentioned?
>> >> >> > > >
>> >> >> > > >
>> >> http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
>> >> >> > > >
>> >> >> > > > It's not much work (on our side) but it sounds pretty
vendor
>> >> >> specific.
>> >> >> > > > Again, I don't have a better solution. Mathias writes
"which
>> is
>> >> >> implemented
>> >> >> > > > by j2ee containers". I wonder if each container will end
up
>> >> >> looking
>> >> >> for
>> >> >> > > > different interfaces. How would MyFaces find Geronimo's
>> >> >> implementation ? A
>> >> >> > > > context parameter? A for loop like this ...
>> >> >> > > >
>> >> >> > > > String[] providers = new
>> >> String[]{"org,apache.geronimo.DIProvider
>> >> ",
>> >> >> > > > "com.bea.DIProvider", "org.jboss.DIProvider"}
>> >> >> > > >
>> >> >> > > > for(String clazz : providers){
>> >> >> > > > try{
>> >> >> > > > return ClassUtils.load (clazz)
>> >> >> > > > }catch(){}
>> >> >> > > > }
>> >> >> > > >
>> >> >> > > > Dennis Byrne
>> >> >> > > >
>> >> >> > > >
>> >> >> > > > On 3/1/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
>> >> >> > > > > OK, I think your interpretation of the spec makes sense
and
>> >> >> there's
>> >> >> > > > > one particular aspect we should discuss a little further.
>> >> >> > > > >
>> >> >> > > > > The container doesn't know which classes are managed
beans
>> so
>> >> it
>
Re: @PreDestroy, Servlet API,
No code in myfaces (or any other apache project) is owned by someone.
That is important for a healthy and moving community. Bernds
submission was a little bit fast but sometimes a complex issue is
better understand if we can look at the code - no matter if that is
the solution we finally have.
I wasn't aware that tomcat already has something like an
AnnotationProcessor which defines exactly that kind of
InjectionProvider which the RI uses. But it perfectly matches our
requirements.
How about this solution:
We define a myfaces specific interface of an
AnnotationProcessor/InjectionProvider which will be used throughout
the code in myfaces. The initialization code lookups an implementation
for that interface. If there is nothing found (through context param,
META-INF/service, etc.) we implement some fallback strategies to
either looking for a InjectionProvider implementation for suns RI or
if that also fails we try to lookup container specific implementations
like tomcats AnnotationProcessor implementation. If all fails we
supply a default implementation which only handles @PostConstruct and
@PreDestroy annotations - I don't think that it is possible to inject
any resource w/o knowing how to lookup these.
2007/3/3, Bernd Bohmann <[EMAIL PROTECTED]>:
Sorry,
I ask you if it's ok to add the code.
I get no answer then I asume it's ok to add my idea.
It's only a different possible implementation.
If you don't like it you can remove it.
Is anything wrong with the code?
Bernd
Dennis Byrne wrote:
> Mathias, me and Paul were discussing the future of this feature. For the
> most part we were in agreement. I appreciate your input, but it did not
> gain traction w/ anyone. You then went ahead and committed a bunch of
> code.
>
>
> IMO, you have not been a good team member today Bernd. Please assign the
> issue to yourself.
>
> Thank you very much for your interest in getting us closer to a
> 1.2implementation.
>
> Dennis Byrne
>
> On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
>>
>> ??? Yes, I know it.
>>
>> Dennis Byrne wrote:
>> > Are you under the impression that our 1.2 branch didn't already handle
>> > @PostConstruct and @PreDestroy? Looks like the left hand doesn't know
>> what
>> > the right hand is doing here.
>> >
>> > Dennis Byrne
>> >
>> > On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
>> >>
>> >> Just added an implementation of the annotation handling based on the
>> >> tomcat implementation.
>> >>
>> >> Bernd
>> >>
>> >> Dennis Byrne wrote:
>> >> > I added a comment
>> >> >
>> >>
>> http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023.
>> >> >
>> >> > Two more ideas. Ryan mentions applications using facelets, jsf
>> 1.2and
>> >> > servlet 2.4. Unless I'm missing something, there's one reason to
>> use
>> >> > annotation.getName().equals("javax.annotation.PostConstruct") rather
>> >> than
>> >> > annotation.class == PostConstruct.class. Also, the tomcat guys are
>> >> > processing annotations even when the method is marked private.
>> >> >
>> >> > Dennis Byrne
>> >> >
>> >> > On 3/3/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
>> >> >>
>> >> >> OK, I think the RI also recently added the META-INF/services
>> >> >> technique. But I don't know how reliable this sun blog entry is:
>> >> >> http://tinyurl.com/yrrjs2
>> >> >>
>> >> >> Best wishes,
>> >> >> Paul
>> >> >>
>> >> >> On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
>> >> >> > The RI uses two ways to lookup the implementation of the vendor
>> >> >> > specific implementation of the InjectionProvider. They first try
>> to
>> >> >> > use a web context init param and if that is not configured they
>> >> simply
>> >> >> > use a system property. Both keyed by the class name of the
>> >> >> > InjectionProvider interface.
>> >> >> >
>> >> >> > 2007/3/2, Paul McMahan <[EMAIL PROTECTED]>:
>> >> >> > > I think Mathias' suggestion is right on. I haven't looked at
>> the
>> >> RI
>> >> >> > > code but I read somewhere that it passes the name of
>> >> >> > > InjectionProviders via entries in META-INF/services. If
>> MyFaces
>> >> used
>> >> >> > > a similar approach I think it should work OK for Geronimo and
>> just
>> >> >> > > about any other container that supports injection, And it
>> should
>> >> >> also
>> >> >> > > make MyFaces more interchangeable with the RI.
>> >> >> > >
>> >> >> > > Best wishes,
>> >> >> > > Paul
>> >> >> > >
>> >> >> > > On 3/2/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
>> >> >> > > > Similar to what Mathias mentioned?
>> >> >> > > >
>> >> >> > > >
>> >> http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
>> >> >> > > >
>> >> >> > > > It's not much work (on our side) but it sounds pretty vendor
>> >> >> specific.
>> >> >> > > > Again, I don't have a better solution. Mathias writes "which
>> is
>> >> >> implemented
>> >> >> > > > by j2ee containers". I wonder if each container will end up
>> >> >> looking
>> >> >> for
>> >> >> > > > different interfaces. How wo
Re: @PreDestroy, Servlet API,
Just revert my commit
Dennis Byrne wrote:
Mathias, me and Paul were discussing the future of this feature. For the
most part we were in agreement. I appreciate your input, but it did not
gain traction w/ anyone. You then went ahead and committed a bunch of
code.
IMO, you have not been a good team member today Bernd. Please assign the
issue to yourself.
Thank you very much for your interest in getting us closer to a
1.2implementation.
Dennis Byrne
On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
??? Yes, I know it.
Dennis Byrne wrote:
> Are you under the impression that our 1.2 branch didn't already handle
> @PostConstruct and @PreDestroy? Looks like the left hand doesn't know
what
> the right hand is doing here.
>
> Dennis Byrne
>
> On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
>>
>> Just added an implementation of the annotation handling based on the
>> tomcat implementation.
>>
>> Bernd
>>
>> Dennis Byrne wrote:
>> > I added a comment
>> >
>>
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023.
>> >
>> > Two more ideas. Ryan mentions applications using facelets, jsf
1.2and
>> > servlet 2.4. Unless I'm missing something, there's one reason to
use
>> > annotation.getName().equals("javax.annotation.PostConstruct") rather
>> than
>> > annotation.class == PostConstruct.class. Also, the tomcat guys are
>> > processing annotations even when the method is marked private.
>> >
>> > Dennis Byrne
>> >
>> > On 3/3/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
>> >>
>> >> OK, I think the RI also recently added the META-INF/services
>> >> technique. But I don't know how reliable this sun blog entry is:
>> >> http://tinyurl.com/yrrjs2
>> >>
>> >> Best wishes,
>> >> Paul
>> >>
>> >> On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
>> >> > The RI uses two ways to lookup the implementation of the vendor
>> >> > specific implementation of the InjectionProvider. They first try
to
>> >> > use a web context init param and if that is not configured they
>> simply
>> >> > use a system property. Both keyed by the class name of the
>> >> > InjectionProvider interface.
>> >> >
>> >> > 2007/3/2, Paul McMahan <[EMAIL PROTECTED]>:
>> >> > > I think Mathias' suggestion is right on. I haven't looked at
the
>> RI
>> >> > > code but I read somewhere that it passes the name of
>> >> > > InjectionProviders via entries in META-INF/services. If
MyFaces
>> used
>> >> > > a similar approach I think it should work OK for Geronimo and
just
>> >> > > about any other container that supports injection, And it
should
>> >> also
>> >> > > make MyFaces more interchangeable with the RI.
>> >> > >
>> >> > > Best wishes,
>> >> > > Paul
>> >> > >
>> >> > > On 3/2/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
>> >> > > > Similar to what Mathias mentioned?
>> >> > > >
>> >> > > >
>> http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
>> >> > > >
>> >> > > > It's not much work (on our side) but it sounds pretty vendor
>> >> specific.
>> >> > > > Again, I don't have a better solution. Mathias writes "which
is
>> >> implemented
>> >> > > > by j2ee containers". I wonder if each container will end up
>> >> looking
>> >> for
>> >> > > > different interfaces. How would MyFaces find Geronimo's
>> >> implementation ? A
>> >> > > > context parameter? A for loop like this ...
>> >> > > >
>> >> > > > String[] providers = new
>> String[]{"org,apache.geronimo.DIProvider
>> ",
>> >> > > > "com.bea.DIProvider", "org.jboss.DIProvider"}
>> >> > > >
>> >> > > > for(String clazz : providers){
>> >> > > > try{
>> >> > > > return ClassUtils.load (clazz)
>> >> > > > }catch(){}
>> >> > > > }
>> >> > > >
>> >> > > > Dennis Byrne
>> >> > > >
>> >> > > >
>> >> > > > On 3/1/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
>> >> > > > > OK, I think your interpretation of the spec makes sense and
>> >> there's
>> >> > > > > one particular aspect we should discuss a little further.
>> >> > > > >
>> >> > > > > The container doesn't know which classes are managed beans
so
>> it
>> >> > > > > wouldn't know when to intercept the instantiation
process to
>> >> perform
>> >> > > > > injection. What would you all think about MyFaces
>> providing an
>> >> > > > > interface that containers could implement to perform
injection
>> on
>> >> a
>> >> > > > > managed bean when MyFaces brings that bean into
service? This
>> >> would
>> >> > > > > allow MyFaces to maintain control of the timing while
allowing
>> >> the
>> >> > > > > container to scan for annotations and handle injection when
>> >> prompted
>> >> > > > > to do so.
>> >> > > > >
>> >> > > > > Best wishes,
>> >> > > > > Paul
>> >> > > > >
>> >> > > > >
>> >> > > > > On 2/26/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
>> >> > > > > > I know the specs can be vague sometimes, but I don't
>> interpret
>> >> the first
>> >> > > > > > paragraph of section 5.4 as meaning the JSF
>> implementation is
>> >> > > > responsible
>> >> > > > > > for @EJB, @Resou
Re: @PreDestroy, Servlet API,
Sorry,
I ask you if it's ok to add the code.
I get no answer then I asume it's ok to add my idea.
It's only a different possible implementation.
If you don't like it you can remove it.
Is anything wrong with the code?
Bernd
Dennis Byrne wrote:
Mathias, me and Paul were discussing the future of this feature. For the
most part we were in agreement. I appreciate your input, but it did not
gain traction w/ anyone. You then went ahead and committed a bunch of
code.
IMO, you have not been a good team member today Bernd. Please assign the
issue to yourself.
Thank you very much for your interest in getting us closer to a
1.2implementation.
Dennis Byrne
On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
??? Yes, I know it.
Dennis Byrne wrote:
> Are you under the impression that our 1.2 branch didn't already handle
> @PostConstruct and @PreDestroy? Looks like the left hand doesn't know
what
> the right hand is doing here.
>
> Dennis Byrne
>
> On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
>>
>> Just added an implementation of the annotation handling based on the
>> tomcat implementation.
>>
>> Bernd
>>
>> Dennis Byrne wrote:
>> > I added a comment
>> >
>>
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023.
>> >
>> > Two more ideas. Ryan mentions applications using facelets, jsf
1.2and
>> > servlet 2.4. Unless I'm missing something, there's one reason to
use
>> > annotation.getName().equals("javax.annotation.PostConstruct") rather
>> than
>> > annotation.class == PostConstruct.class. Also, the tomcat guys are
>> > processing annotations even when the method is marked private.
>> >
>> > Dennis Byrne
>> >
>> > On 3/3/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
>> >>
>> >> OK, I think the RI also recently added the META-INF/services
>> >> technique. But I don't know how reliable this sun blog entry is:
>> >> http://tinyurl.com/yrrjs2
>> >>
>> >> Best wishes,
>> >> Paul
>> >>
>> >> On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
>> >> > The RI uses two ways to lookup the implementation of the vendor
>> >> > specific implementation of the InjectionProvider. They first try
to
>> >> > use a web context init param and if that is not configured they
>> simply
>> >> > use a system property. Both keyed by the class name of the
>> >> > InjectionProvider interface.
>> >> >
>> >> > 2007/3/2, Paul McMahan <[EMAIL PROTECTED]>:
>> >> > > I think Mathias' suggestion is right on. I haven't looked at
the
>> RI
>> >> > > code but I read somewhere that it passes the name of
>> >> > > InjectionProviders via entries in META-INF/services. If
MyFaces
>> used
>> >> > > a similar approach I think it should work OK for Geronimo and
just
>> >> > > about any other container that supports injection, And it
should
>> >> also
>> >> > > make MyFaces more interchangeable with the RI.
>> >> > >
>> >> > > Best wishes,
>> >> > > Paul
>> >> > >
>> >> > > On 3/2/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
>> >> > > > Similar to what Mathias mentioned?
>> >> > > >
>> >> > > >
>> http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
>> >> > > >
>> >> > > > It's not much work (on our side) but it sounds pretty vendor
>> >> specific.
>> >> > > > Again, I don't have a better solution. Mathias writes "which
is
>> >> implemented
>> >> > > > by j2ee containers". I wonder if each container will end up
>> >> looking
>> >> for
>> >> > > > different interfaces. How would MyFaces find Geronimo's
>> >> implementation ? A
>> >> > > > context parameter? A for loop like this ...
>> >> > > >
>> >> > > > String[] providers = new
>> String[]{"org,apache.geronimo.DIProvider
>> ",
>> >> > > > "com.bea.DIProvider", "org.jboss.DIProvider"}
>> >> > > >
>> >> > > > for(String clazz : providers){
>> >> > > > try{
>> >> > > > return ClassUtils.load (clazz)
>> >> > > > }catch(){}
>> >> > > > }
>> >> > > >
>> >> > > > Dennis Byrne
>> >> > > >
>> >> > > >
>> >> > > > On 3/1/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
>> >> > > > > OK, I think your interpretation of the spec makes sense and
>> >> there's
>> >> > > > > one particular aspect we should discuss a little further.
>> >> > > > >
>> >> > > > > The container doesn't know which classes are managed beans
so
>> it
>> >> > > > > wouldn't know when to intercept the instantiation
process to
>> >> perform
>> >> > > > > injection. What would you all think about MyFaces
>> providing an
>> >> > > > > interface that containers could implement to perform
injection
>> on
>> >> a
>> >> > > > > managed bean when MyFaces brings that bean into
service? This
>> >> would
>> >> > > > > allow MyFaces to maintain control of the timing while
allowing
>> >> the
>> >> > > > > container to scan for annotations and handle injection when
>> >> prompted
>> >> > > > > to do so.
>> >> > > > >
>> >> > > > > Best wishes,
>> >> > > > > Paul
>> >> > > > >
>> >> > > > >
>> >> > > > > On 2/26/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
>> >> > > > > > I know the sp
Re: @PreDestroy, Servlet API,
Mathias, me and Paul were discussing the future of this feature. For the
most part we were in agreement. I appreciate your input, but it did not
gain traction w/ anyone. You then went ahead and committed a bunch of code.
IMO, you have not been a good team member today Bernd. Please assign the
issue to yourself.
Thank you very much for your interest in getting us closer to a
1.2implementation.
Dennis Byrne
On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
??? Yes, I know it.
Dennis Byrne wrote:
> Are you under the impression that our 1.2 branch didn't already handle
> @PostConstruct and @PreDestroy? Looks like the left hand doesn't know
what
> the right hand is doing here.
>
> Dennis Byrne
>
> On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
>>
>> Just added an implementation of the annotation handling based on the
>> tomcat implementation.
>>
>> Bernd
>>
>> Dennis Byrne wrote:
>> > I added a comment
>> >
>> http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023.
>> >
>> > Two more ideas. Ryan mentions applications using facelets, jsf 1.2and
>> > servlet 2.4. Unless I'm missing something, there's one reason to use
>> > annotation.getName().equals("javax.annotation.PostConstruct") rather
>> than
>> > annotation.class == PostConstruct.class. Also, the tomcat guys are
>> > processing annotations even when the method is marked private.
>> >
>> > Dennis Byrne
>> >
>> > On 3/3/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
>> >>
>> >> OK, I think the RI also recently added the META-INF/services
>> >> technique. But I don't know how reliable this sun blog entry is:
>> >> http://tinyurl.com/yrrjs2
>> >>
>> >> Best wishes,
>> >> Paul
>> >>
>> >> On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
>> >> > The RI uses two ways to lookup the implementation of the vendor
>> >> > specific implementation of the InjectionProvider. They first try
to
>> >> > use a web context init param and if that is not configured they
>> simply
>> >> > use a system property. Both keyed by the class name of the
>> >> > InjectionProvider interface.
>> >> >
>> >> > 2007/3/2, Paul McMahan <[EMAIL PROTECTED]>:
>> >> > > I think Mathias' suggestion is right on. I haven't looked at
the
>> RI
>> >> > > code but I read somewhere that it passes the name of
>> >> > > InjectionProviders via entries in META-INF/services. If MyFaces
>> used
>> >> > > a similar approach I think it should work OK for Geronimo and
just
>> >> > > about any other container that supports injection, And it
should
>> >> also
>> >> > > make MyFaces more interchangeable with the RI.
>> >> > >
>> >> > > Best wishes,
>> >> > > Paul
>> >> > >
>> >> > > On 3/2/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
>> >> > > > Similar to what Mathias mentioned?
>> >> > > >
>> >> > > >
>> http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
>> >> > > >
>> >> > > > It's not much work (on our side) but it sounds pretty vendor
>> >> specific.
>> >> > > > Again, I don't have a better solution. Mathias writes "which
is
>> >> implemented
>> >> > > > by j2ee containers". I wonder if each container will end up
>> >> looking
>> >> for
>> >> > > > different interfaces. How would MyFaces find Geronimo's
>> >> implementation ? A
>> >> > > > context parameter? A for loop like this ...
>> >> > > >
>> >> > > > String[] providers = new
>> String[]{"org,apache.geronimo.DIProvider
>> ",
>> >> > > > "com.bea.DIProvider", "org.jboss.DIProvider"}
>> >> > > >
>> >> > > > for(String clazz : providers){
>> >> > > > try{
>> >> > > > return ClassUtils.load (clazz)
>> >> > > > }catch(){}
>> >> > > > }
>> >> > > >
>> >> > > > Dennis Byrne
>> >> > > >
>> >> > > >
>> >> > > > On 3/1/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
>> >> > > > > OK, I think your interpretation of the spec makes sense and
>> >> there's
>> >> > > > > one particular aspect we should discuss a little further.
>> >> > > > >
>> >> > > > > The container doesn't know which classes are managed beans
so
>> it
>> >> > > > > wouldn't know when to intercept the instantiation process to
>> >> perform
>> >> > > > > injection. What would you all think about MyFaces
>> providing an
>> >> > > > > interface that containers could implement to perform
injection
>> on
>> >> a
>> >> > > > > managed bean when MyFaces brings that bean into
service? This
>> >> would
>> >> > > > > allow MyFaces to maintain control of the timing while
allowing
>> >> the
>> >> > > > > container to scan for annotations and handle injection when
>> >> prompted
>> >> > > > > to do so.
>> >> > > > >
>> >> > > > > Best wishes,
>> >> > > > > Paul
>> >> > > > >
>> >> > > > >
>> >> > > > > On 2/26/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
>> >> > > > > > I know the specs can be vague sometimes, but I don't
>> interpret
>> >> the first
>> >> > > > > > paragraph of section 5.4 as meaning the JSF
>> implementation is
>> >> > > > responsible
>> >> > > > > > for @EJB, @Resources, etc. The JSF spec specifically
>> mentions
>> >>
Re: @PreDestroy, Servlet API,
??? Yes, I know it.
Dennis Byrne wrote:
Are you under the impression that our 1.2 branch didn't already handle
@PostConstruct and @PreDestroy? Looks like the left hand doesn't know what
the right hand is doing here.
Dennis Byrne
On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
Just added an implementation of the annotation handling based on the
tomcat implementation.
Bernd
Dennis Byrne wrote:
> I added a comment
>
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023 .
>
> Two more ideas. Ryan mentions applications using facelets, jsf 1.2 and
> servlet 2.4. Unless I'm missing something, there's one reason to use
> annotation.getName().equals("javax.annotation.PostConstruct") rather
than
> annotation.class == PostConstruct.class. Also, the tomcat guys are
> processing annotations even when the method is marked private.
>
> Dennis Byrne
>
> On 3/3/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
>>
>> OK, I think the RI also recently added the META-INF/services
>> technique. But I don't know how reliable this sun blog entry is:
>> http://tinyurl.com/yrrjs2
>>
>> Best wishes,
>> Paul
>>
>> On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
>> > The RI uses two ways to lookup the implementation of the vendor
>> > specific implementation of the InjectionProvider. They first try to
>> > use a web context init param and if that is not configured they
simply
>> > use a system property. Both keyed by the class name of the
>> > InjectionProvider interface.
>> >
>> > 2007/3/2, Paul McMahan <[EMAIL PROTECTED]>:
>> > > I think Mathias' suggestion is right on. I haven't looked at the
RI
>> > > code but I read somewhere that it passes the name of
>> > > InjectionProviders via entries in META-INF/services. If MyFaces
used
>> > > a similar approach I think it should work OK for Geronimo and just
>> > > about any other container that supports injection, And it should
>> also
>> > > make MyFaces more interchangeable with the RI.
>> > >
>> > > Best wishes,
>> > > Paul
>> > >
>> > > On 3/2/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
>> > > > Similar to what Mathias mentioned?
>> > > >
>> > > >
http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
>> > > >
>> > > > It's not much work (on our side) but it sounds pretty vendor
>> specific.
>> > > > Again, I don't have a better solution. Mathias writes "which is
>> implemented
>> > > > by j2ee containers". I wonder if each container will end up
>> looking
>> for
>> > > > different interfaces. How would MyFaces find Geronimo's
>> implementation ? A
>> > > > context parameter? A for loop like this ...
>> > > >
>> > > > String[] providers = new
String[]{"org,apache.geronimo.DIProvider
",
>> > > > "com.bea.DIProvider", "org.jboss.DIProvider"}
>> > > >
>> > > > for(String clazz : providers){
>> > > > try{
>> > > > return ClassUtils.load (clazz)
>> > > > }catch(){}
>> > > > }
>> > > >
>> > > > Dennis Byrne
>> > > >
>> > > >
>> > > > On 3/1/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
>> > > > > OK, I think your interpretation of the spec makes sense and
>> there's
>> > > > > one particular aspect we should discuss a little further.
>> > > > >
>> > > > > The container doesn't know which classes are managed beans so
it
>> > > > > wouldn't know when to intercept the instantiation process to
>> perform
>> > > > > injection. What would you all think about MyFaces
providing an
>> > > > > interface that containers could implement to perform injection
on
>> a
>> > > > > managed bean when MyFaces brings that bean into service? This
>> would
>> > > > > allow MyFaces to maintain control of the timing while allowing
>> the
>> > > > > container to scan for annotations and handle injection when
>> prompted
>> > > > > to do so.
>> > > > >
>> > > > > Best wishes,
>> > > > > Paul
>> > > > >
>> > > > >
>> > > > > On 2/26/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
>> > > > > > I know the specs can be vague sometimes, but I don't
interpret
>> the first
>> > > > > > paragraph of section 5.4 as meaning the JSF
implementation is
>> > > > responsible
>> > > > > > for @EJB, @Resources, etc. The JSF spec specifically
mentions
>> "the
>> > > > > > container to inject references". If Geronimo can intercept
the
>> > > > > > instantiation of these classes in the classloader (something
I
>> know
>> > > > nothing
>> > > > > > about right now), I think we are all good here. Wouldn't
>> MyFaces then
>> > > > be
>> > > > > > observing the requirements (in plain java) around
>> @PostConstruct
>> after
>> > > > > > Geronimo had injected the resources?
>> > > > > >
>> > > > > > I think the JSF impl is only responsible for @PostConstruct
and
>> > > > @Predestroy.
>> > > > > > This makes sense because scoped (request, session,
>> application)
>> are the
>> > > > > > only candidates for this, and it would be more awkward to do
>> that from
>> > > > the
>> > > > > > container. I say all of this in an open manner, so anyone
feel
>> free to
>> > >
Re: @PreDestroy, Servlet API,
Are you under the impression that our 1.2 branch didn't already handle
@PostConstruct and @PreDestroy? Looks like the left hand doesn't know what
the right hand is doing here.
Dennis Byrne
On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
Just added an implementation of the annotation handling based on the
tomcat implementation.
Bernd
Dennis Byrne wrote:
> I added a comment
> http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023 .
>
> Two more ideas. Ryan mentions applications using facelets, jsf 1.2 and
> servlet 2.4. Unless I'm missing something, there's one reason to use
> annotation.getName().equals("javax.annotation.PostConstruct") rather
than
> annotation.class == PostConstruct.class. Also, the tomcat guys are
> processing annotations even when the method is marked private.
>
> Dennis Byrne
>
> On 3/3/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
>>
>> OK, I think the RI also recently added the META-INF/services
>> technique. But I don't know how reliable this sun blog entry is:
>> http://tinyurl.com/yrrjs2
>>
>> Best wishes,
>> Paul
>>
>> On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
>> > The RI uses two ways to lookup the implementation of the vendor
>> > specific implementation of the InjectionProvider. They first try to
>> > use a web context init param and if that is not configured they
simply
>> > use a system property. Both keyed by the class name of the
>> > InjectionProvider interface.
>> >
>> > 2007/3/2, Paul McMahan <[EMAIL PROTECTED]>:
>> > > I think Mathias' suggestion is right on. I haven't looked at the
RI
>> > > code but I read somewhere that it passes the name of
>> > > InjectionProviders via entries in META-INF/services. If MyFaces
used
>> > > a similar approach I think it should work OK for Geronimo and just
>> > > about any other container that supports injection, And it should
>> also
>> > > make MyFaces more interchangeable with the RI.
>> > >
>> > > Best wishes,
>> > > Paul
>> > >
>> > > On 3/2/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
>> > > > Similar to what Mathias mentioned?
>> > > >
>> > > > http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
>> > > >
>> > > > It's not much work (on our side) but it sounds pretty vendor
>> specific.
>> > > > Again, I don't have a better solution. Mathias writes "which is
>> implemented
>> > > > by j2ee containers". I wonder if each container will end up
>> looking
>> for
>> > > > different interfaces. How would MyFaces find Geronimo's
>> implementation ? A
>> > > > context parameter? A for loop like this ...
>> > > >
>> > > > String[] providers = new String[]{"org,apache.geronimo.DIProvider
",
>> > > > "com.bea.DIProvider", "org.jboss.DIProvider"}
>> > > >
>> > > > for(String clazz : providers){
>> > > > try{
>> > > > return ClassUtils.load (clazz)
>> > > > }catch(){}
>> > > > }
>> > > >
>> > > > Dennis Byrne
>> > > >
>> > > >
>> > > > On 3/1/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
>> > > > > OK, I think your interpretation of the spec makes sense and
>> there's
>> > > > > one particular aspect we should discuss a little further.
>> > > > >
>> > > > > The container doesn't know which classes are managed beans so
it
>> > > > > wouldn't know when to intercept the instantiation process to
>> perform
>> > > > > injection. What would you all think about MyFaces providing an
>> > > > > interface that containers could implement to perform injection
on
>> a
>> > > > > managed bean when MyFaces brings that bean into service? This
>> would
>> > > > > allow MyFaces to maintain control of the timing while allowing
>> the
>> > > > > container to scan for annotations and handle injection when
>> prompted
>> > > > > to do so.
>> > > > >
>> > > > > Best wishes,
>> > > > > Paul
>> > > > >
>> > > > >
>> > > > > On 2/26/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
>> > > > > > I know the specs can be vague sometimes, but I don't
interpret
>> the first
>> > > > > > paragraph of section 5.4 as meaning the JSF implementation is
>> > > > responsible
>> > > > > > for @EJB, @Resources, etc. The JSF spec specifically
mentions
>> "the
>> > > > > > container to inject references". If Geronimo can intercept
the
>> > > > > > instantiation of these classes in the classloader (something
I
>> know
>> > > > nothing
>> > > > > > about right now), I think we are all good here. Wouldn't
>> MyFaces then
>> > > > be
>> > > > > > observing the requirements (in plain java) around
>> @PostConstruct
>> after
>> > > > > > Geronimo had injected the resources?
>> > > > > >
>> > > > > > I think the JSF impl is only responsible for @PostConstruct
and
>> > > > @Predestroy.
>> > > > > > This makes sense because scoped (request, session,
>> application)
>> are the
>> > > > > > only candidates for this, and it would be more awkward to do
>> that from
>> > > > the
>> > > > > > container. I say all of this in an open manner, so anyone
feel
>> free to
>> > > > > > discuss.
>> > > > > >
>> > > > > > You're poin
Re: @PreDestroy, Servlet API,
Just added an implementation of the annotation handling based on the
tomcat implementation.
Bernd
Dennis Byrne wrote:
I added a comment
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023 .
Two more ideas. Ryan mentions applications using facelets, jsf 1.2 and
servlet 2.4. Unless I'm missing something, there's one reason to use
annotation.getName().equals("javax.annotation.PostConstruct") rather than
annotation.class == PostConstruct.class. Also, the tomcat guys are
processing annotations even when the method is marked private.
Dennis Byrne
On 3/3/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
OK, I think the RI also recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
> The RI uses two ways to lookup the implementation of the vendor
> specific implementation of the InjectionProvider. They first try to
> use a web context init param and if that is not configured they simply
> use a system property. Both keyed by the class name of the
> InjectionProvider interface.
>
> 2007/3/2, Paul McMahan <[EMAIL PROTECTED]>:
> > I think Mathias' suggestion is right on. I haven't looked at the RI
> > code but I read somewhere that it passes the name of
> > InjectionProviders via entries in META-INF/services. If MyFaces used
> > a similar approach I think it should work OK for Geronimo and just
> > about any other container that supports injection, And it should
also
> > make MyFaces more interchangeable with the RI.
> >
> > Best wishes,
> > Paul
> >
> > On 3/2/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
> > > Similar to what Mathias mentioned?
> > >
> > > http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
> > >
> > > It's not much work (on our side) but it sounds pretty vendor
specific.
> > > Again, I don't have a better solution. Mathias writes "which is
implemented
> > > by j2ee containers". I wonder if each container will end up
looking
for
> > > different interfaces. How would MyFaces find Geronimo's
implementation ? A
> > > context parameter? A for loop like this ...
> > >
> > > String[] providers = new String[]{"org,apache.geronimo.DIProvider",
> > > "com.bea.DIProvider", "org.jboss.DIProvider"}
> > >
> > > for(String clazz : providers){
> > > try{
> > > return ClassUtils.load (clazz)
> > > }catch(){}
> > > }
> > >
> > > Dennis Byrne
> > >
> > >
> > > On 3/1/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
> > > > OK, I think your interpretation of the spec makes sense and
there's
> > > > one particular aspect we should discuss a little further.
> > > >
> > > > The container doesn't know which classes are managed beans so it
> > > > wouldn't know when to intercept the instantiation process to
perform
> > > > injection. What would you all think about MyFaces providing an
> > > > interface that containers could implement to perform injection on
a
> > > > managed bean when MyFaces brings that bean into service? This
would
> > > > allow MyFaces to maintain control of the timing while allowing
the
> > > > container to scan for annotations and handle injection when
prompted
> > > > to do so.
> > > >
> > > > Best wishes,
> > > > Paul
> > > >
> > > >
> > > > On 2/26/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
> > > > > I know the specs can be vague sometimes, but I don't interpret
the first
> > > > > paragraph of section 5.4 as meaning the JSF implementation is
> > > responsible
> > > > > for @EJB, @Resources, etc. The JSF spec specifically mentions
"the
> > > > > container to inject references". If Geronimo can intercept the
> > > > > instantiation of these classes in the classloader (something I
know
> > > nothing
> > > > > about right now), I think we are all good here. Wouldn't
MyFaces then
> > > be
> > > > > observing the requirements (in plain java) around
@PostConstruct
after
> > > > > Geronimo had injected the resources?
> > > > >
> > > > > I think the JSF impl is only responsible for @PostConstruct and
> > > @Predestroy.
> > > > > This makes sense because scoped (request, session,
application)
are the
> > > > > only candidates for this, and it would be more awkward to do
that from
> > > the
> > > > > container. I say all of this in an open manner, so anyone feel
free to
> > > > > discuss.
> > > > >
> > > > > You're point about javax.annotation being in the Servlet 2.5 is
taken.
> > > I
> > > > > totally missed that.
> > > > >
> > > > >
> > > > > Dennis Byrne
> > > > >
> > > > > On 2/26/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
> > > > > > Actually by "dependency injection" I'm specifically referring
to the
> > > > > > portion of the JSF spec that discusses injecting resources
where
> > > > > > certain annotations are found in a managed bean. So, while
scanning
> > > > > > for the @PreConstruct and @PostDestroy annotations MyFaces
would also
> > > > > > scan for @EJB, @Resource, @WebServi
Re: @PreDestroy, Servlet API,
I added a comment
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023 .
Two more ideas. Ryan mentions applications using facelets, jsf 1.2 and
servlet 2.4. Unless I'm missing something, there's one reason to use
annotation.getName().equals("javax.annotation.PostConstruct") rather than
annotation.class == PostConstruct.class. Also, the tomcat guys are
processing annotations even when the method is marked private.
Dennis Byrne
On 3/3/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
OK, I think the RI also recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
> The RI uses two ways to lookup the implementation of the vendor
> specific implementation of the InjectionProvider. They first try to
> use a web context init param and if that is not configured they simply
> use a system property. Both keyed by the class name of the
> InjectionProvider interface.
>
> 2007/3/2, Paul McMahan <[EMAIL PROTECTED]>:
> > I think Mathias' suggestion is right on. I haven't looked at the RI
> > code but I read somewhere that it passes the name of
> > InjectionProviders via entries in META-INF/services. If MyFaces used
> > a similar approach I think it should work OK for Geronimo and just
> > about any other container that supports injection, And it should also
> > make MyFaces more interchangeable with the RI.
> >
> > Best wishes,
> > Paul
> >
> > On 3/2/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
> > > Similar to what Mathias mentioned?
> > >
> > > http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
> > >
> > > It's not much work (on our side) but it sounds pretty vendor
specific.
> > > Again, I don't have a better solution. Mathias writes "which is
implemented
> > > by j2ee containers". I wonder if each container will end up looking
for
> > > different interfaces. How would MyFaces find Geronimo's
implementation ? A
> > > context parameter? A for loop like this ...
> > >
> > > String[] providers = new String[]{"org,apache.geronimo.DIProvider",
> > > "com.bea.DIProvider", "org.jboss.DIProvider"}
> > >
> > > for(String clazz : providers){
> > > try{
> > > return ClassUtils.load (clazz)
> > > }catch(){}
> > > }
> > >
> > > Dennis Byrne
> > >
> > >
> > > On 3/1/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
> > > > OK, I think your interpretation of the spec makes sense and
there's
> > > > one particular aspect we should discuss a little further.
> > > >
> > > > The container doesn't know which classes are managed beans so it
> > > > wouldn't know when to intercept the instantiation process to
perform
> > > > injection. What would you all think about MyFaces providing an
> > > > interface that containers could implement to perform injection on
a
> > > > managed bean when MyFaces brings that bean into service? This
would
> > > > allow MyFaces to maintain control of the timing while allowing the
> > > > container to scan for annotations and handle injection when
prompted
> > > > to do so.
> > > >
> > > > Best wishes,
> > > > Paul
> > > >
> > > >
> > > > On 2/26/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
> > > > > I know the specs can be vague sometimes, but I don't interpret
the first
> > > > > paragraph of section 5.4 as meaning the JSF implementation is
> > > responsible
> > > > > for @EJB, @Resources, etc. The JSF spec specifically mentions
"the
> > > > > container to inject references". If Geronimo can intercept the
> > > > > instantiation of these classes in the classloader (something I
know
> > > nothing
> > > > > about right now), I think we are all good here. Wouldn't
MyFaces then
> > > be
> > > > > observing the requirements (in plain java) around @PostConstruct
after
> > > > > Geronimo had injected the resources?
> > > > >
> > > > > I think the JSF impl is only responsible for @PostConstruct and
> > > @Predestroy.
> > > > > This makes sense because scoped (request, session, application)
are the
> > > > > only candidates for this, and it would be more awkward to do
that from
> > > the
> > > > > container. I say all of this in an open manner, so anyone feel
free to
> > > > > discuss.
> > > > >
> > > > > You're point about javax.annotation being in the Servlet 2.5 is
taken.
> > > I
> > > > > totally missed that.
> > > > >
> > > > >
> > > > > Dennis Byrne
> > > > >
> > > > > On 2/26/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
> > > > > > Actually by "dependency injection" I'm specifically referring
to the
> > > > > > portion of the JSF spec that discusses injecting resources
where
> > > > > > certain annotations are found in a managed bean. So, while
scanning
> > > > > > for the @PreConstruct and @PostDestroy annotations MyFaces
would also
> > > > > > scan for @EJB, @Resource, @WebServiceRef, etc and then time
the
> > > > > > invocation of @PreConstruct and @PostDestroy to support the
injection.
> > > > > >
> > > >
Re: @PreDestroy, Servlet API,
OK, I think the RI also recently added the META-INF/services
technique. But I don't know how reliable this sun blog entry is:
http://tinyurl.com/yrrjs2
Best wishes,
Paul
On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
The RI uses two ways to lookup the implementation of the vendor
specific implementation of the InjectionProvider. They first try to
use a web context init param and if that is not configured they simply
use a system property. Both keyed by the class name of the
InjectionProvider interface.
2007/3/2, Paul McMahan <[EMAIL PROTECTED]>:
> I think Mathias' suggestion is right on. I haven't looked at the RI
> code but I read somewhere that it passes the name of
> InjectionProviders via entries in META-INF/services. If MyFaces used
> a similar approach I think it should work OK for Geronimo and just
> about any other container that supports injection, And it should also
> make MyFaces more interchangeable with the RI.
>
> Best wishes,
> Paul
>
> On 3/2/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
> > Similar to what Mathias mentioned?
> >
> > http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
> >
> > It's not much work (on our side) but it sounds pretty vendor specific.
> > Again, I don't have a better solution. Mathias writes "which is implemented
> > by j2ee containers". I wonder if each container will end up looking for
> > different interfaces. How would MyFaces find Geronimo's implementation ? A
> > context parameter? A for loop like this ...
> >
> > String[] providers = new String[]{"org,apache.geronimo.DIProvider",
> > "com.bea.DIProvider", "org.jboss.DIProvider"}
> >
> > for(String clazz : providers){
> > try{
> > return ClassUtils.load (clazz)
> > }catch(){}
> > }
> >
> > Dennis Byrne
> >
> >
> > On 3/1/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
> > > OK, I think your interpretation of the spec makes sense and there's
> > > one particular aspect we should discuss a little further.
> > >
> > > The container doesn't know which classes are managed beans so it
> > > wouldn't know when to intercept the instantiation process to perform
> > > injection. What would you all think about MyFaces providing an
> > > interface that containers could implement to perform injection on a
> > > managed bean when MyFaces brings that bean into service? This would
> > > allow MyFaces to maintain control of the timing while allowing the
> > > container to scan for annotations and handle injection when prompted
> > > to do so.
> > >
> > > Best wishes,
> > > Paul
> > >
> > >
> > > On 2/26/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
> > > > I know the specs can be vague sometimes, but I don't interpret the first
> > > > paragraph of section 5.4 as meaning the JSF implementation is
> > responsible
> > > > for @EJB, @Resources, etc. The JSF spec specifically mentions "the
> > > > container to inject references". If Geronimo can intercept the
> > > > instantiation of these classes in the classloader (something I know
> > nothing
> > > > about right now), I think we are all good here. Wouldn't MyFaces then
> > be
> > > > observing the requirements (in plain java) around @PostConstruct after
> > > > Geronimo had injected the resources?
> > > >
> > > > I think the JSF impl is only responsible for @PostConstruct and
> > @Predestroy.
> > > > This makes sense because scoped (request, session, application) are the
> > > > only candidates for this, and it would be more awkward to do that from
> > the
> > > > container. I say all of this in an open manner, so anyone feel free to
> > > > discuss.
> > > >
> > > > You're point about javax.annotation being in the Servlet 2.5 is taken.
> > I
> > > > totally missed that.
> > > >
> > > >
> > > > Dennis Byrne
> > > >
> > > > On 2/26/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
> > > > > Actually by "dependency injection" I'm specifically referring to the
> > > > > portion of the JSF spec that discusses injecting resources where
> > > > > certain annotations are found in a managed bean. So, while scanning
> > > > > for the @PreConstruct and @PostDestroy annotations MyFaces would also
> > > > > scan for @EJB, @Resource, @WebServiceRef, etc and then time the
> > > > > invocation of @PreConstruct and @PostDestroy to support the injection.
> > > > >
> > > > > Tomcat provides an example of how this can be done. The following
> > > > > class scans for annotations when a web app starts:
> > > > >
> > > >
> >
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/WebAnnotationSet.java
> > > > >
> > > > > And then this class handles the injection and calling the
> > > > > PostConstruct and PreDestroy methods when an servlet, filter, or
> > > > > listener is brought into service:
> > > > >
> > > >
> >
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/DefaultAnnotationProcessor.java
> > > > >
> > > > > Would it make sense for MyFaces to follow a similar approach for
> > > > > m
Re: @PreDestroy, Servlet API,
Hello Dennis, I think the interface has nothing to do with tomcat. Would the interface meet your requirements? If yes, I would suggest following: Create a AnnotationProcessorFactory which return as default an AnnotationProcessor who is a copy of the tomcat DefaultAnnotationProcessor(the code has no dependency to other tomcat code). I think the factory should return a suitable AnnotationProcessor based on which Annotations are present in the classpath. Maybe we can make the AnnotationProcessor configurable. If you like I would add this code to 1.2. Regards Bernd
Re: getAlign() and setAlign() not in JSF 1.2 spec
Thanks Dennis! On 3/2/07, Dennis Byrne <[EMAIL PROTECTED]> wrote: I removed it from the code generator. Some of the renderers still look for the 'align' attribute but I'll get to that later. Thanks, Dennis Byrne On 3/2/07, Paul McMahan <[EMAIL PROTECTED]> wrote: > I see that the datafld, dataformatas, and datasrc properties were > removed from HtmlDataTable in rev 513533. Should the align property > also be removed from HtmlDataTable and HtmlPanelGrid since its not in > spec? > > Best wishes, > Paul > -- Dennis Byrne
Re: @PreDestroy, Servlet API,
On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
Hello Dennis,
why we should look at the RI?
I'd prefer doing things that is compatible with them. This is easier on the
users and it makes passing TCK smoother.
Can we use this Interface
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/AnnotationProcessor.html
?
I'd prefer something that would work on other Servlet containers. I am open
to ideas.
Why you don't like to import javax.annotation. in the code. If the
annotation are missing in the container the annotations in the managed
bean would be meaningless. But maybe the annotation are required by the
servlet spec.
I didn't do this for users who were using @PostConstruct in their managed
beans, I did this to avoid ClassDefNotFoundErrors for users who *didn't* use
@PostConstruct. However Paul has already pointed out in this thread that
this is not realistic, since Servlet 2.5 requires these annotations.
Why you create a own class for each Listener?
Regards
Bernd
Dennis Byrne wrote:
> As much as I agree w/ you about how better things would be if this were
in
> the spec, and as much as I hate to "bow down" here, I am actually OK
with
> using com.sun.faces.spi.InjectionProvider as the parameter in MyFaces as
> well ... for the sake of users. If anyone has a problem w/ it, we can
go
> with org.apache.myfaces.InjectionProvider.
>
> Dennis Byrne
>
> On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
>>
>> The RI looks for "com.sun.faces.spi.InjectionProvider" for a class
>> name which implements this interface. It would have been very nice if
>> this is part of the spec. But that is not the case so we need to find
>> a way to support any kind of j2ee container. IMO injecting j2ee
>> resources without knowing where these resources can be found is not
>> possible. Therefore myfaces should call an InjectionProvider which
>> simply do this job.
>>
>> 2007/3/3, Dennis Byrne <[EMAIL PROTECTED]>:
>> > Are any of these class names or context params start w/
>> javax.faces? If
>> > so, we can move the conversation back into the issue tracker and I'll
>> close
>> > the @PostConstruct issue once Paul says it's good to go. I don't see
>> the
>> > point of the system property though.
>> >
>> > Dennis Byrne
>> >
>> >
>> > On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
>> > > The RI uses two ways to lookup the implementation of the vendor
>> > > specific implementation of the InjectionProvider. They first try to
>> > > use a web context init param and if that is not configured they
>> simply
>> > > use a system property. Both keyed by the class name of the
>> > > InjectionProvider interface.
>> > >
>> > > 2007/3/2, Paul McMahan <[EMAIL PROTECTED]>:
>> > > > I think Mathias' suggestion is right on. I haven't looked at
>> the RI
>> > > > code but I read somewhere that it passes the name of
>> > > > InjectionProviders via entries in META-INF/services. If MyFaces
>> used
>> > > > a similar approach I think it should work OK for Geronimo and
just
>> > > > about any other container that supports injection, And it should
>> also
>> > > > make MyFaces more interchangeable with the RI.
>> > > >
>> > > > Best wishes,
>> > > > Paul
>> > > >
>> > > > On 3/2/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
>> > > > > Similar to what Mathias mentioned?
>> > > > >
>> > > > >
>> > http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
>> > > > >
>> > > > > It's not much work (on our side) but it sounds pretty vendor
>> specific.
>> > > > > Again, I don't have a better solution. Mathias writes "which
is
>> > implemented
>> > > > > by j2ee containers". I wonder if each container will end up
>> looking
>> > for
>> > > > > different interfaces. How would MyFaces find Geronimo's
>> > implementation ? A
>> > > > > context parameter? A for loop like this ...
>> > > > >
>> > > > > String[] providers = new String[]{"org,
apache.geronimo.DIProvider
>> ",
>> > > > > "com.bea.DIProvider", "org.jboss.DIProvider "}
>> > > > >
>> > > > > for(String clazz : providers){
>> > > > > try{
>> > > > > return ClassUtils.load (clazz)
>> > > > > }catch(){}
>> > > > > }
>> > > > >
>> > > > > Dennis Byrne
>> > > > >
>> > > > >
>> > > > > On 3/1/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
>> > > > > > OK, I think your interpretation of the spec makes sense and
>> there's
>> > > > > > one particular aspect we should discuss a little further.
>> > > > > >
>> > > > > > The container doesn't know which classes are managed beans
>> so it
>> > > > > > wouldn't know when to intercept the instantiation process to
>> perform
>> > > > > > injection. What would you all think about MyFaces providing
an
>> > > > > > interface that containers could implement to perform
injection
>> on a
>> > > > > > managed bean when MyFaces brings that bean into
service? This
>> would
>> > > > > > allow MyFaces to maintain control of the timing while
allowing
>> the
>> > > > > > container to scan for annotations a
Re: @PreDestroy, Servlet API,
Hello Dennis,
why we should look at the RI?
Can we use this Interface
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/AnnotationProcessor.html?
Why you don't like to import javax.annotation. in the code. If the
annotation are missing in the container the annotations in the managed
bean would be meaningless. But maybe the annotation are required by the
servlet spec.
Why you create a own class for each Listener?
Regards
Bernd
Dennis Byrne wrote:
As much as I agree w/ you about how better things would be if this were in
the spec, and as much as I hate to "bow down" here, I am actually OK with
using com.sun.faces.spi.InjectionProvider as the parameter in MyFaces as
well ... for the sake of users. If anyone has a problem w/ it, we can go
with org.apache.myfaces.InjectionProvider.
Dennis Byrne
On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
The RI looks for "com.sun.faces.spi.InjectionProvider" for a class
name which implements this interface. It would have been very nice if
this is part of the spec. But that is not the case so we need to find
a way to support any kind of j2ee container. IMO injecting j2ee
resources without knowing where these resources can be found is not
possible. Therefore myfaces should call an InjectionProvider which
simply do this job.
2007/3/3, Dennis Byrne <[EMAIL PROTECTED]>:
> Are any of these class names or context params start w/
javax.faces? If
> so, we can move the conversation back into the issue tracker and I'll
close
> the @PostConstruct issue once Paul says it's good to go. I don't see
the
> point of the system property though.
>
> Dennis Byrne
>
>
> On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
> > The RI uses two ways to lookup the implementation of the vendor
> > specific implementation of the InjectionProvider. They first try to
> > use a web context init param and if that is not configured they
simply
> > use a system property. Both keyed by the class name of the
> > InjectionProvider interface.
> >
> > 2007/3/2, Paul McMahan <[EMAIL PROTECTED]>:
> > > I think Mathias' suggestion is right on. I haven't looked at
the RI
> > > code but I read somewhere that it passes the name of
> > > InjectionProviders via entries in META-INF/services. If MyFaces
used
> > > a similar approach I think it should work OK for Geronimo and just
> > > about any other container that supports injection, And it should
also
> > > make MyFaces more interchangeable with the RI.
> > >
> > > Best wishes,
> > > Paul
> > >
> > > On 3/2/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
> > > > Similar to what Mathias mentioned?
> > > >
> > > >
> http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
> > > >
> > > > It's not much work (on our side) but it sounds pretty vendor
specific.
> > > > Again, I don't have a better solution. Mathias writes "which is
> implemented
> > > > by j2ee containers". I wonder if each container will end up
looking
> for
> > > > different interfaces. How would MyFaces find Geronimo's
> implementation ? A
> > > > context parameter? A for loop like this ...
> > > >
> > > > String[] providers = new String[]{"org,apache.geronimo.DIProvider
",
> > > > "com.bea.DIProvider", "org.jboss.DIProvider "}
> > > >
> > > > for(String clazz : providers){
> > > > try{
> > > > return ClassUtils.load (clazz)
> > > > }catch(){}
> > > > }
> > > >
> > > > Dennis Byrne
> > > >
> > > >
> > > > On 3/1/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
> > > > > OK, I think your interpretation of the spec makes sense and
there's
> > > > > one particular aspect we should discuss a little further.
> > > > >
> > > > > The container doesn't know which classes are managed beans
so it
> > > > > wouldn't know when to intercept the instantiation process to
perform
> > > > > injection. What would you all think about MyFaces providing an
> > > > > interface that containers could implement to perform injection
on a
> > > > > managed bean when MyFaces brings that bean into service? This
would
> > > > > allow MyFaces to maintain control of the timing while allowing
the
> > > > > container to scan for annotations and handle injection when
prompted
> > > > > to do so.
> > > > >
> > > > > Best wishes,
> > > > > Paul
> > > > >
> > > > >
> > > > > On 2/26/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
> > > > > > I know the specs can be vague sometimes, but I don't
interpret
the
> first
> > > > > > paragraph of section 5.4 as meaning the JSF implementation is
> > > > responsible
> > > > > > for @EJB, @Resources, etc. The JSF spec specifically
mentions
> "the
> > > > > > container to inject references". If Geronimo can intercept
the
> > > > > > instantiation of these classes in the classloader
(something I
> know
> > > > nothing
> > > > > > about right now), I think we are all good here. Wouldn't
MyFaces
> then
> > > > be
> > > > > > observing the requirements (in plain java) around
@PostConstruct
> after
> > > > > > Geronimo had injecte
Re: MyFaces Fusion Name Poll App
Top 5 On 3/3/07, Mario Ivankovits <[EMAIL PROTECTED]> wrote: Another question is, if I should allow you to vote for each name, or if I should force you to cast your vote for e.g. 5 names only. Then changing the available vote selections should be 0 1 2 3 4 5, no? > Hi! > > Using Apache MyFaces Fusion I've created a new example app: Ballot > A tool to help make what I call "dynamic votes". > BTW: Even if there would have such a tool already there, I wanted to > create another example for fusion. > > It is not meant to replace the voting on the ML, its just to distill > those names worth to vote for. > > The dynamic part means, you can change your mind as long as the poll is > open. > You'll always be able to see the current state about each name. > > After registering you'll receive an url which allows you to cast a vote > ... and change it again. > > Afterwards I'll take the top (say 5) names and we make a normal vote on > the ML on them. > > > No to the poll rules. I plan that you will be able to make 5 decisions > per name, they are: -2 -1 0 1 2 > What do you think, is this suitable? > > Ciao, > Mario > >
Re: MyFaces Fusion Name Poll App
Another question is, if I should allow you to vote for each name, or if I should force you to cast your vote for e.g. 5 names only. Then changing the available vote selections should be 0 1 2 3 4 5, no? > Hi! > > Using Apache MyFaces Fusion I've created a new example app: Ballot > A tool to help make what I call "dynamic votes". > BTW: Even if there would have such a tool already there, I wanted to > create another example for fusion. > > It is not meant to replace the voting on the ML, its just to distill > those names worth to vote for. > > The dynamic part means, you can change your mind as long as the poll is > open. > You'll always be able to see the current state about each name. > > After registering you'll receive an url which allows you to cast a vote > ... and change it again. > > Afterwards I'll take the top (say 5) names and we make a normal vote on > the ML on them. > > > No to the poll rules. I plan that you will be able to make 5 decisions > per name, they are: -2 -1 0 1 2 > What do you think, is this suitable? > > Ciao, > Mario > >
Re: @PreDestroy, Servlet API,
What is wrong with
http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/DefaultAnnotationProcessor.java
?
Dennis Byrne wrote:
As much as I agree w/ you about how better things would be if this were in
the spec, and as much as I hate to "bow down" here, I am actually OK with
using com.sun.faces.spi.InjectionProvider as the parameter in MyFaces as
well ... for the sake of users. If anyone has a problem w/ it, we can go
with org.apache.myfaces.InjectionProvider.
Dennis Byrne
On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
The RI looks for "com.sun.faces.spi.InjectionProvider" for a class
name which implements this interface. It would have been very nice if
this is part of the spec. But that is not the case so we need to find
a way to support any kind of j2ee container. IMO injecting j2ee
resources without knowing where these resources can be found is not
possible. Therefore myfaces should call an InjectionProvider which
simply do this job.
2007/3/3, Dennis Byrne <[EMAIL PROTECTED]>:
> Are any of these class names or context params start w/
javax.faces? If
> so, we can move the conversation back into the issue tracker and I'll
close
> the @PostConstruct issue once Paul says it's good to go. I don't see
the
> point of the system property though.
>
> Dennis Byrne
>
>
> On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote:
> > The RI uses two ways to lookup the implementation of the vendor
> > specific implementation of the InjectionProvider. They first try to
> > use a web context init param and if that is not configured they
simply
> > use a system property. Both keyed by the class name of the
> > InjectionProvider interface.
> >
> > 2007/3/2, Paul McMahan <[EMAIL PROTECTED]>:
> > > I think Mathias' suggestion is right on. I haven't looked at
the RI
> > > code but I read somewhere that it passes the name of
> > > InjectionProviders via entries in META-INF/services. If MyFaces
used
> > > a similar approach I think it should work OK for Geronimo and just
> > > about any other container that supports injection, And it should
also
> > > make MyFaces more interchangeable with the RI.
> > >
> > > Best wishes,
> > > Paul
> > >
> > > On 3/2/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
> > > > Similar to what Mathias mentioned?
> > > >
> > > >
> http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337
> > > >
> > > > It's not much work (on our side) but it sounds pretty vendor
specific.
> > > > Again, I don't have a better solution. Mathias writes "which is
> implemented
> > > > by j2ee containers". I wonder if each container will end up
looking
> for
> > > > different interfaces. How would MyFaces find Geronimo's
> implementation ? A
> > > > context parameter? A for loop like this ...
> > > >
> > > > String[] providers = new String[]{"org,apache.geronimo.DIProvider
",
> > > > "com.bea.DIProvider", "org.jboss.DIProvider "}
> > > >
> > > > for(String clazz : providers){
> > > > try{
> > > > return ClassUtils.load (clazz)
> > > > }catch(){}
> > > > }
> > > >
> > > > Dennis Byrne
> > > >
> > > >
> > > > On 3/1/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
> > > > > OK, I think your interpretation of the spec makes sense and
there's
> > > > > one particular aspect we should discuss a little further.
> > > > >
> > > > > The container doesn't know which classes are managed beans
so it
> > > > > wouldn't know when to intercept the instantiation process to
perform
> > > > > injection. What would you all think about MyFaces providing an
> > > > > interface that containers could implement to perform injection
on a
> > > > > managed bean when MyFaces brings that bean into service? This
would
> > > > > allow MyFaces to maintain control of the timing while allowing
the
> > > > > container to scan for annotations and handle injection when
prompted
> > > > > to do so.
> > > > >
> > > > > Best wishes,
> > > > > Paul
> > > > >
> > > > >
> > > > > On 2/26/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
> > > > > > I know the specs can be vague sometimes, but I don't
interpret
the
> first
> > > > > > paragraph of section 5.4 as meaning the JSF implementation is
> > > > responsible
> > > > > > for @EJB, @Resources, etc. The JSF spec specifically
mentions
> "the
> > > > > > container to inject references". If Geronimo can intercept
the
> > > > > > instantiation of these classes in the classloader
(something I
> know
> > > > nothing
> > > > > > about right now), I think we are all good here. Wouldn't
MyFaces
> then
> > > > be
> > > > > > observing the requirements (in plain java) around
@PostConstruct
> after
> > > > > > Geronimo had injected the resources?
> > > > > >
> > > > > > I think the JSF impl is only responsible for @PostConstruct
and
> > > > @Predestroy.
> > > > > > This makes sense because scoped (request, session,
application)
> are the
> > > > > > only candidates for this, and it would be more awkward to do
that
> from
> > > > the
> >
Re: MyFaces Fusion Name Poll App
Btw, this poll will not be anonymous, so that everyone can be sure that I don't manipulate the data. A (to be create) page will allow you to have a look at the vote of each voter. If you don't mind > Hi! > > Using Apache MyFaces Fusion I've created a new example app: Ballot > A tool to help make what I call "dynamic votes". > BTW: Even if there would have such a tool already there, I wanted to > create another example for fusion. > > It is not meant to replace the voting on the ML, its just to distill > those names worth to vote for. > > The dynamic part means, you can change your mind as long as the poll is > open. > You'll always be able to see the current state about each name. > > After registering you'll receive an url which allows you to cast a vote > ... and change it again. > > Afterwards I'll take the top (say 5) names and we make a normal vote on > the ML on them. > > > No to the poll rules. I plan that you will be able to make 5 decisions > per name, they are: -2 -1 0 1 2 > What do you think, is this suitable? > > Ciao, > Mario > >
MyFaces Fusion Name Poll App
Hi! Using Apache MyFaces Fusion I've created a new example app: Ballot A tool to help make what I call "dynamic votes". BTW: Even if there would have such a tool already there, I wanted to create another example for fusion. It is not meant to replace the voting on the ML, its just to distill those names worth to vote for. The dynamic part means, you can change your mind as long as the poll is open. You'll always be able to see the current state about each name. After registering you'll receive an url which allows you to cast a vote ... and change it again. Afterwards I'll take the top (say 5) names and we make a normal vote on the ML on them. No to the poll rules. I plan that you will be able to make 5 decisions per name, they are: -2 -1 0 1 2 What do you think, is this suitable? Ciao, Mario
