Re: Tiger (annotations) + Facelets
Facelets and Tiger annotations work fine for me. I'm not using the
view controller stuff yet (@Init) but @Bean and @Property work fine
for me. As soon as I finish refactoring for the new package names I
will check into shale-goodies.
Sean
On 8/7/06, Sean Schofield [EMAIL PROTECTED] wrote:
I'm about to add the annotations stuff to my petstore app (which uses
facelets) so I will let you know what I find shortly.
Sean
On 8/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
not only @Bean(...)
also
@Init
public void myInit() {
System.out.println(getClass());
_name = FUNKY DJ!;
}
is not working
On 8/6/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
hi,
anybody used Tiger w/ Facelets?
I get (in Jetty6)
javax.faces.el.PropertyNotFoundException: /index.xhtml @23,102
value=#{helloWorldBacking.name}: Target Unreachable, identifier
'helloWorldBacking' resolved to null
at
com.sun.facelets.el.LegacyValueBinding.isReadOnly(LegacyValueBinding.java:84)
thx
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: Tiger (annotations) + Facelets
thx,
but I still get this error. I hope I've time to look deeper into it.
-Matt
snip
javax.faces.el.PropertyNotFoundException: /index.xhtml @23,102
value=#{helloWorldBacking.name}: Target Unreachable, identifier
'helloWorldBacking' resolved to null
at
com.sun.facelets.el.LegacyValueBinding.isReadOnly(LegacyValueBinding.java:84)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.EditableValueRenderer.getReadOnly(EditableValueRenderer.java:226)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.FormElementRenderer.renderAsElement(FormElementRenderer.java:171)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.InputLabelAndMessageRenderer.getLabelFor(InputLabelAndMessageRenderer.java:70)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.LabelAndMessageRenderer$Label.getForId(LabelAndMessageRenderer.java:565)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.OutputLabelRenderer.encodeAll(OutputLabelRenderer.java:81)
at
org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderer.delegateRenderer(CoreRenderer.java:290)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.LabelAndMessageRenderer._renderLabelCell(LabelAndMessageRenderer.java:314)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.LabelAndMessageRenderer.encodeAll(LabelAndMessageRenderer.java:231)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.InputLabelAndMessageRenderer.encodeAll(InputLabelAndMessageRenderer.java:111)
at
org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderer.encodeEnd(CoreRenderer.java:178)
at
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:670)
at
org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode._renderComponent(UIComponentUINode.java:326)
at
org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render(UIComponentUINode.java:272)
at
org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render(UIComponentUINode.java:249)
at
org.apache.myfaces.trinidadinternal.ui.composite.ContextPoppingUINode$ContextPoppingRenderer.render(ContextPoppingUINode.java:234)
at
org.apache.myfaces.trinidadinternal.ui.BaseUINode.render(BaseUINode.java:356)
at
org.apache.myfaces.trinidadinternal.ui.BaseUINode.render(BaseUINode.java:311)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderChild(BaseRenderer.java:422)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:340)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:232)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderContent(BaseRenderer.java:139)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.render(BaseRenderer.java:91)
at
org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafRenderer.render(XhtmlLafRenderer.java:78)
at
org.apache.myfaces.trinidadinternal.ui.BaseUINode.render(BaseUINode.java:356)
at
org.apache.myfaces.trinidadinternal.ui.BaseUINode.render(BaseUINode.java:311)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderChild(BaseRenderer.java:422)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:340)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:232)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderContent(BaseRenderer.java:139)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.render(BaseRenderer.java:91)
at
org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafRenderer.render(XhtmlLafRenderer.java:78)
at
org.apache.myfaces.trinidadinternal.ui.BaseUINode.render(BaseUINode.java:356)
at
org.apache.myfaces.trinidadinternal.ui.BaseUINode.render(BaseUINode.java:311)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderChild(BaseRenderer.java:422)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:340)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:232)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderContent(BaseRenderer.java:139)
at
org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.BorderLayoutRenderer.renderIndexedChildren(BorderLayoutRenderer.java:52)
at
org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.BorderLayoutRenderer.renderContent(BorderLayoutRenderer.java:81)
at
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.render(BaseRenderer.java:91)
at
org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafRenderer.render(XhtmlLafRenderer.java:78)
at
Shale Test - Exceptions
Looking at Shale Test, specifically the AbstractJsfTestCase I noticed that the method signatures of the JUnit setup tearDown methods have been altered so that they no longer can throw exceptions. Just wondering if the throws Exception can be added back to these methods so they stay true to JUnit. Thanks, Bob Butash
Remoting Documentation
I've attached an HTML file that documents Shale Remoting. It would be nice if some kind committer could drop it into $SHALE_HOME/framework/trunk/src/site/xdoc/features-remoting.xml and commit that XML file. I would've given you the XML file directly, but 'mvn site' isn't exactly working for me at the moment. Thanks,david
Re: Remoting Documentation
On 8/8/06, David Geary [EMAIL PROTECTED] wrote: I've attached an HTML file that documents Shale Remoting. It would be nice if some kind committer could drop it into $SHALE_HOME/framework/trunk/src/site/xdoc/features-remoting.xml and commit that XML file. I would've given you the XML file directly, but 'mvn site' isn't exactly working for me at the moment. Thank you! I don't think the list accepts attachments. Can you open a JIRA issue and attach it there? http://issues.apache.org/struts/browse/SHALE -- Wendy
Re: Remoting Documentation
Attachment didn't seem to go through. Could you file a ticket? You can send me the file directly I'll still have to open a ticket to commit it. Greg On Aug 8, 2006, at 4:25 PM, David Geary wrote: I've attached an HTML file that documents Shale Remoting. It would be nice if some kind committer could drop it into $SHALE_HOME/ framework/trunk/src/site/xdoc/features-remoting.xml and commit that XML file. I would've given you the XML file directly, but 'mvn site' isn't exactly working for me at the moment. Thanks, david
Re: Remoting Documentation
Will do. david 2006/8/8, Greg Reddin [EMAIL PROTECTED]: Attachment didn't seem to go through. Could you file a ticket? You can send me the file directly I'll still have to open a ticket to commit it. Greg On Aug 8, 2006, at 4:25 PM, David Geary wrote: I've attached an HTML file that documents Shale Remoting. It would be nice if some kind committer could drop it into $SHALE_HOME/ framework/trunk/src/site/xdoc/features-remoting.xml and commit that XML file. I would've given you the XML file directly, but 'mvn site' isn't exactly working for me at the moment. Thanks, david
Re: Confluence Wiki Anyone?
On 8/8/06, Sean Schofield [EMAIL PROTECTED] wrote: What do people think about setting up a confluence wiki for Shale? Wendy tipped me off about cwiki.apache.org. Apparently its up and running now. Personally I think Confluence is a lot better then the current wiki. I wanted it from the beginning, but they were still working out the details. It seems to be available now, requests for new spaces and imports are being fulfilled. Take a look at how Geronimo is using it: http://cwiki.apache.org/geronimo/ They have a separate 'space' for the docs for each version, one for development, project management, knowledge base, and sandbox. The space naming convention would probably give us SHLx___ Do we want to have just one space, and use it like we use Moin, or do we want to push most of the project docs to the wiki? In the second case we might want SHLxDEV for our notes on how to use Maven and Subversion for various things, and another one for docs that get exported and included in the distribution. -- Wendy
SHALE-219 -- Still want it for 1.0.3?
This issue[1] is the last functionality related one flagged in JIRA for 1.0.3. Do we still want to do it first, or can we target that for a later release and move on towards getting 1.0.3 out the door now? Craig [1] http://issues.apache.org/struts/browse/SHALE-219
Re: Remoting Documentation
2006/8/8, Wendy Smoak [EMAIL PROTECTED]: On 8/8/06, David Geary [EMAIL PROTECTED] wrote: I've attached an HTML file that documents Shale Remoting. It would be nice if some kind committer could drop it into $SHALE_HOME/framework/trunk/src/site/xdoc/features-remoting.xml and commit that XML file. I would've given you the XML file directly, but 'mvn site' isn't exactly working for me at the moment. Thank you! I don't think the list accepts attachments. Can you open a JIRA issue and attach it there? There was already an issue: Shale-130. I attached a ZIP, but then realized that I needed to account for the bigger picture so I made some mods and attached a second ZIP file. So, there are two ZIP files attached to Shale-130. The 314kb version should be removed, but I don't have admin privileges. There's still some work to be done on remoting documentation, but this should get us 60%, or so, of the way there. Thanks, david http://issues.apache.org/struts/browse/SHALE -- Wendy
Re: Remoting Documentation
On 8/8/06, David Geary [EMAIL PROTECTED] wrote: There's still some work to be done on remoting documentation, but this should get us 60%, or so, of the way there. I'm working with it now. BTW, what error are you getting from 'mvn site' ? -- Wendy
Re: Confluence Wiki Anyone?
strong +1 on that. we use that at work. pretty awesome! On 8/8/06, Sean Schofield [EMAIL PROTECTED] wrote: What do people think about setting up a confluence wiki for Shale? Wendy tipped me off about cwiki.apache.org. Apparently its up and running now. Personally I think Confluence is a lot better then the current wiki. Sean -- Matthias Wessendorf further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Confluence Wiki Anyone?
While I tend to lean toward the 'use OSS when possible' side, Confluence is a sexy wiki. If we can get a confluence instance, how feasible would it be to: - move all the documentation to the wiki - have that content available as a PDF to replace what we moved We could even go so far as to commit the pdf to svn so we can version it along with the distributions. I see this as having several positive aspects. - we no longer have to publish the site documentation on every simple change - we can use that cool snippet plugin - those who prefer to grab a zip/pdf and run can do so (without having to build from src xdocs if offline) - there are more I'm sure -- James Mitchell 678.910.8017 On Aug 8, 2006, at 8:00 PM, Wendy Smoak wrote: On 8/8/06, Sean Schofield [EMAIL PROTECTED] wrote: What do people think about setting up a confluence wiki for Shale? Wendy tipped me off about cwiki.apache.org. Apparently its up and running now. Personally I think Confluence is a lot better then the current wiki. I wanted it from the beginning, but they were still working out the details. It seems to be available now, requests for new spaces and imports are being fulfilled. Take a look at how Geronimo is using it: http://cwiki.apache.org/ geronimo/ They have a separate 'space' for the docs for each version, one for development, project management, knowledge base, and sandbox. The space naming convention would probably give us SHLx___ Do we want to have just one space, and use it like we use Moin, or do we want to push most of the project docs to the wiki? In the second case we might want SHLxDEV for our notes on how to use Maven and Subversion for various things, and another one for docs that get exported and included in the distribution. -- Wendy
Re: Remoting Documentation
2006/8/8, Wendy Smoak [EMAIL PROTECTED]: On 8/8/06, David Geary [EMAIL PROTECTED] wrote: There's still some work to be done on remoting documentation, but this should get us 60%, or so, of the way there. I'm working with it now. Thanks. BTW, what error are you getting from 'mvn site' ? The build succeeds, but when I pull up .../shale-core/target/site/index.html, I get a page with very little content and missing links. david -- Wendy
Re: SHALE-219 -- Still want it for 1.0.3?
1.0.3 is going to be another alpha/beta release right? We still need to fix the dialog issues such as SHALE-48 before we go legit right? I'm assuming the goal is to have a solid 1.0.4 release just before Apache Con no? If so, then I imagine we're going to be busy in September. My personal roadmap will involve helping Craig to resolve the dialog problems and getting a nice version of shale-petstore ready. That plus my day job will keep me busy these next few weeks. Sean On 8/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: This issue[1] is the last functionality related one flagged in JIRA for 1.0.3. Do we still want to do it first, or can we target that for a later release and move on towards getting 1.0.3 out the door now? Craig [1] http://issues.apache.org/struts/browse/SHALE-219
Re: SHALE-219 -- Still want it for 1.0.3?
On 8/8/06, Sean Schofield [EMAIL PROTECTED] wrote: 1.0.3 is going to be another alpha/beta release right? That's my thinking ... dialog and tiles are still problem areas. But there's a bunch of new stuff and bugfixes plus the new build infrastructure that people can leverage now. We still need to fix the dialog issues such as SHALE-48 before we go legit right? I'm assuming the goal is to have a solid 1.0.4 release just before Apache Con no? If so, then I imagine we're going to be busy in September. Yes. My personal roadmap will involve helping Craig to resolve the dialog problems and getting a nice version of shale-petstore ready. That plus my day job will keep me busy these next few weeks. Cool! I've been doing some thinking and will post a wiki page with proposed goals and an architecture for us to poke holes in before we try to actually build it. Sean Craig On 8/8/06, Craig McClanahan [EMAIL PROTECTED] wrote: This issue[1] is the last functionality related one flagged in JIRA for 1.0.3. Do we still want to do it first, or can we target that for a later release and move on towards getting 1.0.3 out the door now? Craig [1] http://issues.apache.org/struts/browse/SHALE-219
