[jira] Resolved: (TRINIDAD-1032) New component: tr:panelStretchLayout

[Andrew Robinson (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRINIDAD-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrew Robinson resolved TRINIDAD-1032.
---

   Resolution: Fixed
Fix Version/s:  1.2.8-core
1.0.8-core

Added positioning layout to the panelBorderLayout.
Added new skin selectors for the component with a positioned layout.

See the panelBorderLayout.jspx in the demo project for an example (at the 
bottom of the page).

> New component: tr:panelStretchLayout
> 
>
> Key: TRINIDAD-1032
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1032
> Project: MyFaces Trinidad
>  Issue Type: New Feature
>  Components: Components
>Affects Versions: 1.0.7-core, 1.2.7-core
>Reporter: Andrew Robinson
>Assignee: Andrew Robinson
> Fix For:  1.0.8-core,  1.2.8-core
>
>
> Add a new component, to the trinidad-sandbox first, that is similar to the 
> panelBorderLayout. Unlike this component the panelStretchLayout would be 
> rendered using DIV instead of TABLE and would be able to stretch horizontally 
> and vertically. 
> The main reason I am proposing this is to be able to produce a component for 
> the new demo that can frame the browser viewport and have the demo page 
> content in a center-scrolling DIV. This way there can be a header, footer on 
> the page that fits on one page.
> For those that are familiar with the Oracle panelStretchLayout, this one 
> would not be as robust. I do not think it would be in the scope to 
> automatically stretch the children and I do not think that it would be needed 
> to have an auto-height for the original version.
> The component would have a top, bottom, left, and right facets and use the 
> children for the center. The facet sizes (height and width) would be 
> specified using attributes. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

The pdfExport component released ;)

[Hazem Saleh]

Hi guys,
Iam pleased to tell you that the (PDFExport) component is finished.
It works like the (excelExport) component.

for example)




Here is the patch url :
https://issues.apache.org/jira/browse/TOMAHAWK-1229

Thanks all :).
-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

[jira] Updated: (TOMAHAWK-1229) PDF Exporter Component

[Hazem Saleh (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TOMAHAWK-1229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hazem Saleh updated TOMAHAWK-1229:
--

Status: Patch Available  (was: Open)

> PDF Exporter Component
> --
>
> Key: TOMAHAWK-1229
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1229
> Project: MyFaces Tomahawk
>  Issue Type: New Feature
>Affects Versions: 1.1.7-SNAPSHOT
>Reporter: Hazem Saleh
> Fix For: 1.1.7-SNAPSHOT
>
>   Original Estimate: 504h
>  Remaining Estimate: 504h
>
> PDF Exporter

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Trinidad] Debug JS version breaks trunk

[Andrew Robinson]

Okay, I am doing something wrong, it is not broken.

If I am having a custom script that I do not want in Common for a core
component, how can I do it?

I am adding JS code for my panelBorderLayout enhancement that is only
needed for IE6. So I want to send it down from the renderer after
checking the version.

Right now I have the JS code in a string in my renderer in a class
extending Scriptlet. I would like to have it in a JS file instead.

How can I use LibraryScriplet to add this file from the renderer?
Where must I do all the registration for this new JS file so that the
resource loaders find it correctly?

Thanks,
Andrew



On Fri, Apr 4, 2008 at 5:07 PM, Andrew Robinson
<[EMAIL PROTECTED]> wrote:
> A renderer using LibraryScriptlet is getting the URL:
>  /trinidad-demo/adf/jsLibs/DebugApacheChart1_2_8.js
>  instead of:
>  /trinidad-demo/adf/jsLibsDebug/ApacheChart1_2_8.js
>
>  The former is what is added to the page. The latter is what is being
>  generated by the build. As a result, any component using
>  LibraryScriplet will break if JS debugging is turned on.
>
>  Anyone know why this is and if one was changed, why the other was not?
>
>  It would be hard to fix the LibraryScriplet as it would require an API change
>
>  Code snippets from LibraryScriptlet.java:
>
>   protected String getLibraryName(
> FacesContextcontext,
> RenderingContext arc)
>   {
> String libraryName = _libraryName;
>
> if (_isDebug(context))
>   libraryName = "Debug" + libraryName;
>
> return libraryName;
>   }
>
>   public static String getBaseLibURL()
>   {
> return _JSLIBS_DIRECTORY;
>   }
>
>   static private final String _JSLIBS_DIRECTORY = "/adf/jsLibs/";
>
>  -Andrew
>

[jira] Resolved: (TRINIDAD-999) tr:panelLabelAndMessage ... facet="help" generates two help strings

[Cagatay Civici (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TRINIDAD-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cagatay Civici resolved TRINIDAD-999.
-

   Resolution: Fixed
Fix Version/s:  1.2.8-core
1.0.8-core

> tr:panelLabelAndMessage ... facet="help" generates two help strings
> ---
>
> Key: TRINIDAD-999
> URL: https://issues.apache.org/jira/browse/TRINIDAD-999
> Project: MyFaces Trinidad
>  Issue Type: Bug
>  Components: Components
>Affects Versions: 1.2.6-core
> Environment: facelets
>Reporter: Mark Dopheide
>Assignee: Cagatay Civici
> Fix For:  1.0.8-core,  1.2.8-core
>
>
>  showRequired="true" for="dobCal">
> 
> 
> 
>  renderPopupButtonAsImage="true" value="#{signupForm.DOB}" />
> 
> -- The relevant part of the page gets rendered with this code 
> - 
> 
> (mm/dd/yy)
> 
> 
> 
> 
> 
> (mm/dd/yy)
>   
> 
> 
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[Trinidad] Debug JS version breaks trunk

[Andrew Robinson]

A renderer using LibraryScriptlet is getting the URL:
/trinidad-demo/adf/jsLibs/DebugApacheChart1_2_8.js
instead of:
/trinidad-demo/adf/jsLibsDebug/ApacheChart1_2_8.js

The former is what is added to the page. The latter is what is being
generated by the build. As a result, any component using
LibraryScriplet will break if JS debugging is turned on.

Anyone know why this is and if one was changed, why the other was not?

It would be hard to fix the LibraryScriplet as it would require an API change

Code snippets from LibraryScriptlet.java:

  protected String getLibraryName(
FacesContextcontext,
RenderingContext arc)
  {
String libraryName = _libraryName;

if (_isDebug(context))
  libraryName = "Debug" + libraryName;

return libraryName;
  }

  public static String getBaseLibURL()
  {
return _JSLIBS_DIRECTORY;
  }

  static private final String _JSLIBS_DIRECTORY = "/adf/jsLibs/";

-Andrew

[jira] Commented: (TRINIDAD-1036) Client Color Converter's getFormatHint() returns empty string for the hints.

[Yee-Wah Lee (JIRA)]

[ 
https://issues.apache.org/jira/browse/TRINIDAD-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585801#action_12585801
 ] 

Yee-Wah Lee commented on TRINIDAD-1036:
---

Attachment works for both trunk and jsf 1.2.6 branch.

> Client Color Converter's getFormatHint() returns empty string for the hints. 
> -
>
> Key: TRINIDAD-1036
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1036
> Project: MyFaces Trinidad
>  Issue Type: Bug
>  Components: Components
>Reporter: Yee-Wah Lee
>Priority: Minor
> Attachments: trin11_1036.diff
>
>
> 1. Sample code to create a button which, when clicked, gets the format hint 
> for a color field and displays it in an output text.
> 
>   
>   function getHint ()
>   {
> var colorField = document.getElementById ("sic1");
> var format = _getColorFieldFormat (colorField);
> var colorHint = document.getElementById ("help_sic1");
> colorHint.textContent = format.getFormatHint ();
>   }
>   
> 
> label="Enter or select color from palette below">
> 
>   
> 
>   
>text="Click for color hint"/>
> 2. Run the page and click the button - the output text is updated with the 
> string "Example Format: ". It should instead reflect the patterns for the 
> inputColor which are defaulted in the example above, i.e. "Example Format: 
> RRGGBB, #RRGGBB, r,g,b" 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Updated: (TRINIDAD-873) JavaScriptError in Core.js _formatErrorString

[Yee-wah Lee]

Hi all,

I would like to modify the code slightly from this patch. Basically, 
move the check for typeof down, so that it only affects the code which 
does String.replace(). For details, see TRINIDAD-1036.


I didn't see a test scenario for TRINIDAD-873, so if anyone familiar 
with the above can i) email me their test case or ii) verify the 
proposed changes, please let me know.


Thanks,
Yee-Wah

Original:
function _formatErrorString()
{
..
 for (var currToken in tokens)
 {
   var currValue = tokens[currToken];

   // if the token has no value, replace it with the empty string
   if (!currValue)
   {
 currValue = "";
   }

   // TRINIDAD-829:
   // we replace '{' and '}' to ensure, that tokens containing values
   // like {3} aren't parsed more than once...
   currValue = currValue.replace("{","{'");
   currValue = currValue.replace("}","'}");
}
-
With TRINIDAD-873 patch:
function _formatErrorString( )
{
  ..
 for (var currToken in tokens)
 {
   var currValue = tokens[currToken];

+// if the token has no value
+// or !typeof string, replace it with the empty string (see 
TRINIDAD-873)

+if (!currValue || !(typeof currValue == "string"))
   {
 currValue = "";
   }

   // TRINIDAD-829:
   // we replace '{' and '}' to ensure, that tokens containing values
   // like {3} aren't parsed more than once...
   currValue = currValue.replace("{","{'");
   currValue = currValue.replace("}","'}");
}
-
With TRINIDAD-1036 patch:
function _formatErrorString( )
{
  ..
 for (var currToken in tokens)
 {
   var currValue = tokens[currToken];

   // if the token has no value
+if (!currValue)
   {
  currValue = "";
   }

   // TRINIDAD-829:
   // we replace '{' and '}' to ensure, that tokens containing values
   // like {3} aren't parsed more than once...
+// Only do this if it is typeof string (see TRINIDAD-873)
+if (typeof currValue == "string")
+{
   currValue = currValue.replace("{","{'");
   currValue = currValue.replace("}","'}");
+}



Matthias Weßendorf (JIRA) wrote:

 [ 
https://issues.apache.org/jira/browse/TRINIDAD-873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Matthias Weßendorf updated TRINIDAD-873:


   Resolution: Fixed
Fix Version/s: 1.2.5-core
   1.0.5-core
   Status: Resolved  (was: Patch Available)

applied the patch to both trunks;

  

JavaScriptError in Core.js _formatErrorString
-

Key: TRINIDAD-873
URL: https://issues.apache.org/jira/browse/TRINIDAD-873
Project: MyFaces Trinidad
 Issue Type: Bug
   Affects Versions: 1.0.5-core
   Reporter: Thomas Spiegl
   Assignee: Matthias Weßendorf
Fix For: 1.0.5-core, 1.2.5-core

Attachments: Core.js.patch


currValue in defined in function _formatErrorString line 2807 may be a function 
(eg. removeDuplicates)
currValue.replace will then cause a JavaScript error
adding a typeof fixes the problem
// if the token has no value or !typeof string, replace it with the empty 
string
if (!currValue || !(typeof currValue == "string"))
{
  currValue = "";
}



  

[jira] Commented: (MYFACES-1850) component attributes problem with server side state saving with "serialize in state" = false

[Martin Marinschek (JIRA)]

[ 
https://issues.apache.org/jira/browse/MYFACES-1850?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585735#action_12585735
 ] 

Martin Marinschek commented on MYFACES-1850:


This is very dangerous; it's good you fix it. Simon's comment is still true, 
however. Generally, for references to JSF objects, this will not be a problem, 
cause they will implement the StateHolder-interface. Couldn't we serialize 
everything which is a reference-type and not a JSF-internal class, instead of 
serializing the full tree? Would this perform well? Could this be done in a 
central place?

regards,

Marti n

> component attributes problem with server side state saving with "serialize in 
> state" = false
> 
>
> Key: MYFACES-1850
> URL: https://issues.apache.org/jira/browse/MYFACES-1850
> Project: MyFaces Core
>  Issue Type: Bug
>  Components: General
>Affects Versions: 1.1.5, 1.2.2
>Reporter: Mario Ivankovits
>Assignee: Mario Ivankovits
>Priority: Critical
>
> When using server side state saving with "serialize state in view"=false all 
> the saved states for the same view contains a shared reference to the 
> component attribute map.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [proposal] jsf validation with annotations

[Cagatay Civici]

Hi,

I think Orchestra is kinda out of it's original scope, Mario and Simon
couldn't resist and add many cool useful features like viewController,
dynaForm and more that are not related to conversations and persistence.

Orchestra is becoming our alternative to seam, sev-en is a goodie right? So
rather than a seperate project, I've no problem if it gets merged in
Orchestra, just my 2 cents, it's up to further discussion.

Cagatay

On Fri, Apr 4, 2008 at 9:57 PM, Kito D. Mann <[EMAIL PROTECTED]> wrote:

>
>
> *From:* Gerhard Petracek [mailto:[EMAIL PROTECTED]
> *Sent:* Friday, April 04, 2008 2:47 PM
> *To:* MyFaces Development; [EMAIL PROTECTED]
> *Subject:* Re: [proposal] jsf validation with annotations
>
>
>
> hello kito,
>
> you can put every extension into a "commons" module.
>
> I see what you're saying. I suppose the main issue is the size of the
> module, and the number of perceived users.
>
> To be honest, I think Tomahawk is a better place for it, since Tomahawk
> contains a lot of stuff that belongs in the JSF core, like some basic
> validators.
>
> orchestra is about conversations and persistence
> and
> sev-en is about validation (simple and cross-component validation)
> at the moment i'm not aware of the difference.
>
> it might be ok to put specific sev-en annotation modules into the commons
> module (as i said - they are independent of the sev-en core).
>
> regards,
> gerhard
>
>
>  2008/4/4, Kito D. Mann <[EMAIL PROTECTED]>:
>
> Gerhard,
>
>
>
> Actually, it's different. Commons is a collection of useful utilities and
> features. Think of it in terms of the Apache Commons. Orchestra is about
> conversations and persistence contexts.
>
>
>
> ~~~
> Kito D. Mann - Author, JavaServer Faces in Action
> http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
> http://www.JSFCentral.com  - JavaServer Faces
> FAQ, news, and info
> phone: +1 203-653-2989
> fax: +1 203-653-2988
>
>
>
> *From:* Gerhard Petracek [mailto:[EMAIL PROTECTED]
> *Sent:* Friday, April 04, 2008 12:56 PM
> *To:* MyFaces Development
> *Subject:* Re: [proposal] jsf validation with annotations
>
>
>
> hello leonardo,
>
> concerning myfaces-commons-sev-en:
> i don't agree. it's similar if you suggest to merge myfaces-orchestra with
> myfaces-commons. - in my opinion that's not a good idea.
> sev-en should stay independent!
>
> + commons-sev-en sounds strage. :)
> (the pronunciation isn't [sev] ... [en] - it's like the 7 in english)
>
> regards,
> gerhard
>
>  2008/4/4, Leonardo Uribe <[EMAIL PROTECTED]>:
>
>
> I have tried the demo on my workstation, and in my opinion is a very cool
> idea and this should be on myfaces :)
>
> The idea of include with myfaces-commons sounds better that put this on
> orchestra (someone could want to use this only). Maybe
> myfaces-commons-sev-en.
>
> regards
>
> Leonardo Uribe
>
>
>
> On Fri, Apr 4, 2008 at 11:02 AM, Gerhard Petracek <
> [EMAIL PROTECTED]> wrote:
>
> hello andrew,
>
> sev-en is completely independent of orchestra or the idea behind it.
>
> regards,
> gerhard
>
>  2008/4/4, Andrew Robinson <[EMAIL PROTECTED]>:
>
> Since this is currently supported in Seam and Orchestra is a Seam
> spin-off/clone, perhaps this should be incorporated into Orchestra
> instead of yet another project.
>
>
> On Fri, Apr 4, 2008 at 4:45 AM, Matthias Wessendorf <[EMAIL PROTECTED]>
> wrote:
> > Hi,
> >
> >
> >  On Thu, Apr 3, 2008 at 10:11 PM, Gerhard Petracek
> >  <[EMAIL PROTECTED]> wrote:
> >  > sev-en is a new jsf-extension.
> >  >
> >  > sev-en allows jsf validation with annotations!
> >  >
> >  > some central features:
> >  > - cross-component validation (including cross-entity validation)
> >  >  - support for jpa based validation
> >  > - zero configuration
> >  > - extensible (e.g. custom annotations)
> >  >
> >  > you will find some previews (descriptions [1], examples [2] and much
> more)
> >  > at the sev-en section [3] of my new open source blog.
> >  >
> >  > what's your opinion about this extension?
> >
> >  sounds interesting. Is that levering the "bean validation" JSR ?
> >  Would be cool to have a little bit more standard oriented validation
> >  "framework".
> >  Otherwise (IMO) that would be just something similar to @Hibernate's
> validators
> >  (used heavily in Seam)
> >
> >  -M
> >
> >
> >
> >  >
> >  > regards,
> >  > gerhard
> >  >
> >  > [1] http://os890.blogspot.com/2008/03/new-jsf-extension.html
> >  > [2]
> http://os890.blogspot.com/2008/04/sev-en-preview-short-example.html
> >  >  [3] http://os890.blogspot.com/search/label/sev-en
> >  >
> >  > --
> >  >
> >  > http://www.irian.at
> >  >
> >  > Your JSF powerhouse -
> >  > JSF Consulting, Development and
> >  >  Courses in English and German
> >  >
> >  > Professional Support for Apache MyFaces
> >
> >
> >
> >  --
> >  Matthias Wessendorf
> >
> >  further stuff:
> >  blog: http://matthiaswessendorf.wordpress.com/
> >  session

Re: [proposal] jsf validation with annotations

[Gerhard Petracek]

hello,

maybe there is a misunderstanding in view of the used annotations, jsr 303
and so on.

as mentioned before:
the sev-en core is independent of specific annotations!
e.g. you can implement your own annotations [1]

regards,
gerhard

[1] http://os890.blogspot.com/2008/04/sev-en-preview-implement-your-own.html



2008/4/4, Kito D. Mann <[EMAIL PROTECTED]>:
>
>
>
> *From:* Gerhard Petracek [mailto:[EMAIL PROTECTED]
> *Sent:* Friday, April 04, 2008 2:47 PM
> *To:* MyFaces Development; [EMAIL PROTECTED]
> *Subject:* Re: [proposal] jsf validation with annotations
>
>
>
> hello kito,
>
> you can put every extension into a "commons" module.
>
> I see what you're saying. I suppose the main issue is the size of the
> module, and the number of perceived users.
>
> To be honest, I think Tomahawk is a better place for it, since Tomahawk
> contains a lot of stuff that belongs in the JSF core, like some basic
> validators.
>
> orchestra is about conversations and persistence
> and
> sev-en is about validation (simple and cross-component validation)
> at the moment i'm not aware of the difference.
>
> it might be ok to put specific sev-en annotation modules into the commons
> module (as i said - they are independent of the sev-en core).
>
> regards,
> gerhard
>
>
>  2008/4/4, Kito D. Mann <[EMAIL PROTECTED]>:
>
> Gerhard,
>
>
>
> Actually, it's different. Commons is a collection of useful utilities and
> features. Think of it in terms of the Apache Commons. Orchestra is about
> conversations and persistence contexts.
>
>
>
> ~~~
> Kito D. Mann - Author, JavaServer Faces in Action
> http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
> http://www.JSFCentral.com  - JavaServer Faces
> FAQ, news, and info
> phone: +1 203-653-2989
> fax: +1 203-653-2988
>
>
>
> *From:* Gerhard Petracek [mailto:[EMAIL PROTECTED]
> *Sent:* Friday, April 04, 2008 12:56 PM
> *To:* MyFaces Development
> *Subject:* Re: [proposal] jsf validation with annotations
>
>
>
> hello leonardo,
>
> concerning myfaces-commons-sev-en:
> i don't agree. it's similar if you suggest to merge myfaces-orchestra with
> myfaces-commons. - in my opinion that's not a good idea.
> sev-en should stay independent!
>
> + commons-sev-en sounds strage. :)
> (the pronunciation isn't [sev] ... [en] - it's like the 7 in english)
>
> regards,
> gerhard
>
>  2008/4/4, Leonardo Uribe <[EMAIL PROTECTED]>:
>
>
> I have tried the demo on my workstation, and in my opinion is a very cool
> idea and this should be on myfaces :)
>
> The idea of include with myfaces-commons sounds better that put this on
> orchestra (someone could want to use this only). Maybe
> myfaces-commons-sev-en.
>
> regards
>
> Leonardo Uribe
>
>
>
> On Fri, Apr 4, 2008 at 11:02 AM, Gerhard Petracek <
> [EMAIL PROTECTED]> wrote:
>
> hello andrew,
>
> sev-en is completely independent of orchestra or the idea behind it.
>
> regards,
> gerhard
>
>  2008/4/4, Andrew Robinson <[EMAIL PROTECTED]>:
>
> Since this is currently supported in Seam and Orchestra is a Seam
> spin-off/clone, perhaps this should be incorporated into Orchestra
> instead of yet another project.
>
>
> On Fri, Apr 4, 2008 at 4:45 AM, Matthias Wessendorf <[EMAIL PROTECTED]>
> wrote:
> > Hi,
> >
> >
> >  On Thu, Apr 3, 2008 at 10:11 PM, Gerhard Petracek
> >  <[EMAIL PROTECTED]> wrote:
> >  > sev-en is a new jsf-extension.
> >  >
> >  > sev-en allows jsf validation with annotations!
> >  >
> >  > some central features:
> >  > - cross-component validation (including cross-entity validation)
> >  >  - support for jpa based validation
> >  > - zero configuration
> >  > - extensible (e.g. custom annotations)
> >  >
> >  > you will find some previews (descriptions [1], examples [2] and much
> more)
> >  > at the sev-en section [3] of my new open source blog.
> >  >
> >  > what's your opinion about this extension?
> >
> >  sounds interesting. Is that levering the "bean validation" JSR ?
> >  Would be cool to have a little bit more standard oriented validation
> >  "framework".
> >  Otherwise (IMO) that would be just something similar to @Hibernate's
> validators
> >  (used heavily in Seam)
> >
> >  -M
> >
> >
> >
> >  >
> >  > regards,
> >  > gerhard
> >  >
> >  > [1] http://os890.blogspot.com/2008/03/new-jsf-extension.html
> >  > [2]
> http://os890.blogspot.com/2008/04/sev-en-preview-short-example.html
> >  >  [3] http://os890.blogspot.com/search/label/sev-en
> >  >
> >  > --
> >  >
> >  > http://www.irian.at
> >  >
> >  > Your JSF powerhouse -
> >  > JSF Consulting, Development and
> >  >  Courses in English and German
> >  >
> >  > Professional Support for Apache MyFaces
> >
> >
> >
> >  --
> >  Matthias Wessendorf
> >
> >  further stuff:
> >  blog: http://matthiaswessendorf.wordpress.com/
> >  sessions: http://www.slideshare.net/mwessendorf
> >  mail: matzew-at-apache-dot-org
> >
>
>
>
>
> --
>
>
> http://www.irian.at
>
> Your JSF powerhouse

RE: [proposal] jsf validation with annotations

[Kito D. Mann]

 

From: Gerhard Petracek [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 04, 2008 2:47 PM
To: MyFaces Development; [EMAIL PROTECTED]
Subject: Re: [proposal] jsf validation with annotations

 

hello kito,

you can put every extension into a "commons" module.

I see what you're saying. I suppose the main issue is the size of the
module, and the number of perceived users.

To be honest, I think Tomahawk is a better place for it, since Tomahawk
contains a lot of stuff that belongs in the JSF core, like some basic
validators. 

orchestra is about conversations and persistence
and
sev-en is about validation (simple and cross-component validation)
at the moment i'm not aware of the difference.

it might be ok to put specific sev-en annotation modules into the commons
module (as i said - they are independent of the sev-en core).

regards,
gerhard




2008/4/4, Kito D. Mann <[EMAIL PROTECTED]>:

Gerhard,

 

Actually, it's different. Commons is a collection of useful utilities and
features. Think of it in terms of the Apache Commons. Orchestra is about
conversations and persistence contexts. 

 

~~~
Kito D. Mann - Author, JavaServer Faces in Action
  http://www.virtua.com - JSF/Java EE consulting,
training, and mentoring
  http://www.JSFCentral.com - JavaServer Faces
FAQ, news, and info
phone: +1 203-653-2989
fax: +1 203-653-2988

 

From: Gerhard Petracek [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 04, 2008 12:56 PM
To: MyFaces Development
Subject: Re: [proposal] jsf validation with annotations

 

hello leonardo,

concerning myfaces-commons-sev-en:
i don't agree. it's similar if you suggest to merge myfaces-orchestra with
myfaces-commons. - in my opinion that's not a good idea.
sev-en should stay independent!

+ commons-sev-en sounds strage. :)
(the pronunciation isn't [sev] ... [en] - it's like the 7 in english)

regards,
gerhard



2008/4/4, Leonardo Uribe <[EMAIL PROTECTED]>:


I have tried the demo on my workstation, and in my opinion is a very cool
idea and this should be on myfaces :)

The idea of include with myfaces-commons sounds better that put this on
orchestra (someone could want to use this only). Maybe
myfaces-commons-sev-en.

regards

Leonardo Uribe

 

On Fri, Apr 4, 2008 at 11:02 AM, Gerhard Petracek
<[EMAIL PROTECTED]> wrote:

hello andrew,

sev-en is completely independent of orchestra or the idea behind it.

regards,
gerhard



2008/4/4, Andrew Robinson <[EMAIL PROTECTED]>:

Since this is currently supported in Seam and Orchestra is a Seam
spin-off/clone, perhaps this should be incorporated into Orchestra
instead of yet another project.


On Fri, Apr 4, 2008 at 4:45 AM, Matthias Wessendorf <[EMAIL PROTECTED]>
wrote:
> Hi,
>
>
>  On Thu, Apr 3, 2008 at 10:11 PM, Gerhard Petracek
>  <[EMAIL PROTECTED]> wrote:
>  > sev-en is a new jsf-extension.
>  >
>  > sev-en allows jsf validation with annotations!
>  >
>  > some central features:
>  > - cross-component validation (including cross-entity validation)
>  >  - support for jpa based validation
>  > - zero configuration
>  > - extensible (e.g. custom annotations)
>  >
>  > you will find some previews (descriptions [1], examples [2] and much
more)
>  > at the sev-en section [3] of my new open source blog.
>  >
>  > what's your opinion about this extension?
>
>  sounds interesting. Is that levering the "bean validation" JSR ?
>  Would be cool to have a little bit more standard oriented validation
>  "framework".
>  Otherwise (IMO) that would be just something similar to @Hibernate's
validators
>  (used heavily in Seam)
>
>  -M
>
>
>
>  >
>  > regards,
>  > gerhard
>  >
>  > [1] http://os890.blogspot.com/2008/03/new-jsf-extension.html
>  > [2] http://os890.blogspot.com/2008/04/sev-en-preview-short-example.html
>  >  [3] http://os890.blogspot.com/search/label/sev-en
>  >
>  > --
>  >
>  > http://www.irian.at
>  >
>  > Your JSF powerhouse -
>  > JSF Consulting, Development and
>  >  Courses in English and German
>  >
>  > Professional Support for Apache MyFaces
>
>
>
>  --
>  Matthias Wessendorf
>
>  further stuff:
>  blog: http://matthiaswessendorf.wordpress.com/
>  sessions: http://www.slideshare.net/mwessendorf
>  mail: matzew-at-apache-dot-org
>




-- 


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.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces 

Re: [proposal] jsf validation with annotations

[Gerhard Petracek]

hello kito,

you can put every extension into a "commons" module.

orchestra is about conversations and persistence
and
sev-en is about validation (simple and cross-component validation)
at the moment i'm not aware of the difference.

it might be ok to put specific sev-en annotation modules into the commons
module (as i said - they are independent of the sev-en core).

regards,
gerhard



2008/4/4, Kito D. Mann <[EMAIL PROTECTED]>:
>
>  Gerhard,
>
>
>
> Actually, it's different. Commons is a collection of useful utilities and
> features. Think of it in terms of the Apache Commons. Orchestra is about
> conversations and persistence contexts.
>
>
>
> ~~~
> Kito D. Mann - Author, JavaServer Faces in Action
> http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
> http://www.JSFCentral.com  - JavaServer Faces
> FAQ, news, and info
> phone: +1 203-653-2989
> fax: +1 203-653-2988
>
>
>
> *From:* Gerhard Petracek [mailto:[EMAIL PROTECTED]
> *Sent:* Friday, April 04, 2008 12:56 PM
> *To:* MyFaces Development
> *Subject:* Re: [proposal] jsf validation with annotations
>
>
>
> hello leonardo,
>
> concerning myfaces-commons-sev-en:
> i don't agree. it's similar if you suggest to merge myfaces-orchestra with
> myfaces-commons. - in my opinion that's not a good idea.
> sev-en should stay independent!
>
> + commons-sev-en sounds strage. :)
> (the pronunciation isn't [sev] ... [en] - it's like the 7 in english)
>
> regards,
> gerhard
>
>
>  2008/4/4, Leonardo Uribe <[EMAIL PROTECTED]>:
>
>
> I have tried the demo on my workstation, and in my opinion is a very cool
> idea and this should be on myfaces :)
>
> The idea of include with myfaces-commons sounds better that put this on
> orchestra (someone could want to use this only). Maybe
> myfaces-commons-sev-en.
>
> regards
>
> Leonardo Uribe
>
>
>
>  On Fri, Apr 4, 2008 at 11:02 AM, Gerhard Petracek <
> [EMAIL PROTECTED]> wrote:
>
> hello andrew,
>
> sev-en is completely independent of orchestra or the idea behind it.
>
> regards,
> gerhard
>
>
>  2008/4/4, Andrew Robinson <[EMAIL PROTECTED]>:
>
> Since this is currently supported in Seam and Orchestra is a Seam
> spin-off/clone, perhaps this should be incorporated into Orchestra
> instead of yet another project.
>
>
> On Fri, Apr 4, 2008 at 4:45 AM, Matthias Wessendorf <[EMAIL PROTECTED]>
> wrote:
> > Hi,
> >
> >
> >  On Thu, Apr 3, 2008 at 10:11 PM, Gerhard Petracek
> >  <[EMAIL PROTECTED]> wrote:
> >  > sev-en is a new jsf-extension.
> >  >
> >  > sev-en allows jsf validation with annotations!
> >  >
> >  > some central features:
> >  > - cross-component validation (including cross-entity validation)
> >  >  - support for jpa based validation
> >  > - zero configuration
> >  > - extensible (e.g. custom annotations)
> >  >
> >  > you will find some previews (descriptions [1], examples [2] and much
> more)
> >  > at the sev-en section [3] of my new open source blog.
> >  >
> >  > what's your opinion about this extension?
> >
> >  sounds interesting. Is that levering the "bean validation" JSR ?
> >  Would be cool to have a little bit more standard oriented validation
> >  "framework".
> >  Otherwise (IMO) that would be just something similar to @Hibernate's
> validators
> >  (used heavily in Seam)
> >
> >  -M
> >
> >
> >
> >  >
> >  > regards,
> >  > gerhard
> >  >
> >  > [1] http://os890.blogspot.com/2008/03/new-jsf-extension.html
> >  > [2]
> http://os890.blogspot.com/2008/04/sev-en-preview-short-example.html
> >  >  [3] http://os890.blogspot.com/search/label/sev-en
> >  >
> >  > --
> >  >
> >  > http://www.irian.at
> >  >
> >  > Your JSF powerhouse -
> >  > JSF Consulting, Development and
> >  >  Courses in English and German
> >  >
> >  > Professional Support for Apache MyFaces
> >
> >
> >
> >  --
> >  Matthias Wessendorf
> >
> >  further stuff:
> >  blog: http://matthiaswessendorf.wordpress.com/
> >  sessions: http://www.slideshare.net/mwessendorf
> >  mail: matzew-at-apache-dot-org
> >
>
>
>
>
> --
>
>
> 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.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

RE: MyfacesBuilderPlugin

[Kito D. Mann]

Simon,

Thanks for the recap. Guess I missed that discussion :-).

Whenever you guys get this one out of the door, make sure you devote an obvious 
Wiki location for it. That way, it'll be easier for people to document it. 
That’s a major issue with the Trinidad plugins :-).

~~~
Kito D. Mann - Author, JavaServer Faces in Action
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
phone: +1 203-653-2989
fax: +1 203-653-2988


> -Original Message-
> From: simon [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 04, 2008 2:29 AM
> To: 'MyFaces Development'
> Cc: Kito D. Mann
> Subject: RE: MyfacesBuilderPlugin
> 
> 
> On Thu, 2008-04-03 at 20:29 -0400, Kito D. Mann wrote:
> > Thanks for the explanation, Leonardo. I’m guessing that the Trinidad
> > plugin isn’t generic enough to be used outside of Trinidad?
> 
> No, the Trinidad plugin could be used elsewhere. In fact it has been
> used to build the myfaces-core 1.2.0 and 1.2.2 releases.
> 
> Work was then done to rename it to "myfaces-faces-plugin" just for
> tidiness (not released yet, but probably "late beta" state as it's
> mostly a rename of existing code). Some work was then done to start
> converting Tomahawk to use this (beta) plugin.
> 
> But then there was a lot of discussion on the dev list; some people
> (particularly me) did not think the trinidad-plugin approach was very
> elegant, and did not want it to spread across the whole set of myfaces
> projects. You can see the discussion in the mail archives, and more
> info
> here:
>   http://wiki.apache.org/myfaces/MyfacesBuilderPlugin
> 
> As there was reasonable support for an alternative "annotation-driven"
> approach, I created a prototype implementation. People seem reasonably
> happy with the approach, and Leonardo is now doing some great work
> extending the initial code (in particular, adding the "back end" part).
> This new plugin is 95% new code, with just a little bit borrowed from
> the trinidad plugin project.
> 
> At some point I guess there will need to be an official vote on which
> plugin will be used for myfaces core 1.1, core1.2 and tomahawk. *If*
> the
> "myfaces-builder-plugin" is chosen, then the Trinidad team will need to
> decide whether to stay with their existing plugin or change over.
> Tobago
> has its own plugin for similar purposes; their approach is much more
> like the myfaces-builder-plugin proposal than the trinidad-plugin
> approach. Again, it would be up to the Tobago team to decide whether to
> try to join forces or not.
> 
> Regards,
> Simon
> 
> 
> 
> 
> 
> >
> > From: Leonardo Uribe [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, April 03, 2008 7:50 PM
> > To: MyFaces Development; [EMAIL PROTECTED]
> > Subject: Re: MyfacesBuilderPlugin
> >
> >
> >
> >
> >
> >
> > On Thu, Apr 3, 2008 at 11:31 AM, Kito D. Mann <[EMAIL PROTECTED]>
> > wrote:
> >
> > Is the MyfacesBuilderPlugin completely separate from the Trinidad
> > Maven Plugins?
> >
> >
> >
> > Actually is a branch developed inside build-tools. There is no
> > official vote yet about if this plugin will be used on trinidad,
> since
> > myfaces-faces-plugin (or maven-faces-plugin on trinidadbuild) are
> > working and works very well. Theorically, after a votation this
> plugin
> > could be used on myfaces and tomahawk.
> >
> >
> >
> >
> >
> >
> ~~~
> > Kito D. Mann - Author, JavaServer Faces in Action
> > http://www.virtua.com - JSF/Java EE consulting, training, and
> > mentoring
> > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and
> > info
> > phone: +1 203-653-2989
> > fax: +1 203-653-2988
> >
> >
> >
> > From: Leonardo Uribe [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, April 02, 2008 9:53 PM
> > To: MyFaces Development
> > Subject: Re: MyfacesBuilderPlugin
> >
> >
> >
> >
> > Hi
> >
> > I have a design question. I'm working on generate component
> > tag classes using velocity.
> >
> > In this part it is common to found some situations when you
> > need utility methods. There are several methods
> > to do this:
> >
> > 1) Implementing this methods on a java class, and use the
> > following code using a macro file on inside the template:
> >
> > ## [ Setting Utility Classes to use ]
> > ##
> > #set($utils =
> >
> $classes.forName("org.apache.commons.lang.StringUtils").newInstance())
> >
> > In this case, we can copy
> > org.apache.myfaces.buildtools.maven2.plugin.faces.util.Util
> > form myfaces-faces-plugin and use it
> > inside the templates. like this
> >
> > $utils.lowerCase($field.getAttributeValue("name"))
> >
> > 2) Use a file to create velocity macros

RE: [proposal] jsf validation with annotations

[Kito D. Mann]

Gerhard,

 

Actually, it's different. Commons is a collection of useful utilities and
features. Think of it in terms of the Apache Commons. Orchestra is about
conversations and persistence contexts. 

 

~~~
Kito D. Mann - Author, JavaServer Faces in Action
  http://www.virtua.com - JSF/Java EE consulting,
training, and mentoring
  http://www.JSFCentral.com - JavaServer Faces
FAQ, news, and info
phone: +1 203-653-2989
fax: +1 203-653-2988

 

From: Gerhard Petracek [mailto:[EMAIL PROTECTED] 
Sent: Friday, April 04, 2008 12:56 PM
To: MyFaces Development
Subject: Re: [proposal] jsf validation with annotations

 

hello leonardo,

concerning myfaces-commons-sev-en:
i don't agree. it's similar if you suggest to merge myfaces-orchestra with
myfaces-commons. - in my opinion that's not a good idea.
sev-en should stay independent!

+ commons-sev-en sounds strage. :)
(the pronunciation isn't [sev] ... [en] - it's like the 7 in english)

regards,
gerhard




2008/4/4, Leonardo Uribe <[EMAIL PROTECTED]>:


I have tried the demo on my workstation, and in my opinion is a very cool
idea and this should be on myfaces :)

The idea of include with myfaces-commons sounds better that put this on
orchestra (someone could want to use this only). Maybe
myfaces-commons-sev-en.

regards

Leonardo Uribe





On Fri, Apr 4, 2008 at 11:02 AM, Gerhard Petracek
<[EMAIL PROTECTED]> wrote:

hello andrew,

sev-en is completely independent of orchestra or the idea behind it.

regards,
gerhard




2008/4/4, Andrew Robinson <[EMAIL PROTECTED]>:

Since this is currently supported in Seam and Orchestra is a Seam
spin-off/clone, perhaps this should be incorporated into Orchestra
instead of yet another project.


On Fri, Apr 4, 2008 at 4:45 AM, Matthias Wessendorf <[EMAIL PROTECTED]>
wrote:
> Hi,
>
>
>  On Thu, Apr 3, 2008 at 10:11 PM, Gerhard Petracek
>  <[EMAIL PROTECTED]> wrote:
>  > sev-en is a new jsf-extension.
>  >
>  > sev-en allows jsf validation with annotations!
>  >
>  > some central features:
>  > - cross-component validation (including cross-entity validation)
>  >  - support for jpa based validation
>  > - zero configuration
>  > - extensible (e.g. custom annotations)
>  >
>  > you will find some previews (descriptions [1], examples [2] and much
more)
>  > at the sev-en section [3] of my new open source blog.
>  >
>  > what's your opinion about this extension?
>
>  sounds interesting. Is that levering the "bean validation" JSR ?
>  Would be cool to have a little bit more standard oriented validation
>  "framework".
>  Otherwise (IMO) that would be just something similar to @Hibernate's
validators
>  (used heavily in Seam)
>
>  -M
>
>
>
>  >
>  > regards,
>  > gerhard
>  >
>  > [1] http://os890.blogspot.com/2008/03/new-jsf-extension.html
>  > [2] http://os890.blogspot.com/2008/04/sev-en-preview-short-example.html
>  >  [3] http://os890.blogspot.com/search/label/sev-en
>  >
>  > --
>  >
>  > http://www.irian.at
>  >
>  > Your JSF powerhouse -
>  > JSF Consulting, Development and
>  >  Courses in English and German
>  >
>  > Professional Support for Apache MyFaces
>
>
>
>  --
>  Matthias Wessendorf
>
>  further stuff:
>  blog: http://matthiaswessendorf.wordpress.com/
>  sessions: http://www.slideshare.net/mwessendorf
>  mail: matzew-at-apache-dot-org
>




-- 


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 

RE: shale-test location (was RE: JSF 2.0 component set)

[Kito D. Mann]

> -Original Message-
> From: Scott O'Bryan [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 04, 2008 12:12 PM
> To: MyFaces Development
> Subject: Re: shale-test location (was RE: JSF 2.0 component set)
> 
> Yeah, the conversation has already gone on longer then I intended.  I
> was merely expressing sentiments that the moving of shale-test is not
> something I would oppose.  It is frustrating though to have to port the
> bridges ExternalContext logic to another platform.  The logic in JSF is
> largely tivial, but the Bridge environment has some extra complexities.
> 
> Understand also that I was in no way proposing the need to make
> configuration of your webapp matter for your test environment.  Just
> because one may use a piece of implementation from another project
> doesn't mean you need to use the whole thing.  My point was that much
> of
> the code in shale-test is unnecessary *IF* you are able to leverage the
> same work from an already built faces container.  This is something
> that
> shale cannot do currently and it leaves maintenance for changes to
> ExternalContext (in both the portal and servlet environments)
> co-existing in two locations.
> 
> Moving on, Gary, since your a PMC of shale, what would be the chances
> that we can add Portlet 1.0/JSF 1.2 testcases to shale-test.  I believe
> Kito was looking at doing some of this work and I would be interrested
> also.  I know that the Bridge can certainly use it (not necessarily for
> the TCK, but for build-time unit tests, and certainly my
> myfaces-commons-configurator project and my ExternalContextUtils in the
> myfaces-commons-util.  Would the community be open to adding portlet
> support?

I'm certainly willing to help. There are some changes I'd like to make for
shale-test in general anyway.

> Paul Spencer wrote:
> > Gary,
> > I also use shale-test.  One of the feature in the unreleased 1.1.0
> > allows you the test against any JSF 1.1/1.2 implementation without
> > having to replace the faces.xml configuration inside the test.  Thus
> > keeping the test framework independent from an implantation. Which is
> a
> > good thing and something I support.  Gary VanMatre has been named
> > Shale's PMC, and hopefully he, with our help, will revive the
> community.
> >
> > FYI: Their have been many threads related to moving parts of Shale
> into
> > MyFaces.  Lets not start another one while Shale is still alive.
> >
> >
> > Paul Spencer
> >
> >
> >
> >
> > Gary VanMatre wrote:
> >>  -- Original message --
> >> From: "Scott O'Bryan" <[EMAIL PROTECTED]>
>  I don't really see why the physical location affects the ability
> to
>  fix bugs
>  or do enhancements in parallel, unless it depends on some common
>  implementation classes. Or, are you talking more about releases?
> 
> >>> Well releases are part of it.  I was meerly bringing up that the
> >>> Bridge (even MyFaces) have impls which perform the logic for
> >>> "ExternalContext" expected of their various specs.  These are
> >>> duplicated somewhat in the shale-tests.  If it were moved over to
> >>> faces, both the core-team and the bridge team would be able to
> >>> maintain the test harnesses with the code they are writing.  For
> >>> instance, Mock the Bridge and Servlet API's and Mock the
> >>> FacesContextFactory.  It would, in turn, return an ExternalContext
> >>> which (while being based off the myfaces or bridge impl) would also
> >>> expose the setters needed to test thing.  But ultimately, the
> >>> underlying implementations would run under the covers.  This would
> >>> much easier reflect reality.
> >>>
> >>> That said, I was just bringing up the idea that I wouldn't argue
> >>> against it.  The Bridge (and some of the projects I'm doing in
> >>> commons) need released versions of a portlet test harness and I
> >>> wouldn't mind adding these test cases to Trinidad either.  Whether
> I
> >>> pull them from Shale or MyFaces makes no real difference to me, but
> >>> I could help maintain them better if they were in MyFaces -- for a
> >>> current committer of shale I am not.  :)
> >>>
> >>
> >> Well, I'm not a MyFaces committer either.  Ok, I'll bore you - I had
> >> to work on Clay under Struts for 6 months submitting patches to the
> >> code I contributed before I
> >> was nominated to join.
> >> Of course, that was then and this is now but I'd like to see Shale
> >> grow as a community.
> >> The reality is that the majority of Shale was Craig's work.  I don't
> >> think that anyone would
> >> dispute that. David Geary also had a hand in the inception.   That's
> >> why I'm into the all or nothing versus the cafeteria plan.  Shale
> >> test is one of the nuggets.  The annotation and remoting are also
> >> being used as the foundation - point of discussion for JSF 2.0.
> >> Shale controller + shale dialog is a simplified version of ADFc 11g.
> >> I don't know...  I think we all know how to work together amongst
> >> apache comm

RE: shale-test location (was RE: JSF 2.0 component set)

[Kito D. Mann]

> -Original Message-
> From: Scott O'Bryan [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 03, 2008 6:39 PM
> To: [EMAIL PROTECTED]
> Cc: 'MyFaces Development'; 'Gary VanMatre'
> Subject: Re: shale-test location (was RE: JSF 2.0 component set)
> 
> 
> > I don't really see why the physical location affects the ability to
> fix bugs
> > or do enhancements in parallel, unless it depends on some common
> > implementation classes. Or, are you talking more about releases?
> >
> Well releases are part of it.  I was meerly bringing up that the Bridge
> (even MyFaces) have impls which perform the logic for "ExternalContext"
> expected of their various specs.  These are duplicated somewhat in the
> shale-tests.  If it were moved over to faces, both the core-team and
> the
> bridge team would be able to maintain the test harnesses with the code
> they are writing.  For instance, Mock the Bridge and Servlet API's and
> Mock the FacesContextFactory.  It would, in turn, return an
> ExternalContext which (while being based off the myfaces or bridge
> impl)
> would also expose the setters needed to test thing.  But ultimately,
> the
> underlying implementations would run under the covers.  This would much
> easier reflect reality.

I don't see why you still can't use the internals of these projects, though.
Either way, it increases the number of dependencies for shale-test. 


> That said, I was just bringing up the idea that I wouldn't argue
> against
> it.  The Bridge (and some of the projects I'm doing in commons) need
> released versions of a portlet test harness and I wouldn't mind adding
> these test cases to Trinidad either.  Whether I pull them from Shale or
> MyFaces makes no real difference to me, but I could help maintain them
> better if they were in MyFaces -- for a current committer of shale I am
> not.  :)

Fair enough.

> 
> Scott
> > Well, I'm happy whether it's in MyFaces or Shale, as long as we can
> update
> > it for JSF 1.2 and the Bridge. So, if you want it to be part of
> MyFaces and
> > are willing to deal with the work of getting it established, I think
> you'd
> > have a good case.
> >
> > What do others think (especially Gary)?
> >
> >
> >> Kito D. Mann wrote:
> >>
> >>> *From:* Gary VanMatre [mailto:[EMAIL PROTECTED]
> >>> *Sent:* Wednesday, April 02, 2008 11:16 AM
> >>> *To:* MyFaces Development; [EMAIL PROTECTED]; 'MyFaces Development'
> >>> *Cc:* Kito D. Mann
> >>> *Subject:* RE: JSF 2.0 component set
> >>>
> >>>
>  From: "Kito D. Mann" <[EMAIL PROTECTED]>
> 
>  I just want to add that when we were talking about moving Shale
> 
> >> over to
> >>
>  MyFaces, people were worried about resources for maintaining it.
> 
> >> And
> >>
> >>> Shale
> >>>
>  is an *existing* code base :-). I think it'd make a lot more sense
> 
> >> to
> >>
>  migrate the existing suites to JSF 2 branches.
> 
> 
> >>> The big issue I had with merging was that the majority didn't want
> to
> >>> bring over all of shale. At this point, I don't think it would be
> >>> responsible just to drop support unless you could offer a
> comparable
> >>> feature.
> >>>
> >>> True. I thought it might make sense to bring the biggest pieces
> over
> >>> to MyFaces, but if we can revive part of Shale's development, I'm
> >>>
> >> fine
> >>
> >>> with that too. I just wanted to avoid atrophy of the entire Shale
> >>>
> >> code
> >>
> >>> base :-).
> >>>
> >>> The shale's test library is one of the few that have not been
> >>> reinvented over and over and that seemed to be where the root
> >>>
> >> interest
> >>
> >>> is with myfaces.
> >>>
> >>> In terms of maintaining Shale, we most certainly encourage
> >>> contributions the same as myfaces :-)
> >>>
> >>> Of course :-).
> >>>
> >>> Gary
> >>>
> >>>
> >>>
> 
> ~~~
>  Kito D. Mann - Author, JavaServer Faces in Action
>  http://www.virtua.com - JSF/Java EE consulting, training, and
> 
> >> mentoring
> >>
>  http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
>  phone: +1 203-653-2989
>  fax: +1 203-653-2988
> 
> 
> 
> > -Original Message-
> > From: Scott O'Bryan [mailto:[EMAIL PROTECTED]
> > Sent: Monday, March 31, 2008 4:39 PM
> > To: MyFaces Development
> > Subject: Re: JSF 2.0 component set
> >
> > Bruno, I totally agree, but we don't want a lot of dead projects
> >
> >> out
> >>
> > there either. My point, and I think Simon's as well, is that much
> >
> >> of
> >>
> > the contributions to the MyFaces Projects and renderkits comes
> >
> >> from
> >>
> > companies and individuals who have a vested interest in
> >
> >> supporting
> >>
> >>> the
> >>>
> > exis! ting re nderkits going forward. Getting MyFaces core up to
> >
> >>> 2.0 is
> >>>
> > going to take away interest from the new project as is getting
> > renderkits like Trinidad to b

[jira] Commented: (ORCHESTRA-19) refactor conversationContext to allow nested conversationContext

[Mario Ivankovits (JIRA)]

[ 
https://issues.apache.org/jira/browse/ORCHESTRA-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585651#action_12585651
 ] 

Mario Ivankovits commented on ORCHESTRA-19:
---

The conversationContext api needs to be enhanced to get access to specific 
types of conversationContext.

* byId (already there)
* byName (user definable name)
* byType (e.g. find the one responsible for the window data)

> refactor conversationContext to allow nested conversationContext
> 
>
> Key: ORCHESTRA-19
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-19
> Project: MyFaces Orchestra
>  Issue Type: Improvement
>  Components: Conversation
>Reporter: Mario Ivankovits
>
> The conversationContext should be enhanced to allow nested 
> conversationContext which is a requirement for dialog/flow implementations to 
> separate the conversations for different flows.
> The new conversationContext should be able to handle:
> * a conversation context per windows
> * multiple named conversationContexts
> * a stack of conversationContexts to fulfill the requirement a dialog 
> framework has with its subflows
> Technically this might all be the same conversationContext implementation 
>  probably.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ORCHESTRA-19) refactor conversationContext to allow nested conversationContext

[Mario Ivankovits (JIRA)]

[ 
https://issues.apache.org/jira/browse/ORCHESTRA-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585648#action_12585648
 ] 

Mario Ivankovits commented on ORCHESTRA-19:
---

The conversationContext URL parameter might hold the bottom conversationContext 
id.

> refactor conversationContext to allow nested conversationContext
> 
>
> Key: ORCHESTRA-19
> URL: https://issues.apache.org/jira/browse/ORCHESTRA-19
> Project: MyFaces Orchestra
>  Issue Type: Improvement
>  Components: Conversation
>Reporter: Mario Ivankovits
>
> The conversationContext should be enhanced to allow nested 
> conversationContext which is a requirement for dialog/flow implementations to 
> separate the conversations for different flows.
> The new conversationContext should be able to handle:
> * a conversation context per windows
> * multiple named conversationContexts
> * a stack of conversationContexts to fulfill the requirement a dialog 
> framework has with its subflows
> Technically this might all be the same conversationContext implementation 
>  probably.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (ORCHESTRA-20) single conversation

[Mario Ivankovits (JIRA)]

single conversation
---

 Key: ORCHESTRA-20
 URL: https://issues.apache.org/jira/browse/ORCHESTRA-20
 Project: MyFaces Orchestra
  Issue Type: Improvement
  Components: Conversation
Reporter: Mario Ivankovits


Create an implementation of a "single conversation".

A dialog/flow framework will create new conversationContexts instead of direct 
conversations.

While you still will be able to use conversation.manual or conversation.access 
it makes sense to also provide a conversation.single implementation which 
shares the lifetime of the conversationContext (managed by the dialog 
framework) and has only one (single) persistence context.

Still, mixing the various conversation implementations is possible.

Probably Conversation.getCurrentInstance() outside of a conversation will 
return this single conversation if it exists within the current 
conversationContext.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [proposal] jsf validation with annotations

[Gerhard Petracek]

hello leonardo,

that's ok! :)
it's great to have these discussions.

regards,
gerhard



2008/4/4, Leonardo Uribe <[EMAIL PROTECTED]>:
>
>
> On Fri, Apr 4, 2008 at 11:56 AM, Gerhard Petracek <
> [EMAIL PROTECTED]> wrote:
>
> > hello leonardo,
> >
> > concerning myfaces-commons-sev-en:
> > i don't agree. it's similar if you suggest to merge myfaces-orchestra
> > with myfaces-commons. - in my opinion that's not a good idea.
> > sev-en should stay independent!
> >
> > + commons-sev-en sounds strage. :)
> > (the pronunciation isn't [sev] ... [en] - it's like the 7 in english)
> >
>
> Ok, the idea is explore all possibilities and take the best.
>
>
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2008/4/4, Leonardo Uribe <[EMAIL PROTECTED]>:
> >
> > >
> > > I have tried the demo on my workstation, and in my opinion is a very
> > > cool idea and this should be on myfaces :)
> > >
> > > The idea of include with myfaces-commons sounds better that put this
> > > on orchestra (someone could want to use this only). Maybe
> > > myfaces-commons-sev-en.
> > >
> > > regards
> > >
> > > Leonardo Uribe
> > >
> > >
> > > On Fri, Apr 4, 2008 at 11:02 AM, Gerhard Petracek <
> > > [EMAIL PROTECTED]> wrote:
> > >
> > > > hello andrew,
> > > >
> > > > sev-en is completely independent of orchestra or the idea behind it.
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2008/4/4, Andrew Robinson <[EMAIL PROTECTED]>:
> > > >
> > > > > Since this is currently supported in Seam and Orchestra is a Seam
> > > > > spin-off/clone, perhaps this should be incorporated into Orchestra
> > > > > instead of yet another project.
> > > > >
> > > > >
> > > > > On Fri, Apr 4, 2008 at 4:45 AM, Matthias Wessendorf <
> > > > > [EMAIL PROTECTED]> wrote:
> > > > > > Hi,
> > > > > >
> > > > > >
> > > > > >  On Thu, Apr 3, 2008 at 10:11 PM, Gerhard Petracek
> > > > > >  <[EMAIL PROTECTED]> wrote:
> > > > > >  > sev-en is a new jsf-extension.
> > > > > >  >
> > > > > >  > sev-en allows jsf validation with annotations!
> > > > > >  >
> > > > > >  > some central features:
> > > > > >  > - cross-component validation (including cross-entity
> > > > > validation)
> > > > > >  >  - support for jpa based validation
> > > > > >  > - zero configuration
> > > > > >  > - extensible (e.g. custom annotations)
> > > > > >  >
> > > > > >  > you will find some previews (descriptions [1], examples [2]
> > > > > and much more)
> > > > > >  > at the sev-en section [3] of my new open source blog.
> > > > > >  >
> > > > > >  > what's your opinion about this extension?
> > > > > >
> > > > > >  sounds interesting. Is that levering the "bean validation" JSR
> > > > > ?
> > > > > >  Would be cool to have a little bit more standard oriented
> > > > > validation
> > > > > >  "framework".
> > > > > >  Otherwise (IMO) that would be just something similar to
> > > > > @Hibernate's validators
> > > > > >  (used heavily in Seam)
> > > > > >
> > > > > >  -M
> > > > > >
> > > > > >
> > > > > >
> > > > > >  >
> > > > > >  > regards,
> > > > > >  > gerhard
> > > > > >  >
> > > > > >  > [1] http://os890.blogspot.com/2008/03/new-jsf-extension.html
> > > > > >  > [2]
> > > > > http://os890.blogspot.com/2008/04/sev-en-preview-short-example.html
> > > > > >  >  [3] http://os890.blogspot.com/search/label/sev-en
> > > > > >  >
> > > > > >  > --
> > > > > >  >
> > > > > >  > http://www.irian.at
> > > > > >  >
> > > > > >  > Your JSF powerhouse -
> > > > > >  > JSF Consulting, Development and
> > > > > >  >  Courses in English and German
> > > > > >  >
> > > > > >  > Professional Support for Apache MyFaces
> > > > > >
> > > > > >
> > > > > >
> > > > > >  --
> > > > > >  Matthias Wessendorf
> > > > > >
> > > > > >  further stuff:
> > > > > >  blog: http://matthiaswessendorf.wordpress.com/
> > > > > >  sessions: http://www.slideshare.net/mwessendorf
> > > > > >  mail: matzew-at-apache-dot-org
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > >
> > > > 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.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

[jira] Created: (ORCHESTRA-19) refactor conversationContext to allow nested conversationContext

[Mario Ivankovits (JIRA)]

refactor conversationContext to allow nested conversationContext


 Key: ORCHESTRA-19
 URL: https://issues.apache.org/jira/browse/ORCHESTRA-19
 Project: MyFaces Orchestra
  Issue Type: Improvement
  Components: Conversation
Reporter: Mario Ivankovits


The conversationContext should be enhanced to allow nested conversationContext 
which is a requirement for dialog/flow implementations to separate the 
conversations for different flows.

The new conversationContext should be able to handle:
* a conversation context per windows
* multiple named conversationContexts
* a stack of conversationContexts to fulfill the requirement a dialog framework 
has with its subflows

Technically this might all be the same conversationContext implementation  
probably.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [proposal] jsf validation with annotations

[Leonardo Uribe]

On Fri, Apr 4, 2008 at 11:56 AM, Gerhard Petracek <
[EMAIL PROTECTED]> wrote:

> hello leonardo,
>
> concerning myfaces-commons-sev-en:
> i don't agree. it's similar if you suggest to merge myfaces-orchestra with
> myfaces-commons. - in my opinion that's not a good idea.
> sev-en should stay independent!
>
> + commons-sev-en sounds strage. :)
> (the pronunciation isn't [sev] ... [en] - it's like the 7 in english)
>

Ok, the idea is explore all possibilities and take the best.


>
> regards,
> gerhard
>
>
>
> 2008/4/4, Leonardo Uribe <[EMAIL PROTECTED]>:
>
> >
> > I have tried the demo on my workstation, and in my opinion is a very
> > cool idea and this should be on myfaces :)
> >
> > The idea of include with myfaces-commons sounds better that put this on
> > orchestra (someone could want to use this only). Maybe
> > myfaces-commons-sev-en.
> >
> > regards
> >
> > Leonardo Uribe
> >
> >
> > On Fri, Apr 4, 2008 at 11:02 AM, Gerhard Petracek <
> > [EMAIL PROTECTED]> wrote:
> >
> > > hello andrew,
> > >
> > > sev-en is completely independent of orchestra or the idea behind it.
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2008/4/4, Andrew Robinson <[EMAIL PROTECTED]>:
> > >
> > > > Since this is currently supported in Seam and Orchestra is a Seam
> > > > spin-off/clone, perhaps this should be incorporated into Orchestra
> > > > instead of yet another project.
> > > >
> > > >
> > > > On Fri, Apr 4, 2008 at 4:45 AM, Matthias Wessendorf <
> > > > [EMAIL PROTECTED]> wrote:
> > > > > Hi,
> > > > >
> > > > >
> > > > >  On Thu, Apr 3, 2008 at 10:11 PM, Gerhard Petracek
> > > > >  <[EMAIL PROTECTED]> wrote:
> > > > >  > sev-en is a new jsf-extension.
> > > > >  >
> > > > >  > sev-en allows jsf validation with annotations!
> > > > >  >
> > > > >  > some central features:
> > > > >  > - cross-component validation (including cross-entity
> > > > validation)
> > > > >  >  - support for jpa based validation
> > > > >  > - zero configuration
> > > > >  > - extensible (e.g. custom annotations)
> > > > >  >
> > > > >  > you will find some previews (descriptions [1], examples [2] and
> > > > much more)
> > > > >  > at the sev-en section [3] of my new open source blog.
> > > > >  >
> > > > >  > what's your opinion about this extension?
> > > > >
> > > > >  sounds interesting. Is that levering the "bean validation" JSR ?
> > > > >  Would be cool to have a little bit more standard oriented
> > > > validation
> > > > >  "framework".
> > > > >  Otherwise (IMO) that would be just something similar to
> > > > @Hibernate's validators
> > > > >  (used heavily in Seam)
> > > > >
> > > > >  -M
> > > > >
> > > > >
> > > > >
> > > > >  >
> > > > >  > regards,
> > > > >  > gerhard
> > > > >  >
> > > > >  > [1] http://os890.blogspot.com/2008/03/new-jsf-extension.html
> > > > >  > [2]
> > > > http://os890.blogspot.com/2008/04/sev-en-preview-short-example.html
> > > > >  >  [3] http://os890.blogspot.com/search/label/sev-en
> > > > >  >
> > > > >  > --
> > > > >  >
> > > > >  > http://www.irian.at
> > > > >  >
> > > > >  > Your JSF powerhouse -
> > > > >  > JSF Consulting, Development and
> > > > >  >  Courses in English and German
> > > > >  >
> > > > >  > Professional Support for Apache MyFaces
> > > > >
> > > > >
> > > > >
> > > > >  --
> > > > >  Matthias Wessendorf
> > > > >
> > > > >  further stuff:
> > > > >  blog: http://matthiaswessendorf.wordpress.com/
> > > > >  sessions: http://www.slideshare.net/mwessendorf
> > > > >  mail: matzew-at-apache-dot-org
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > > 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
>

Re: [proposal] jsf validation with annotations

[Gerhard Petracek]

hello leonardo,

concerning myfaces-commons-sev-en:
i don't agree. it's similar if you suggest to merge myfaces-orchestra with
myfaces-commons. - in my opinion that's not a good idea.
sev-en should stay independent!

+ commons-sev-en sounds strage. :)
(the pronunciation isn't [sev] ... [en] - it's like the 7 in english)

regards,
gerhard



2008/4/4, Leonardo Uribe <[EMAIL PROTECTED]>:
>
>
> I have tried the demo on my workstation, and in my opinion is a very cool
> idea and this should be on myfaces :)
>
> The idea of include with myfaces-commons sounds better that put this on
> orchestra (someone could want to use this only). Maybe
> myfaces-commons-sev-en.
>
> regards
>
> Leonardo Uribe
>
>
> On Fri, Apr 4, 2008 at 11:02 AM, Gerhard Petracek <
> [EMAIL PROTECTED]> wrote:
>
> > hello andrew,
> >
> > sev-en is completely independent of orchestra or the idea behind it.
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2008/4/4, Andrew Robinson <[EMAIL PROTECTED]>:
> >
> > > Since this is currently supported in Seam and Orchestra is a Seam
> > > spin-off/clone, perhaps this should be incorporated into Orchestra
> > > instead of yet another project.
> > >
> > >
> > > On Fri, Apr 4, 2008 at 4:45 AM, Matthias Wessendorf <[EMAIL PROTECTED]>
> > > wrote:
> > > > Hi,
> > > >
> > > >
> > > >  On Thu, Apr 3, 2008 at 10:11 PM, Gerhard Petracek
> > > >  <[EMAIL PROTECTED]> wrote:
> > > >  > sev-en is a new jsf-extension.
> > > >  >
> > > >  > sev-en allows jsf validation with annotations!
> > > >  >
> > > >  > some central features:
> > > >  > - cross-component validation (including cross-entity validation)
> > > >  >  - support for jpa based validation
> > > >  > - zero configuration
> > > >  > - extensible (e.g. custom annotations)
> > > >  >
> > > >  > you will find some previews (descriptions [1], examples [2] and
> > > much more)
> > > >  > at the sev-en section [3] of my new open source blog.
> > > >  >
> > > >  > what's your opinion about this extension?
> > > >
> > > >  sounds interesting. Is that levering the "bean validation" JSR ?
> > > >  Would be cool to have a little bit more standard oriented
> > > validation
> > > >  "framework".
> > > >  Otherwise (IMO) that would be just something similar to
> > > @Hibernate's validators
> > > >  (used heavily in Seam)
> > > >
> > > >  -M
> > > >
> > > >
> > > >
> > > >  >
> > > >  > regards,
> > > >  > gerhard
> > > >  >
> > > >  > [1] http://os890.blogspot.com/2008/03/new-jsf-extension.html
> > > >  > [2]
> > > http://os890.blogspot.com/2008/04/sev-en-preview-short-example.html
> > > >  >  [3] http://os890.blogspot.com/search/label/sev-en
> > > >  >
> > > >  > --
> > > >  >
> > > >  > http://www.irian.at
> > > >  >
> > > >  > Your JSF powerhouse -
> > > >  > JSF Consulting, Development and
> > > >  >  Courses in English and German
> > > >  >
> > > >  > Professional Support for Apache MyFaces
> > > >
> > > >
> > > >
> > > >  --
> > > >  Matthias Wessendorf
> > > >
> > > >  further stuff:
> > > >  blog: http://matthiaswessendorf.wordpress.com/
> > > >  sessions: http://www.slideshare.net/mwessendorf
> > > >  mail: matzew-at-apache-dot-org
> > > >
> > >
> >
> >
> >
> > --
> >
> > 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

Re: MyfacesBuilderPlugin

[Leonardo Uribe]

On Thu, Apr 3, 2008 at 6:56 PM, Mike Kienenberger <[EMAIL PROTECTED]>
wrote:

> On Thu, Apr 3, 2008 at 7:44 PM, Leonardo Uribe <[EMAIL PROTECTED]> wrote:
> > The drawback
> >  is that creates a log file on the project folder (I'm not found how to
> > output the log on the screen yet!).
>
> Have you looked at this page?
>
>
> http://velocity.apache.org/engine/devel/developer-guide.html#configuring_logging
>
> Here are some specific examples:
>
> http://www.java2s.com/Code/Java/Velocity/Velocity-Log.htm
>

I have readed the developer guide again and with the examples on the second
link the problem is fixed. Thanks for the tips

regards

Leonardo Uribe

Re: tobago island logo :)

[Matthias Wessendorf]

I like it!

On Fri, Apr 4, 2008 at 6:26 PM, Adonis Raduca <[EMAIL PROTECTED]> wrote:
>
>
>
> Hi Udo,
>
> I designed a Tobago island logo for you.
> What do you think, it is OK now ?
>
> Have a nice evening !
> Adonis
>
> On Thu, Apr 3, 2008 at 1:27 PM, Udo Schnurpfeil <[EMAIL PROTECTED]> wrote:
>
> > Hallo Adonis,
> >
> > thank you for your good work. But for the Tobago project it would be nice
> to have a (abstract) shape of the island. Volker has asked for that also.
> > The logo looks good, but it doesn't really fit to the Tobago project,
> because the shape of the island is the logo from the beginning of the
> project.
> >
> > You might use the shape in green, and the small islands (little tobago,
> goat island, st. giles island, and may be bucco reef, sisters/brothers
> rocks) as brown circles. Or the hills in the middle in brown?
> >
> > Could you do me a favour and make a sample?
> >
> > Here are some maps of tobago:
> > http://www.abrahamrealty.com/images/tobagomap.gif
> > http://www.exploretobago.com/tobago/tobagodetailmap.jpg
> >
> > There are also logos in the existing svn:
> >
> http://svn.apache.org/repos/asf/myfaces/tobago/trunk/example/demo/src/main/webapp/tobago-resource/html/scarborough/standard/image/tobago_logo.gif
> 
> >
> > Greetings
> >
> > Udo
> >
> >
> > Adonis Raduca schrieb:
> >
> >
> >
> >
> > > Hi,
> > >
> > > In the final all MyFaces logos are finished.
> > > I placed all of them in one image for a good overview. :)
> > > Please take a look in the atached PNG file.
> > >
> > > What is your final impression about those logos?
> > > Did they individually fit with each project?
> > > Did they fit together?
> > >
> > > Have a nice day !
> > > Adonis
> > >
> > > P.S.
> > > With respect for you Scott, I modified a little the PortletBridge logo
> in order to fit with the general MyFaces logo pattern.
> > > Is this OK for you?
> > >
> > >
> >
>
>



-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: [proposal] jsf validation with annotations

[Matthias Wessendorf]

> And jdk 1.5 is required (myfaces 1.1  is for 1.4)

@nnotation bring that requirement to the table.
which is cool. That the CORE impl of JSF 1.1 needs
Java1.4 doesn't mean, that every 1.1 complaint lib is
also having that (poor) requirement ;-)

-M

>
>
> >
> > regards,
> > gerhard
> >
> > [1] http://os890.blogspot.com/2008/04/sev-en-framework-requirements.html
> >
> >
> >
> >
> > 2008/4/4, Leonardo Uribe <[EMAIL PROTECTED]>:
> >
> >
> >
> > > Hi
> > >
> > > I have run the example on my tomcat installation.
> > >
> > > This works only with trinidad, or I can plug any jsf lib to use with
> (tomahawk or tobago)
> > >
> > > regards
> > >
> > > Leonardo Uribe
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
>
>



-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

tobago island logo :)

[Adonis Raduca]

Hi Udo,

I designed a Tobago island logo for you.
What do you think, it is OK now ?

Have a nice evening !
Adonis

On Thu, Apr 3, 2008 at 1:27 PM, Udo Schnurpfeil <[EMAIL PROTECTED]> wrote:

> Hallo Adonis,
>
> thank you for your good work. But for the Tobago project it would be nice
> to have a (abstract) shape of the island. Volker has asked for that also.
> The logo looks good, but it doesn't really fit to the Tobago project,
> because the shape of the island is the logo from the beginning of the
> project.
>
> You might use the shape in green, and the small islands (little tobago,
> goat island, st. giles island, and may be bucco reef, sisters/brothers
> rocks) as brown circles. Or the hills in the middle in brown?
>
> Could you do me a favour and make a sample?
>
> Here are some maps of tobago:
> http://www.abrahamrealty.com/images/tobagomap.gif
> http://www.exploretobago.com/tobago/tobagodetailmap.jpg
>
> There are also logos in the existing svn:
>
> http://svn.apache.org/repos/asf/myfaces/tobago/trunk/example/demo/src/main/webapp/tobago-resource/html/scarborough/standard/image/tobago_logo.gif<
> http://svn.apache.org/repos/asf/myfaces/tobago/trunk/example/demo/src/main/webapp/tobago-resource/html/scarborough/standard/image/tobago_logo.gif
> >
>
> Greetings
>
> Udo
>
>
> Adonis Raduca schrieb:
>
>  Hi,
> >
> > In the final all MyFaces logos are finished.
> > I placed all of them in one image for a good overview. :)
> > Please take a look in the atached PNG file.
> >
> > What is your final impression about those logos?
> > Did they individually fit with each project?
> > Did they fit together?
> >
> > Have a nice day !
> > Adonis
> >
> > P.S.
> > With respect for you Scott, I modified a little the PortletBridge logo
> > in order to fit with the general MyFaces logo pattern.
> > Is this OK for you?
> >
> >
<>

Re: [proposal] jsf validation with annotations

[Leonardo Uribe]

I have tried the demo on my workstation, and in my opinion is a very cool
idea and this should be on myfaces :)

The idea of include with myfaces-commons sounds better that put this on
orchestra (someone could want to use this only). Maybe
myfaces-commons-sev-en.

regards

Leonardo Uribe


On Fri, Apr 4, 2008 at 11:02 AM, Gerhard Petracek <
[EMAIL PROTECTED]> wrote:

> hello andrew,
>
> sev-en is completely independent of orchestra or the idea behind it.
>
> regards,
> gerhard
>
>
>
> 2008/4/4, Andrew Robinson <[EMAIL PROTECTED]>:
>
> > Since this is currently supported in Seam and Orchestra is a Seam
> > spin-off/clone, perhaps this should be incorporated into Orchestra
> > instead of yet another project.
> >
> >
> > On Fri, Apr 4, 2008 at 4:45 AM, Matthias Wessendorf <[EMAIL PROTECTED]>
> > wrote:
> > > Hi,
> > >
> > >
> > >  On Thu, Apr 3, 2008 at 10:11 PM, Gerhard Petracek
> > >  <[EMAIL PROTECTED]> wrote:
> > >  > sev-en is a new jsf-extension.
> > >  >
> > >  > sev-en allows jsf validation with annotations!
> > >  >
> > >  > some central features:
> > >  > - cross-component validation (including cross-entity validation)
> > >  >  - support for jpa based validation
> > >  > - zero configuration
> > >  > - extensible (e.g. custom annotations)
> > >  >
> > >  > you will find some previews (descriptions [1], examples [2] and
> > much more)
> > >  > at the sev-en section [3] of my new open source blog.
> > >  >
> > >  > what's your opinion about this extension?
> > >
> > >  sounds interesting. Is that levering the "bean validation" JSR ?
> > >  Would be cool to have a little bit more standard oriented validation
> > >  "framework".
> > >  Otherwise (IMO) that would be just something similar to @Hibernate's
> > validators
> > >  (used heavily in Seam)
> > >
> > >  -M
> > >
> > >
> > >
> > >  >
> > >  > regards,
> > >  > gerhard
> > >  >
> > >  > [1] http://os890.blogspot.com/2008/03/new-jsf-extension.html
> > >  > [2]
> > http://os890.blogspot.com/2008/04/sev-en-preview-short-example.html
> > >  >  [3] http://os890.blogspot.com/search/label/sev-en
> > >  >
> > >  > --
> > >  >
> > >  > http://www.irian.at
> > >  >
> > >  > Your JSF powerhouse -
> > >  > JSF Consulting, Development and
> > >  >  Courses in English and German
> > >  >
> > >  > Professional Support for Apache MyFaces
> > >
> > >
> > >
> > >  --
> > >  Matthias Wessendorf
> > >
> > >  further stuff:
> > >  blog: http://matthiaswessendorf.wordpress.com/
> > >  sessions: http://www.slideshare.net/mwessendorf
> > >  mail: matzew-at-apache-dot-org
> > >
> >
>
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>

Re: shale-test location (was RE: JSF 2.0 component set)

[Scott O'Bryan]

Yeah, the conversation has already gone on longer then I intended.  I 
was merely expressing sentiments that the moving of shale-test is not 
something I would oppose.  It is frustrating though to have to port the 
bridges ExternalContext logic to another platform.  The logic in JSF is 
largely tivial, but the Bridge environment has some extra complexities.


Understand also that I was in no way proposing the need to make 
configuration of your webapp matter for your test environment.  Just 
because one may use a piece of implementation from another project 
doesn't mean you need to use the whole thing.  My point was that much of 
the code in shale-test is unnecessary *IF* you are able to leverage the 
same work from an already built faces container.  This is something that 
shale cannot do currently and it leaves maintenance for changes to 
ExternalContext (in both the portal and servlet environments) 
co-existing in two locations.


Moving on, Gary, since your a PMC of shale, what would be the chances 
that we can add Portlet 1.0/JSF 1.2 testcases to shale-test.  I believe 
Kito was looking at doing some of this work and I would be interrested 
also.  I know that the Bridge can certainly use it (not necessarily for 
the TCK, but for build-time unit tests, and certainly my 
myfaces-commons-configurator project and my ExternalContextUtils in the 
myfaces-commons-util.  Would the community be open to adding portlet 
support?


Scott

Paul Spencer wrote:

Gary,
I also use shale-test.  One of the feature in the unreleased 1.1.0
allows you the test against any JSF 1.1/1.2 implementation without
having to replace the faces.xml configuration inside the test.  Thus
keeping the test framework independent from an implantation. Which is a
good thing and something I support.  Gary VanMatre has been named
Shale's PMC, and hopefully he, with our help, will revive the community.

FYI: Their have been many threads related to moving parts of Shale into
MyFaces.  Lets not start another one while Shale is still alive.


Paul Spencer




Gary VanMatre wrote:

 -- Original message --
From: "Scott O'Bryan" <[EMAIL PROTECTED]>
I don't really see why the physical location affects the ability to 
fix bugs

or do enhancements in parallel, unless it depends on some common
implementation classes. Or, are you talking more about releases?
  
Well releases are part of it.  I was meerly bringing up that the 
Bridge (even MyFaces) have impls which perform the logic for 
"ExternalContext" expected of their various specs.  These are 
duplicated somewhat in the shale-tests.  If it were moved over to 
faces, both the core-team and the bridge team would be able to 
maintain the test harnesses with the code they are writing.  For 
instance, Mock the Bridge and Servlet API's and Mock the 
FacesContextFactory.  It would, in turn, return an ExternalContext 
which (while being based off the myfaces or bridge impl) would also 
expose the setters needed to test thing.  But ultimately, the 
underlying implementations would run under the covers.  This would 
much easier reflect reality.


That said, I was just bringing up the idea that I wouldn't argue 
against it.  The Bridge (and some of the projects I'm doing in 
commons) need released versions of a portlet test harness and I 
wouldn't mind adding these test cases to Trinidad either.  Whether I 
pull them from Shale or MyFaces makes no real difference to me, but 
I could help maintain them better if they were in MyFaces -- for a 
current committer of shale I am not.  :)




Well, I'm not a MyFaces committer either.  Ok, I'll bore you - I had 
to work on Clay under Struts for 6 months submitting patches to the 
code I contributed before I
was nominated to join. 
Of course, that was then and this is now but I'd like to see Shale 
grow as a community.
The reality is that the majority of Shale was Craig's work.  I don't 
think that anyone would
dispute that. David Geary also had a hand in the inception.   That's 
why I'm into the all or nothing versus the cafeteria plan.  Shale 
test is one of the nuggets.  The annotation and remoting are also 
being used as the foundation - point of discussion for JSF 2.0.

Shale controller + shale dialog is a simplified version of ADFc 11g.
I don't know...  I think we all know how to work together amongst 
apache communities.  I'm sorta disappointed but at the same time it 
makes sense.  I remember Ted Husted
(someone else I have great respect for) saying open source is 
sometimes like a jealous mistress.  I think he might have told me 
that just before the merger with webwork.

The interesting bit there is that struts 1.x code base still exists.

Gary




Scott
Well, I'm happy whether it's in MyFaces or Shale, as long as we can 
update
it for JSF 1.2 and the Bridge. So, if you want it to be part of 
MyFaces and
are willing to deal with the work of getting it established, I 
think you'd

have a good case.
What do others think (especial

Re: [proposal] jsf validation with annotations

[Gerhard Petracek]

hello andrew,

sev-en is completely independent of orchestra or the idea behind it.

regards,
gerhard



2008/4/4, Andrew Robinson <[EMAIL PROTECTED]>:
>
> Since this is currently supported in Seam and Orchestra is a Seam
> spin-off/clone, perhaps this should be incorporated into Orchestra
> instead of yet another project.
>
>
> On Fri, Apr 4, 2008 at 4:45 AM, Matthias Wessendorf <[EMAIL PROTECTED]>
> wrote:
> > Hi,
> >
> >
> >  On Thu, Apr 3, 2008 at 10:11 PM, Gerhard Petracek
> >  <[EMAIL PROTECTED]> wrote:
> >  > sev-en is a new jsf-extension.
> >  >
> >  > sev-en allows jsf validation with annotations!
> >  >
> >  > some central features:
> >  > - cross-component validation (including cross-entity validation)
> >  >  - support for jpa based validation
> >  > - zero configuration
> >  > - extensible (e.g. custom annotations)
> >  >
> >  > you will find some previews (descriptions [1], examples [2] and much
> more)
> >  > at the sev-en section [3] of my new open source blog.
> >  >
> >  > what's your opinion about this extension?
> >
> >  sounds interesting. Is that levering the "bean validation" JSR ?
> >  Would be cool to have a little bit more standard oriented validation
> >  "framework".
> >  Otherwise (IMO) that would be just something similar to @Hibernate's
> validators
> >  (used heavily in Seam)
> >
> >  -M
> >
> >
> >
> >  >
> >  > regards,
> >  > gerhard
> >  >
> >  > [1] http://os890.blogspot.com/2008/03/new-jsf-extension.html
> >  > [2]
> http://os890.blogspot.com/2008/04/sev-en-preview-short-example.html
> >  >  [3] http://os890.blogspot.com/search/label/sev-en
> >  >
> >  > --
> >  >
> >  > http://www.irian.at
> >  >
> >  > Your JSF powerhouse -
> >  > JSF Consulting, Development and
> >  >  Courses in English and German
> >  >
> >  > Professional Support for Apache MyFaces
> >
> >
> >
> >  --
> >  Matthias Wessendorf
> >
> >  further stuff:
> >  blog: http://matthiaswessendorf.wordpress.com/
> >  sessions: http://www.slideshare.net/mwessendorf
> >  mail: matzew-at-apache-dot-org
> >
>



-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [proposal] jsf validation with annotations

[Gerhard Petracek]

hello leonardo,

that's right - because of the fact you are using annotations ;)

regards,
gerhard



2008/4/4, Leonardo Uribe <[EMAIL PROTECTED]>:
>
> On Fri, Apr 4, 2008 at 10:48 AM, Gerhard Petracek <
> [EMAIL PROTECTED]> wrote:
>
> > hello leonardo,
> >
> > you don't need trinidad - i used it just for the demo!
> > you will find the requirements at my blog [1] ;)
> >
>
> And jdk 1.5 is required (myfaces 1.1  is for 1.4)
>
>
> >
> > regards,
> > gerhard
> >
> > [1] http://os890.blogspot.com/2008/04/sev-en-framework-requirements.html
> >
> >
> >
> > 2008/4/4, Leonardo Uribe <[EMAIL PROTECTED]>:
> >
> > > Hi
> > >
> > > I have run the example on my tomcat installation.
> > >
> > > This works only with trinidad, or I can plug any jsf lib to use with
> > > (tomahawk or tobago)
> > >
> > > regards
> > >
> > > Leonardo Uribe
> > >
> > >
> > >
> > >
> >
> >
> > --
> >
> > 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

Re: [proposal] jsf validation with annotations

[Gerhard Petracek]

hello leonardo,

once again (as mentioned within my blog):
the core of sev-en is independent of specific annotations.

-> if you would like to have the mentioned annotation -> implement and
provide it. ;)
you will find a short description at my blog [1]

as you see within the demo:
validators within your page are not affected by sev-en.

regards,
gerhard

[1] http://os890.blogspot.com/2008/04/sev-en-preview-implement-your-own.html



2008/4/4, Leonardo Uribe <[EMAIL PROTECTED]>:
>
> Another question
>
> If I have a validator, does exists annotations to use it like:
>
>@Validator("org.apache.myfaces.custom.emailvalidator.EmailValidator")
>private string email;
>
> Or the annotations should have defined inside sev-en
>
> regards
>
> Leonardo Uribe
>
> On Fri, Apr 4, 2008 at 10:26 AM, Leonardo Uribe <[EMAIL PROTECTED]> wrote:
>
> > Hi
> >
> > I have run the example on my tomcat installation.
> >
> > This works only with trinidad, or I can plug any jsf lib to use with
> > (tomahawk or tobago)
> >
> > regards
> >
> > Leonardo Uribe
> >
> >
> >
> >
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [proposal] jsf validation with annotations

[Andrew Robinson]

Since this is currently supported in Seam and Orchestra is a Seam
spin-off/clone, perhaps this should be incorporated into Orchestra
instead of yet another project.

On Fri, Apr 4, 2008 at 4:45 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> Hi,
>
>
>  On Thu, Apr 3, 2008 at 10:11 PM, Gerhard Petracek
>  <[EMAIL PROTECTED]> wrote:
>  > sev-en is a new jsf-extension.
>  >
>  > sev-en allows jsf validation with annotations!
>  >
>  > some central features:
>  > - cross-component validation (including cross-entity validation)
>  >  - support for jpa based validation
>  > - zero configuration
>  > - extensible (e.g. custom annotations)
>  >
>  > you will find some previews (descriptions [1], examples [2] and much more)
>  > at the sev-en section [3] of my new open source blog.
>  >
>  > what's your opinion about this extension?
>
>  sounds interesting. Is that levering the "bean validation" JSR ?
>  Would be cool to have a little bit more standard oriented validation
>  "framework".
>  Otherwise (IMO) that would be just something similar to @Hibernate's 
> validators
>  (used heavily in Seam)
>
>  -M
>
>
>
>  >
>  > regards,
>  > gerhard
>  >
>  > [1] http://os890.blogspot.com/2008/03/new-jsf-extension.html
>  > [2] http://os890.blogspot.com/2008/04/sev-en-preview-short-example.html
>  >  [3] http://os890.blogspot.com/search/label/sev-en
>  >
>  > --
>  >
>  > http://www.irian.at
>  >
>  > Your JSF powerhouse -
>  > JSF Consulting, Development and
>  >  Courses in English and German
>  >
>  > Professional Support for Apache MyFaces
>
>
>
>  --
>  Matthias Wessendorf
>
>  further stuff:
>  blog: http://matthiaswessendorf.wordpress.com/
>  sessions: http://www.slideshare.net/mwessendorf
>  mail: matzew-at-apache-dot-org
>

Re: [proposal] jsf validation with annotations

[Leonardo Uribe]

On Fri, Apr 4, 2008 at 10:48 AM, Gerhard Petracek <
[EMAIL PROTECTED]> wrote:

> hello leonardo,
>
> you don't need trinidad - i used it just for the demo!
> you will find the requirements at my blog [1] ;)
>

And jdk 1.5 is required (myfaces 1.1  is for 1.4)


>
> regards,
> gerhard
>
> [1] http://os890.blogspot.com/2008/04/sev-en-framework-requirements.html
>
>
>
> 2008/4/4, Leonardo Uribe <[EMAIL PROTECTED]>:
>
> > Hi
> >
> > I have run the example on my tomcat installation.
> >
> > This works only with trinidad, or I can plug any jsf lib to use with
> > (tomahawk or tobago)
> >
> > regards
> >
> > Leonardo Uribe
> >
> >
> >
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>

Re: [proposal] jsf validation with annotations

[Gerhard Petracek]

hello leonardo,

you don't need trinidad - i used it just for the demo!
you will find the requirements at my blog [1] ;)

regards,
gerhard

[1] http://os890.blogspot.com/2008/04/sev-en-framework-requirements.html



2008/4/4, Leonardo Uribe <[EMAIL PROTECTED]>:
>
> Hi
>
> I have run the example on my tomcat installation.
>
> This works only with trinidad, or I can plug any jsf lib to use with
> (tomahawk or tobago)
>
> regards
>
> Leonardo Uribe
>
>
>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [proposal] jsf validation with annotations

[Leonardo Uribe]

Another question

If I have a validator, does exists annotations to use it like:

   @Validator("org.apache.myfaces.custom.emailvalidator.EmailValidator")
   private string email;

Or the annotations should have defined inside sev-en

regards

Leonardo Uribe

On Fri, Apr 4, 2008 at 10:26 AM, Leonardo Uribe <[EMAIL PROTECTED]> wrote:

> Hi
>
> I have run the example on my tomcat installation.
>
> This works only with trinidad, or I can plug any jsf lib to use with
> (tomahawk or tobago)
>
> regards
>
> Leonardo Uribe
>
>
>
>

Re: [proposal] jsf validation with annotations

[Leonardo Uribe]

Hi

I have run the example on my tomcat installation.

This works only with trinidad, or I can plug any jsf lib to use with
(tomahawk or tobago)

regards

Leonardo Uribe

Re: [proposal] jsf validation with annotations

[Gerhard Petracek]

hello mario,

today i uploaded an intermediate result of the demo. all information are
available at the sev-en section of my blog [1].

regards,
gerhard

[1] http://os890.blogspot.com/search/label/sev-en



2008/4/4, Mario Ivankovits <[EMAIL PROTECTED]>:
>
> Hi!
>
> > sev-en is a new jsf-extension.
>
> Looks Cool, I love it to see that a long standing idea now seems to be
> realized.
>
> You posted on the dev list .. cool .. you probably know we are
> developers too ... so .. where do we find the code? Or is it just a
> too-late April joke ;-)
>
> I think that would make a great new module for myfaces, no?
>
> Ciao,
>
> Mario
>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: shale-test location (was RE: JSF 2.0 component set)

[Paul Spencer]

Gary,
I also use shale-test.  One of the feature in the unreleased 1.1.0
allows you the test against any JSF 1.1/1.2 implementation without
having to replace the faces.xml configuration inside the test.  Thus
keeping the test framework independent from an implantation. Which is a
good thing and something I support.  Gary VanMatre has been named
Shale's PMC, and hopefully he, with our help, will revive the community.

FYI: Their have been many threads related to moving parts of Shale into
MyFaces.  Lets not start another one while Shale is still alive.


Paul Spencer




Gary VanMatre wrote:

 -- Original message --
From: "Scott O'Bryan" <[EMAIL PROTECTED]>

I don't really see why the physical location affects the ability to fix bugs
or do enhancements in parallel, unless it depends on some common
implementation classes. Or, are you talking more about releases?
  
Well releases are part of it.  I was meerly bringing up that the Bridge 
(even MyFaces) have impls which perform the logic for "ExternalContext" 
expected of their various specs.  These are duplicated somewhat in the 
shale-tests.  If it were moved over to faces, both the core-team and the 
bridge team would be able to maintain the test harnesses with the code 
they are writing.  For instance, Mock the Bridge and Servlet API's and 
Mock the FacesContextFactory.  It would, in turn, return an 
ExternalContext which (while being based off the myfaces or bridge impl) 
would also expose the setters needed to test thing.  But ultimately, the 
underlying implementations would run under the covers.  This would much 
easier reflect reality.


That said, I was just bringing up the idea that I wouldn't argue against 
it.  The Bridge (and some of the projects I'm doing in commons) need 
released versions of a portlet test harness and I wouldn't mind adding 
these test cases to Trinidad either.  Whether I pull them from Shale or 
MyFaces makes no real difference to me, but I could help maintain them 
better if they were in MyFaces -- for a current committer of shale I am 
not.  :)




Well, I'm not a MyFaces committer either.  Ok, I'll bore you - I had to work on Clay 
under Struts for 6 months submitting patches to the code I contributed before I
was nominated to join.  


Of course, that was then and this is now but I'd like to see Shale grow as a 
community.
The reality is that the majority of Shale was Craig's work.  I don't think that 
anyone would
dispute that. David Geary also had a hand in the inception.   That's why I'm into the all or 
nothing versus the cafeteria plan.  Shale test is one of the nuggets.  The annotation and 
remoting are also being used as the foundation - point of discussion for JSF 2.0.
Shale controller + shale dialog is a simplified version of ADFc 11g. 

I don't know...  I think we all know how to work together amongst apache communities.  
I'm sorta disappointed but at the same time it makes sense.  I remember Ted Husted
(someone else I have great respect for) saying open source is sometimes like a 
jealous mistress.  I think he might have told me that just before the merger with webwork.

The interesting bit there is that struts 1.x code base still exists.

Gary




Scott

Well, I'm happy whether it's in MyFaces or Shale, as long as we can update
it for JSF 1.2 and the Bridge. So, if you want it to be part of MyFaces and
are willing to deal with the work of getting it established, I think you'd
have a good case. 


What do others think (especially Gary)?

  

Kito D. Mann wrote:


*From:* Gary VanMatre [mailto:[EMAIL PROTECTED]
*Sent:* Wednesday, April 02, 2008 11:16 AM
*To:* MyFaces Development; [EMAIL PROTECTED]; 'MyFaces Development'
*Cc:* Kito D. Mann
*Subject:* RE: JSF 2.0 component set

  

From: "Kito D. Mann" <[EMAIL PROTECTED]>

I just want to add that when we were talking about moving Shale


over to


MyFaces, people were worried about resources for maintaining it.


And


Shale
  

is an *existing* code base :-). I think it'd make a lot more sense


to


migrate the existing suites to JSF 2 branches.



The big issue I had with merging was that the majority didn't want to
bring over all of shale. At this point, I don't think it would be
responsible just to drop support unless you could offer a comparable
feature.

True. I thought it might make sense to bring the biggest pieces over
to MyFaces, but if we can revive part of Shale's development, I'm
  

fine


with that too. I just wanted to avoid atrophy of the entire Shale
  

code


base :-).

The shale's test library is one of the few that have not been
reinvented over and over and that seemed to be where the root
  

interest


is with myfaces.

In terms of maintaining Shale, we most certainly encourage
contributions the same as myfaces :-)

Of course :-).

Gary


  

~~~
Kito D. Mann -

Re: shale-test location (was RE: JSF 2.0 component set)

[Paul Spencer]

Gary,
I also use shale-test.  One of the feature in the unreleased 1.1.0 
allows you the test against any JSF 1.1/1.2 implementation without 
having to replace the faces.xml configuration inside the test.  Thus 
keeping the test framework independent from an implantation. Which is a 
good thing and something I support.  Gary VanMatre has been named 
Shale's PMC, and hopefully he, with our help, will revive the community.


FYI: Their have been many threads related to moving parts of Shale into 
MyFaces.  Lets not start another one while Shale is still alive.



Paul Spencer




Gary VanMatre wrote:

 -- Original message --
From: "Scott O'Bryan" <[EMAIL PROTECTED]>

I don't really see why the physical location affects the ability to fix bugs
or do enhancements in parallel, unless it depends on some common
implementation classes. Or, are you talking more about releases?
  
Well releases are part of it.  I was meerly bringing up that the Bridge 
(even MyFaces) have impls which perform the logic for "ExternalContext" 
expected of their various specs.  These are duplicated somewhat in the 
shale-tests.  If it were moved over to faces, both the core-team and the 
bridge team would be able to maintain the test harnesses with the code 
they are writing.  For instance, Mock the Bridge and Servlet API's and 
Mock the FacesContextFactory.  It would, in turn, return an 
ExternalContext which (while being based off the myfaces or bridge impl) 
would also expose the setters needed to test thing.  But ultimately, the 
underlying implementations would run under the covers.  This would much 
easier reflect reality.


That said, I was just bringing up the idea that I wouldn't argue against 
it.  The Bridge (and some of the projects I'm doing in commons) need 
released versions of a portlet test harness and I wouldn't mind adding 
these test cases to Trinidad either.  Whether I pull them from Shale or 
MyFaces makes no real difference to me, but I could help maintain them 
better if they were in MyFaces -- for a current committer of shale I am 
not.  :)




Well, I'm not a MyFaces committer either.  Ok, I'll bore you - I had to work on Clay 
under Struts for 6 months submitting patches to the code I contributed before I
was nominated to join.  


Of course, that was then and this is now but I'd like to see Shale grow as a 
community.
The reality is that the majority of Shale was Craig's work.  I don't think that 
anyone would
dispute that. David Geary also had a hand in the inception.   That's why I'm into the all or 
nothing versus the cafeteria plan.  Shale test is one of the nuggets.  The annotation and 
remoting are also being used as the foundation - point of discussion for JSF 2.0.
Shale controller + shale dialog is a simplified version of ADFc 11g. 

I don't know...  I think we all know how to work together amongst apache communities.  
I'm sorta disappointed but at the same time it makes sense.  I remember Ted Husted
(someone else I have great respect for) saying open source is sometimes like a 
jealous mistress.  I think he might have told me that just before the merger with webwork.

The interesting bit there is that struts 1.x code base still exists.

Gary




Scott

Well, I'm happy whether it's in MyFaces or Shale, as long as we can update
it for JSF 1.2 and the Bridge. So, if you want it to be part of MyFaces and
are willing to deal with the work of getting it established, I think you'd
have a good case. 


What do others think (especially Gary)?

  

Kito D. Mann wrote:


*From:* Gary VanMatre [mailto:[EMAIL PROTECTED]
*Sent:* Wednesday, April 02, 2008 11:16 AM
*To:* MyFaces Development; [EMAIL PROTECTED]; 'MyFaces Development'
*Cc:* Kito D. Mann
*Subject:* RE: JSF 2.0 component set

  

From: "Kito D. Mann" <[EMAIL PROTECTED]>

I just want to add that when we were talking about moving Shale


over to


MyFaces, people were worried about resources for maintaining it.


And


Shale
  

is an *existing* code base :-). I think it'd make a lot more sense


to


migrate the existing suites to JSF 2 branches.



The big issue I had with merging was that the majority didn't want to
bring over all of shale. At this point, I don't think it would be
responsible just to drop support unless you could offer a comparable
feature.

True. I thought it might make sense to bring the biggest pieces over
to MyFaces, but if we can revive part of Shale's development, I'm
  

fine


with that too. I just wanted to avoid atrophy of the entire Shale
  

code


base :-).

The shale's test library is one of the few that have not been
reinvented over and over and that seemed to be where the root
  

interest


is with myfaces.

In terms of maintaining Shale, we most certainly encourage
contributions the same as myfaces :-)

Of course :-).

Gary


  

~~~
Kito D

Re: [Tobago] Merging maven-apt-plugin with Codehaus'

[Mark Hobson]

Great, I'll looking forward to hearing back from you then.

Cheers,

Mark

On 04/04/2008, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
> Hello Mark,
>
>  during the ApacheCon Europe next week I can spend some time to test the
>  plugin with the tobago build.
>
>  Regards
>
>
>
>  Bernd
>
>
>

[jira] Resolved: (TOBAGO-325) Popups background not disabled

[Bernd Bohmann (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TOBAGO-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Bohmann resolved TOBAGO-325.
--

Resolution: Fixed

This issue needs futher investigation, but i will change the status to Resolved 
for now.

> Popups background not disabled
> --
>
> Key: TOBAGO-325
> URL: https://issues.apache.org/jira/browse/TOBAGO-325
> Project: MyFaces Tobago
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.10
> Environment: All
>Reporter: Helmut Swaczinna
>Assignee: Bernd Bohmann
> Fix For: 1.0.16, 1.1.0
>
> Attachments: tobago-325.diff
>
>
> When the page shows a popup the background page is grayed and
> you can't activate any component by mouse. But you can activate
> any component by keyboard when you use the tab key. You can execute
> actions and modifiy fields.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Tobago] Merging maven-apt-plugin with Codehaus'

[Bernd Bohmann]

Hello Mark,

during the ApacheCon Europe next week I can spend some time to test the
plugin with the tobago build.

Regards


Bernd

[jira] Resolved: (TOBAGO-627) JNDI-Problem on Websphere Application Server

[Bernd Bohmann (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TOBAGO-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Bohmann resolved TOBAGO-627.
--

Resolution: Fixed

> JNDI-Problem on Websphere Application Server
> 
>
> Key: TOBAGO-627
> URL: https://issues.apache.org/jira/browse/TOBAGO-627
> Project: MyFaces Tobago
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.15
> Environment: Websphere Application Server (at least version 6.1)
>Reporter: Matthias Wronka
>Assignee: Bernd Bohmann
> Fix For: 1.0.16, 1.1.0
>
>
> In our Logs on WAS we find several outputs like
> [2/21/08 17:12:16:569 CET] 0022 javaURLContex E   NMSV0310E: A JNDI 
> operation on a "java:" name cannot be completed because the server runtime is 
> not able to associate the operation's thread with any J2EE application 
> component. This condition can occur when the JNDI client using the "java:" 
> name is not executed on the thread of a server application request. Make sure 
> that a J2EE application does not execute JNDI operations on "java:" names 
> within static code blocks or in threads created by that J2EE application. 
> Such code does not necessarily run on the thread of a server application 
> request and therefore is not supported by JNDI operations on "java:" names. 
> Exception stack trace: 
> javax.naming.ConfigurationException [Root exception is 
> javax.naming.NameNotFoundException: Name "tobago.ajax.contentType" not found 
> in context "java:comp/env".]
>   at 
> com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:411)
>   at 
> com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
>   at 
> com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1307)
>   at 
> com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:353)
>   at 
> org.apache.myfaces.tobago.ajax.api.AjaxResponseRenderer.(AjaxResponseRenderer.java:74)
>   at 
> org.apache.myfaces.tobago.lifecycle.RenderResponseExecutor.(RenderResponseExecutor.java:41)
>   at 
> org.apache.myfaces.tobago.lifecycle.TobagoLifecycle.(TobagoLifecycle.java:65)
>   at 
> org.apache.myfaces.tobago.lifecycle.TobagoLifecycleFactory.(TobagoLifecycleFactory.java:36)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:67)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:522)
>   at 
> javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:547)
>   at 
> javax.faces.FactoryFinder.getImplementationInstance(FactoryFinder.java:432)
>   at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:232)
> und
> [2/21/08 17:12:16:665 CET] 0022 javaURLContex E   NMSV0310E: A JNDI 
> operation on a "java:" name cannot be completed because the server runtime is 
> not able to associate the operation's thread with any J2EE application 
> component. This condition can occur when the JNDI client using the "java:" 
> name is not executed on the thread of a server application request. Make sure 
> that a J2EE application does not execute JNDI operations on "java:" names 
> within static code blocks or in threads created by that J2EE application. 
> Such code does not necessarily run on the thread of a server application 
> request and therefore is not supported by JNDI operations on "java:" names. 
> Exception stack trace: 
> javax.naming.ConfigurationException [Root exception is 
> javax.naming.NameNotFoundException: Name "uploadRepositoryPath" not found in 
> context "java:comp/env".]
>   at 
> com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:411)
>   at 
> com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
>   at 
> com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1307)
>   at 
> com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:353)
>   at 
> org.apache.myfaces.tobago.fileupload.FileUploadFacesContextFactoryImpl.(FileUploadFacesContextFactoryImpl.java:79)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:67)
> sowie
> [2/21/08 17:12:16:695 CET] 0022 javaURLContex E   NMSV0310E: A JNDI 
> operation on a "java:" name cannot be completed because the server runtime is 
> not able to associate the operation's thread with any J2EE application 
> component. This condition 

Re: [proposal] jsf validation with annotations

[Gerhard Petracek]

hello,

@matthias:
in my opinion the best solution would be an independent sub-project -> e.g.
myfaces sev-en

@martin:
it started just as private feasibility study. the demo works great. however,
it needs e.g. junit test-cases, much more annotations and such things.
(please note - the sev-en core is independent of specific annotations - you
can implement your own annotations [1])

you see - there is still some work to do. maybe some volunteers will join
the development after publishing it. would be great!

regards,
gerhard

[1] http://os890.blogspot.com/2008/04/sev-en-preview-implement-your-own.html



2008/4/4, Martin Haimberger <[EMAIL PROTECTED]>:
>
> Hi Gerhard,
>
> sounds fancy and simple! Nice work! I think i will take a closer look. How
> stable is it in the mean time?
>
> Regards,
> Martin
>
>
> On 4/3/08, Gerhard Petracek <[EMAIL PROTECTED]> wrote:
> >
> > sev-en is a new jsf-extension.
> >
> > sev-en allows jsf validation with annotations!
> >
> > some central features:
> > - cross-component validation (including cross-entity validation)
> > - support for jpa based validation
> > - zero configuration
> > - extensible (e.g. custom annotations)
> >
> > you will find some previews (descriptions [1], examples [2] and much
> > more) at the sev-en section [3] of my new open source blog.
> >
> > what's your opinion about this extension?
> >
> > regards,
> > gerhard
> >
> > [1] http://os890.blogspot.com/2008/03/new-jsf-extension.html
> > [2] http://os890.blogspot.com/2008/04/sev-en-preview-short-example.html
> > [3] http://os890.blogspot.com/search/label/sev-en
> >
> > --
> >
> > 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

Re: [proposal] jsf validation with annotations

[Martin Haimberger]

Hi Gerhard,

sounds fancy and simple! Nice work! I think i will take a closer look. How
stable is it in the mean time?

Regards,
Martin


On 4/3/08, Gerhard Petracek <[EMAIL PROTECTED]> wrote:
>
> sev-en is a new jsf-extension.
>
> sev-en allows jsf validation with annotations!
>
> some central features:
> - cross-component validation (including cross-entity validation)
> - support for jpa based validation
> - zero configuration
> - extensible (e.g. custom annotations)
>
> you will find some previews (descriptions [1], examples [2] and much more)
> at the sev-en section [3] of my new open source blog.
>
> what's your opinion about this extension?
>
> regards,
> gerhard
>
> [1] http://os890.blogspot.com/2008/03/new-jsf-extension.html
> [2] http://os890.blogspot.com/2008/04/sev-en-preview-short-example.html
> [3] http://os890.blogspot.com/search/label/sev-en
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces

Re: [proposal] jsf validation with annotations

[Matthias Wessendorf]

On Fri, Apr 4, 2008 at 8:07 AM, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> Hi!
>
> > sev-en is a new jsf-extension.
>  Looks Cool, I love it to see that a long standing idea now seems to be
>  realized.
>
>  You posted on the dev list .. cool .. you probably know we are
>  developers too ... so .. where do we find the code? Or is it just a
>  too-late April joke ;-)
>
>  I think that would make a great new module for myfaces, no?

would be a good candidate for the commons-validator,
since not tied to Trinidad, Tobago, Tomahawk or what ever.

-M

>
>  Ciao,
>  Mario
>
>



-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: [proposal] jsf validation with annotations

[Matthias Wessendorf]

Hi,

On Thu, Apr 3, 2008 at 10:11 PM, Gerhard Petracek
<[EMAIL PROTECTED]> wrote:
> sev-en is a new jsf-extension.
>
> sev-en allows jsf validation with annotations!
>
> some central features:
> - cross-component validation (including cross-entity validation)
>  - support for jpa based validation
> - zero configuration
> - extensible (e.g. custom annotations)
>
> you will find some previews (descriptions [1], examples [2] and much more)
> at the sev-en section [3] of my new open source blog.
>
> what's your opinion about this extension?

sounds interesting. Is that levering the "bean validation" JSR ?
Would be cool to have a little bit more standard oriented validation
"framework".
Otherwise (IMO) that would be just something similar to @Hibernate's validators
(used heavily in Seam)

-M

>
> regards,
> gerhard
>
> [1] http://os890.blogspot.com/2008/03/new-jsf-extension.html
> [2] http://os890.blogspot.com/2008/04/sev-en-preview-short-example.html
>  [3] http://os890.blogspot.com/search/label/sev-en
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
>  Courses in English and German
>
> Professional Support for Apache MyFaces



-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

Re: [proposal] jsf validation with annotations

[Gerhard Petracek]

hello mario,

at the moment it's not available at a public repository.

my current plan is to publish it within the next view weeks.
i agree with you - sev-en would be a great myfaces module!

regards,
gerhard



2008/4/4, Mario Ivankovits <[EMAIL PROTECTED]>:
>
> Hi!
>
> > sev-en is a new jsf-extension.
>
> Looks Cool, I love it to see that a long standing idea now seems to be
> realized.
>
> You posted on the dev list .. cool .. you probably know we are
> developers too ... so .. where do we find the code? Or is it just a
> too-late April joke ;-)
>
> I think that would make a great new module for myfaces, no?
>
> Ciao,
>
> Mario
>
>


-- 

http://www.irian.at

Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

Re: [Tobago] Merging maven-apt-plugin with Codehaus'

[Mark Hobson]

Hi Bernd,

On 03/04/2008, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
> http://svn.apache.org/repos/asf/myfaces/tobago/trunk/sandbox/pom.xml
>
>  
> http://svn.apache.org/repos/asf/myfaces/tobago/trunk/extension/facelets/pom.xml
>
>  
> http://svn.apache.org/repos/asf/myfaces/tobago/trunk/extension/tobago-taglib-extension/pom.xml

Okay, I won't argue with these pom.xmls :)  I've kept this parameter
as 'additionalSourceRoots'.

> Sorry, we are using this parameter. I think the apt plugin generates
>  resources and with the parameter targetpath I can tell the resource
>  plugin where the resouces should be copied.
>  This parameter is used for generating the tlds in tobago. Without this
>  parameter i need an extra resources section and I don't like to include
>  the META-INF in the target.

No worries, I've reinstated this parameter.

> No, but as far as I know some guys are using a one to many mapping. They
>  are using the force parameter.

An apt factory that creates multiple target files for each source
file?  Interesting, this may be supported by specifying multiple
outputFileEnding parameters.  Feel free to open a MOJO issue if this
isn't supported.

Okay, I think I'm done with the plugin now, aside from updating the
documentation which I'll try to find time to do later.  If you could
give it a spin in Tobago then I'd be interested in how you get on:

http://svn.codehaus.org/mojo/trunk/sandbox/apt-maven-plugin/

Let me know if you have any issues.  Note that some parameters have
been renamed for consistency with other plugins, but they should be
pretty self-explanatory from the mojo javadoc.  I can start a vote for
an alpha release once we're both happy with it.

Cheers,

Mark

[jira] Commented: (TOBAGO-627) JNDI-Problem on Websphere Application Server

[Dennis Hauser (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOBAGO-627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585470#action_12585470
 ] 

Dennis Hauser commented on TOBAGO-627:
--

Hi Bernd,

we have applied your Tobago - Patches and successfully tested them on Websphere 
6.1.0.13

Thanks!

> JNDI-Problem on Websphere Application Server
> 
>
> Key: TOBAGO-627
> URL: https://issues.apache.org/jira/browse/TOBAGO-627
> Project: MyFaces Tobago
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 1.0.15
> Environment: Websphere Application Server (at least version 6.1)
>Reporter: Matthias Wronka
>Assignee: Bernd Bohmann
> Fix For: 1.0.16, 1.1.0
>
>
> In our Logs on WAS we find several outputs like
> [2/21/08 17:12:16:569 CET] 0022 javaURLContex E   NMSV0310E: A JNDI 
> operation on a "java:" name cannot be completed because the server runtime is 
> not able to associate the operation's thread with any J2EE application 
> component. This condition can occur when the JNDI client using the "java:" 
> name is not executed on the thread of a server application request. Make sure 
> that a J2EE application does not execute JNDI operations on "java:" names 
> within static code blocks or in threads created by that J2EE application. 
> Such code does not necessarily run on the thread of a server application 
> request and therefore is not supported by JNDI operations on "java:" names. 
> Exception stack trace: 
> javax.naming.ConfigurationException [Root exception is 
> javax.naming.NameNotFoundException: Name "tobago.ajax.contentType" not found 
> in context "java:comp/env".]
>   at 
> com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:411)
>   at 
> com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
>   at 
> com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1307)
>   at 
> com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:353)
>   at 
> org.apache.myfaces.tobago.ajax.api.AjaxResponseRenderer.(AjaxResponseRenderer.java:74)
>   at 
> org.apache.myfaces.tobago.lifecycle.RenderResponseExecutor.(RenderResponseExecutor.java:41)
>   at 
> org.apache.myfaces.tobago.lifecycle.TobagoLifecycle.(TobagoLifecycle.java:65)
>   at 
> org.apache.myfaces.tobago.lifecycle.TobagoLifecycleFactory.(TobagoLifecycleFactory.java:36)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:67)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:522)
>   at 
> javax.faces.FactoryFinder.getImplGivenPreviousImpl(FactoryFinder.java:547)
>   at 
> javax.faces.FactoryFinder.getImplementationInstance(FactoryFinder.java:432)
>   at javax.faces.FactoryFinder.getFactory(FactoryFinder.java:232)
> und
> [2/21/08 17:12:16:665 CET] 0022 javaURLContex E   NMSV0310E: A JNDI 
> operation on a "java:" name cannot be completed because the server runtime is 
> not able to associate the operation's thread with any J2EE application 
> component. This condition can occur when the JNDI client using the "java:" 
> name is not executed on the thread of a server application request. Make sure 
> that a J2EE application does not execute JNDI operations on "java:" names 
> within static code blocks or in threads created by that J2EE application. 
> Such code does not necessarily run on the thread of a server application 
> request and therefore is not supported by JNDI operations on "java:" names. 
> Exception stack trace: 
> javax.naming.ConfigurationException [Root exception is 
> javax.naming.NameNotFoundException: Name "uploadRepositoryPath" not found in 
> context "java:comp/env".]
>   at 
> com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:411)
>   at 
> com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:388)
>   at 
> com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1307)
>   at 
> com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:353)
>   at 
> org.apache.myfaces.tobago.fileupload.FileUploadFacesContextFactoryImpl.(FileUploadFacesContextFactoryImpl.java:79)
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:67)
> sowie
> [2/21/08 17:12:16:695 CET] 0022 javaURLContex E   NMSV0310E: A JNDI 
> operation on a "java:" name cannot be c

[jira] Commented: (TOMAHAWK-1199) Seems like email validation is not working

[Ingo Nolden (JIRA)]

[ 
https://issues.apache.org/jira/browse/TOMAHAWK-1199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12585455#action_12585455
 ] 

Ingo Nolden commented on TOMAHAWK-1199:
---

I just ran into the same problem with t:validateEmail.
I was able to solve it by using t:inputText instead of h:inputText.
 
Example:

  



I am using tomahawk 1.1.6 with myfaces 1.2.2.

> Seems like email validation is not working
> --
>
> Key: TOMAHAWK-1199
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1199
> Project: MyFaces Tomahawk
>  Issue Type: Bug
>Affects Versions: 1.1.7-SNAPSHOT
>Reporter: Guy Bashan
>
> Seems like email validation is not working. It used to work in previous 
> versions.
> Code example:
> -
> <%@ taglib uri="http://java.sun.com/jsf/html"; prefix="h" %>
> <%@ taglib uri="http://java.sun.com/jsf/core"; prefix="f" %>
> <%@ taglib uri="http://myfaces.apache.org/tomahawk"; prefix="t" %>
> <%@ page contentType="text/html;charset=UTF-8" language="java" %>
> 
>   Simple jsp page
>   
>   
>   
> 
>   
> 
> 
>   
>   
>   
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.