[Trinidad] NumberConverter and fr_FR locale

2007-11-28 Thread Matthias Wessendorf
for fixing Trinidad-202 ([1] (was done during incubation)), we added
these lines (and some other)

DecimalFormat df = (DecimalFormat)fmt;
DecimalFormatSymbols dfs = df.getDecimalFormatSymbols();

if (dfs.getGroupingSeparator() == '\u00a0')
  value = value.replace(' ', '\u00a0');

So far, so good.
But that causes issues, when running in fr_FR locale, like:

tr:inputText value=#{validate.currency}
   id=outputText1
  tr:convertNumber locale=fr_FR type=currency/
/tr:inputText

The rendered output is 12 345,68 €, which is fine.

When re-submitting this value, you'll see an converter-error-msg, that
the format is wrong.
That is because:
1. the groupingSeparator() in fr_FR is '\u00a0'
2. therefore the   between 2 and 3 AND 8 and € is replaced by '\u00a0'.

the later is the issue, and the conversion fails.

Any ideas ?

-Matthias

[1] https://issues.apache.org/jira/browse/TRINIDAD-202

-- 
Matthias Wessendorf

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


[jira] Created: (TOBAGO-557) Selection problem with tc:treeListbox selectable=siblingLeafOnly

2007-11-28 Thread Emrullah Yaz (JIRA)
Selection problem with tc:treeListbox selectable=siblingLeafOnly


 Key: TOBAGO-557
 URL: https://issues.apache.org/jira/browse/TOBAGO-557
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.12, 1.0.11, 1.0.10, 1.0.9
 Environment: Suse Linux Server 9 , Tomcat 5.5.20, jdk 1.5.0_07
Reporter: Emrullah Yaz
Priority: Critical


this bug is related to bug 343.

the described problem can be verified by the online demo programm at 
http://tobago.atanion.net/tobago-example-demo/.

the requirement to the treelistbox is to allow the user to choose only one or 
more leafs in the tree at the same time without changing selection mode by the 
user before. the selectionmode should not be selected by the user and is set by 
the program always to siblingLeafOnly automatically.

the problems are: (with tree specially treelistbox and selectionmode 
siblingleafonly)

choosing one leaf (f.e. pictures) works fine. afterwards choosing more leafs 
(f.e. pictures, education) works also fine.
afterwards we want choose only one leaf again (f.e. pictures or education) this 
makes problem because the framework shows us
the choose before with more leafs (f.e. pictures and education marked as 
choosen) at this time we also become many javascript
error and warning messages shown in our javascript console.

the version 1.0.8 is working correct without this bug, but since version 1.0.9 
to 1.0.12 this problem/bug appears.

thanks for your help.

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



Re: [jira] Commented: (TOMAHAWK-128) Incorrect inputCalendar position when placed in DIV tag with position: absolute;

2007-11-28 Thread Richard Bremner

this does not seem to work. After applying the patch, I still have the
problem.

Richard

My Faces - Dev mailing list wrote:
 
 
 [
 https://issues.apache.org/jira/browse/TOMAHAWK-128?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531538
 ] 
 
 Thiago D. Freitas commented on TOMAHAWK-128:
 
 
 How to install this patch on my tomahawk?
 
 Incorrect inputCalendar position when placed in DIV tag with position:
 absolute;
 

 Key: TOMAHAWK-128
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-128
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Calendar
Reporter: Pawel Koloszko
Assignee: Martin Marinschek
 Fix For: 1.1.4-SNAPSHOT

 Attachments: popcalendar.js.diff


 On my page I have something like that
 t:div id=pageBody styleClass=pageBody
  t:inputCalendar id=dataUrodzenia renderAsPopup=true/
 /t:div
 pageBodyClass is:
 div.pageBody {
  position: absolute;
  top: 80px;
  left: 165px;
  bottom: 25px;
  width: 635px;   
 height: 400px;
 }
 With such layuot popupCalendar is not rendered next to inputCalendar
 button as it should.
 
 -- 
 This message is automatically generated by JIRA.
 -
 You can reply to this email to add a comment to the issue online.
 
 
 

-- 
View this message in context: 
http://www.nabble.com/-jira--Created%3A-%28MYFACES-1068%29-Incorrect-inputCalendar-position-when-placed-in-DIV-tag-with-position%3A-absolute--tf1009367.html#a13990599
Sent from the My Faces - Dev mailing list archive at Nabble.com.



Re: [Trinidad] open issues

2007-11-28 Thread Matthias Wessendorf
saw it.

will take care soon.

-M

On Nov 28, 2007 2:13 PM, Gerhard Petracek [EMAIL PROTECTED] wrote:
 hello matthias,

 today i opened a new issue and provided a patch - a new link for my
 previous list:
 https://issues.apache.org/jira/browse/TRINIDAD-842

 regards,
 gerhard

 @: the text of the mail is nearly the same again - however, it's really a
 new issue :)



 2007/11/27, Gerhard Petracek  [EMAIL PROTECTED]:

  hello matthias,
 
  today i opened a new issue and provided a patch - a new link for my
 previous list:
  https://issues.apache.org/jira/browse/TRINIDAD-841
 
  regards,
  gerhard
 
 
 
 
  2007/11/24, Gerhard Petracek  [EMAIL PROTECTED]:
 
   hello matthias,
  
   that's great!
  
   for the mentioned issue there is no patch available (at the moment) -
 this issue i would like to discuss (there are different possible solutions).
  
   i was referencing my other issues - at these issues you will find
 patches:
   https://issues.apache.org/jira/browse/TRINIDAD-768
   https://issues.apache.org/jira/browse/TRINIDAD-812
   https://issues.apache.org/jira/browse/TRINIDAD-830
  
   regards,
   gerhard
  
  
  
  
   2007/11/24, Matthias Wessendorf [EMAIL PROTECTED] :
  
Gerhard-
   
I am not seeing a patch attached.
   
-M
   
On Nov 24, 2007 1:50 PM, Matthias Wessendorf  [EMAIL PROTECTED]
 wrote:
 Glad you pointed that out.
 my goal for the patch day is:
 -apply Trinidad patches
 -apply MyFaces 1.2 patches (did some already yestrday)

 I'll take a look at yours!

 -Matthias


 On Nov 24, 2007 1:49 PM, Gerhard Petracek
 [EMAIL PROTECTED] wrote:
  hello,
 
  i've provided some patches for trinidad. is there already a
 planned version
  for these patches?
 
  furthermore, there is an open issue i would like to discuss.
  ( https://issues.apache.org/jira/browse/TRINIDAD-782 )
 
  regards,
  gerhard
 
  --
 
  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

   
   
   
--
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



-- 
Matthias Wessendorf

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


Re: [Trinidad] open issues

2007-11-28 Thread Gerhard Petracek
hello matthias,

today i opened a new issue and provided a patch - a new link for my
previous list:
https://issues.apache.org/jira/browse/TRINIDAD-842

regards,
gerhard

@: the text of the mail is nearly the same again - however, it's really a
new issue :)



2007/11/27, Gerhard Petracek [EMAIL PROTECTED]:

 hello matthias,

 today i opened a new issue and provided a patch - a new link for my
 previous list:
 https://issues.apache.org/jira/browse/TRINIDAD-841

 regards,
 gerhard



 2007/11/24, Gerhard Petracek [EMAIL PROTECTED]:
 
  hello matthias,
 
  that's great!
 
  for the mentioned issue there is no patch available (at the moment) -
  this issue i would like to discuss (there are different possible solutions).
 
  i was referencing my other issues - at these issues you will find
  patches:
  https://issues.apache.org/jira/browse/TRINIDAD-768
  https://issues.apache.org/jira/browse/TRINIDAD-812
  https://issues.apache.org/jira/browse/TRINIDAD-830
 
  regards,
  gerhard
 
 
 
  2007/11/24, Matthias Wessendorf [EMAIL PROTECTED] :
  
   Gerhard-
  
   I am not seeing a patch attached.
  
   -M
  
   On Nov 24, 2007 1:50 PM, Matthias Wessendorf  [EMAIL PROTECTED]
   wrote:
Glad you pointed that out.
my goal for the patch day is:
-apply Trinidad patches
-apply MyFaces 1.2 patches (did some already yestrday)
   
I'll take a look at yours!
   
-Matthias
   
   
On Nov 24, 2007 1:49 PM, Gerhard Petracek 
   [EMAIL PROTECTED] wrote:
 hello,

 i've provided some patches for trinidad. is there already a
   planned version
 for these patches?

 furthermore, there is an open issue i would like to discuss.
 ( https://issues.apache.org/jira/browse/TRINIDAD-782 )

 regards,
 gerhard

 --

 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
   
  
  
  
   --
   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: SortableModel and t:dataTable changes/improvements

2007-11-28 Thread Mike Kienenberger
Tomahawk's t:dataTable requires SortableDataModel, which is why that
check is in here.   At some point I'd love to see that requirement
relaxed, but no one has done further work toward that end.

I think the easiest thing to do right now is to subclass HtmlDataTable
and override createDataModel.

This is how I did it.

package test;

import java.util.Comparator;

import javax.faces.component.UIComponent;
import javax.faces.model.DataModel;

import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.apache.myfaces.component.html.ext.HtmlDataTable;

/**
 * @author Mike Kienenberger (latest modification by $Author: mlk $)
 * @version $id$
 */
public class SortableHtmlDataTable extends HtmlDataTable
{
private static final Log log =
LogFactory.getLog(SortableHtmlDataTable.class);

public static final String COMPARATOR_FACET_NAME = comparator;

/**
 * @see 
org.apache.myfaces.component.html.ext.HtmlDataTableHack#createDataModel()
 */
protected DataModel createDataModel()
{
DataModel dataModel = super.createDataModel();

UIComponent comparatorUIComponent = getComparator();
Comparator comparator = null;
if (null != comparatorUIComponent)
{
if (comparatorUIComponent instanceof ComparatorSource)
{
comparator =
((ComparatorSource)comparatorUIComponent).getComparator();
}
else
{
// TODO: need log error instead
throw new RuntimeException(comparatorUIComponent should
implement ComparatorSource);
}
}

boolean isSortable = null != comparator;

if (isSortable)
{
if (!(dataModel instanceof BaseSortableModel))
{
dataModel = new BaseSortableModel(dataModel);
}

((BaseSortableModel)dataModel).setComparator(comparator);
}

return dataModel;
}

/**
 * Gets the comparator facet for sorting.
 */
public UIComponent getComparator() {
return (UIComponent)getFacets().get(COMPARATOR_FACET_NAME);
}
public void setComparator(UIComponent comparator) {
getFacets().put(COMPARATOR_FACET_NAME, comparator);
}

//-- GENERATED CODE BEGIN (do not modify!)


public static final String COMPONENT_TYPE = test.SortableHtmlDataTable;
public static final String DEFAULT_RENDERER_TYPE =
org.apache.myfaces.Table;

}


On 11/27/07, CatalinPetrisor [EMAIL PROTECTED] wrote:

 I can subclass it of course, but because HtmlDataTable (in createDataModel
 method) checks if the DataModel is an instance of SortableDataModel, it will
 actually wrap my extended BaseSortableModel into a SortableModel, that will
 not use my custom defined comparator.

 I would expect that HtmlDataTable to use only BaseSortableModel and every
 time a column header link is clicked to notify me by which column the data
 to be sorted.

 Or maybe I got it wrong. Could you explain in few words how would you
 implement a custom sortable model starting from BaseSortableModel?

 Thanks.
 Catalin


 Mike Kienenberger wrote:
 
  It was left that way to provide identical backward compatible behavior.
 
  However, you should be able to subclass (or use) BaseSortableModel
  instead of the default sortable model.
 
  On 11/27/07, CatalinPetrisor [EMAIL PROTECTED] wrote:
 
  That's a very good idea. However, in the latest svn sources the
  HtmlDataTable
  component still uses SortableModel class to set the current sort column.
  Wouldn't be normal to use BaseSortableModel class to allow extensibility?
 
  Thanks.
 
 
  Mike Kienenberger wrote:
  
   As a first step in this process, I've separated SortableDataModel into
   SortableDataModel (current behavior, final, subclass of
   BaseSortableDataModel) and BaseSortableDataModel (extendable, works on
   Comparators).
  
   I tested all of the simple examples involving dataTable at one point,
   but it's possible that something may have slipped by me that I didn't
   notice.
  
  
   On 3/14/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
   I took a look at SortableModel and t:dataTable sorting again last
   night.  My requirements in most cases are to simply specify a sort
   order in the page code, not to allow end-users to manipulate the sort
   order.From what I can tell, there's no easy way to do this. I
   documented the most effective method I could find on the wiki under a
   static sorting subheading, but even that method leaves unnecessary
   links in the column headers.
  
   At the same time, I looked into what it would take to make sorting
   cleaner and more user-friendly.
  
   I came up with a subclass of extended dataTable and a replacement
   SortableModel that did what I wanted for the most part:
  
   my:sortableDataTable
   preserveDataModel=true
   

[jira] Resolved: (TOMAHAWK-6) MyFaces FileUpload Issues

2007-11-28 Thread Martin Marinschek (JIRA)

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

Martin Marinschek resolved TOMAHAWK-6.
--

   Resolution: Fixed
Fix Version/s: 1.1.7-SNAPSHOT
 Assignee: Martin Marinschek

Both issues fixed in latest head.

Thanks to Alexander Jesse for helping me to fix and test this.

regards,

Martin

 MyFaces FileUpload Issues
 -

 Key: TOMAHAWK-6
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-6
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: File Upload
Reporter: David F
Assignee: Martin Marinschek
 Fix For: 1.1.7-SNAPSHOT


 Their are two issues:
  The first issues is MyFaces defines an UploadFile Interface that you access 
 in
 your backing bean. The UploadedFile interface doesn't define a method for 
 deleting the temporary files that Commons File Upload creates on disk. These 
 files will be deleted only when the FileItem instances are garbage collected. 
 The DefaultFileItem class of Commons File Upload has a finalize() method that 
 deletes the temporary file managed by the object that is removed from memory. 
 If the application is uploading large files, we want to delete them right 
 after they are processed, without waiting for garbage collection. To be able 
 to do that, we would have to add a getFileItem() method (in 
 UploadedFileDefaultFileImpl) that should return the FileItem instance, which 
 has a delete() method. In addition, we would also have to add
 this to the UploadFile interface as well.
 The second issue is Their are two filter parameters in Myfaces file upload 
 component:  uploadThresholdSize and uploadMaxFileSize(both are required by 
 the Commons File Upload component) The uploadThresholdSize tells Common File 
 uploads to keep files in memory that are less than this size, and 
 uploadMaxFileSize says to ignore files that take less than this size.If you 
 try to upload a file that is too large, the current version of MyFaces 
 ignores all form data, as if the user submitted an empty form. If  we want to 
 signal the failed upload to the user, we would have to change the source code 
 of the MultipartRequestWrapper class of MyFaces and add a 
 FacesContext.getCurrentInstance().addMessage() to warn the user.

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



Re: svn commit: r599022 - in /myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces: custom/fileupload/ webapp/filter/

2007-11-28 Thread Matthias Wessendorf
can you add the license headers?
:-)

On Nov 28, 2007 4:14 PM,  [EMAIL PROTECTED] wrote:
 Author: mmarinschek
 Date: Wed Nov 28 07:14:17 2007
 New Revision: 599022

 URL: http://svn.apache.org/viewvc?rev=599022view=rev
 Log:
 fix for https://issues.apache.org/jira/browse/TOMAHAWK-6 (TOMAHAWK-6): Thanks 
 to Alexander Jesse for helping me fixing this and testing the fix

 Added:
 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/DiskStorageStrategy.java
 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/StorageStrategy.java
 Modified:
 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlFileUploadRenderer.java
 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlInputFileUpload.java
 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/UploadedFile.java
 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/UploadedFileDefaultFileImpl.java
 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/UploadedFileDefaultMemoryImpl.java
 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/webapp/filter/MultipartRequestWrapper.java

 Added: 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/DiskStorageStrategy.java
 URL: 
 http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/DiskStorageStrategy.java?rev=599022view=auto
 ==
 --- 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/DiskStorageStrategy.java
  (added)
 +++ 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/DiskStorageStrategy.java
  Wed Nov 28 07:14:17 2007
 @@ -0,0 +1,9 @@
 +package org.apache.myfaces.custom.fileupload;
 +
 +import java.io.File;
 +
 +public abstract class DiskStorageStrategy extends StorageStrategy {
 +
 +  public abstract File getTempFile();
 +
 +}

 Modified: 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlFileUploadRenderer.java
 URL: 
 http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlFileUploadRenderer.java?rev=599022r1=599021r2=599022view=diff
 ==
 --- 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlFileUploadRenderer.java
  (original)
 +++ 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlFileUploadRenderer.java
  Wed Nov 28 07:14:17 2007
 @@ -31,6 +31,7 @@

  import javax.faces.component.UIComponent;
  import javax.faces.context.FacesContext;
 +import javax.faces.FacesException;
  import javax.faces.context.ResponseWriter;
  import javax.faces.context.ExternalContext;
  import javax.faces.convert.ConverterException;
 @@ -126,7 +127,7 @@
  
 ((HtmlInputFileUpload)uiComponent).setSubmittedValue(upFile);
  ((HtmlInputFileUpload)uiComponent).setValid(true);
  }catch(IOException ioe){
 -log.error(ioe);
 +throw new FacesException(Exception while processing 
 file upload for file-input :  + uiComponent.getClientId(facesContext),ioe);
  }
  }
  return;
 @@ -165,7 +166,7 @@
  
 ((HtmlInputFileUpload)uiComponent).setSubmittedValue(upFile);
  ((HtmlInputFileUpload)uiComponent).setValid(true);
  }catch(IOException ioe){
 -log.error(ioe);
 +  throw new FacesException(Exception while processing 
 file upload for file-input :  + uiComponent.getClientId(facesContext),ioe);
  }
  }
  }

 Modified: 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlInputFileUpload.java
 URL: 
 http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlInputFileUpload.java?rev=599022r1=599021r2=599022view=diff
 ==
 --- 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlInputFileUpload.java
  (original)
 +++ 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlInputFileUpload.java
  Wed Nov 28 07:14:17 2007
 @@ -20,8 +20,10 @@

  import org.apache.myfaces.component.UserRoleAware;
  import org.apache.myfaces.component.UserRoleUtils;
 +import org.apache.myfaces.shared_tomahawk.util.MessageUtils;
  import org.apache.myfaces.shared_tomahawk.util._ComponentUtils;

 +import javax.faces.application.FacesMessage;
  import 

Re: [Trinidad] Adding additional accessibility features to skinning

2007-11-28 Thread Matt Cooper
Okay, we'll skip them for now and can reconsider later if people start
asking for it.

On Nov 27, 2007 2:54 PM, Jeanne Waldman [EMAIL PROTECTED] wrote:

 I don't know off the top of my head, but you can test this with the
 @agent style.
 If the base skin has @agent ie {.foo {some css properties}} and the
 extending skin has .foo not inside the @agent block, for ie, does this
 style get overridden?

 It is probably the case that they do get overwritten, in which case, I
 see your point, but we don't do that same thing for the other @rules.
 It makes the skin more complicated as well.

 Matt Cooper wrote:
  Hi Jeanne,
 
  The any-* types are for users that do not require specific
  consideration.  It is useful because then someone could define some
  styles without worry of negatively impacting users with special needs.
   In particular, it is most useful for people that extend skins.  If
  you are making a skin from scratch you can just use the defaults but
  if you don't want to override the painstakingly crafted styles for
  special needs users then any-* would give you this power.
 
  Is there another mechanism that exists today that would provide you this
 power?
 
  Thank you,
  Matt
 
  On Nov 19, 2007 3:58 PM, Jeanne Waldman [EMAIL PROTECTED]
 wrote:
  Hi Matt,
  I don't understand how any-* works. It seems like this is the 'default'
  which means there is no @accessibility-policy needed around the block
 of
  css.
  I don't understand your example of how this is useful. Can you
 elaborate?
 
  Thanks,
  - Jeanne
 
 
  Matt Cooper wrote:
  I've logged an improvement request for the following issue:
  https://issues.apache.org/jira/browse/TRINIDAD-822
 
  Before I start working on this, I wanted to gather feedback from you
 all.
 
  Thank you,
  Matt
 
 



Re: [vote] release of Trinidad plugins (1.2.5)

2007-11-28 Thread Matt Cooper
+1

On Nov 27, 2007 1:47 PM, Gary Kind [EMAIL PROTECTED] wrote:

 +1

 Jeanne Waldman wrote:
  +1
 
  Gabrielle Crawford wrote:
  +1
 
  Bruno Aranda wrote:
  +1
 
  On 27/11/2007, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 
  +1
 
  On Nov 27, 2007 10:26 AM, Matthias Wessendorf [EMAIL PROTECTED]
  wrote:
 
  Hi,
 
  I was running the needed tasks to get the 1.2.5 release of the
 Apache
  MyFaces Trinidad Maven 2 Plugins out.
 
  The artifacts are deployed to my private Apache account ([1]).
 
  Please take a look at the 1.2.5 artifacts and vote.
 
  How to test those JARs ?
 
  1. there is now a zip file (org.zip) (see [1])
  2. use the stage repo inside your pom.xml file:
  ...
  pluginRepositories
   pluginRepository
   idapache.stage/id
   nameApache Stage Repository/name
   
  urlhttp://people.apache.org/~matzew/125-pluginshttp://people.apache.org/%7Ematzew/125-plugins
 /url
   layoutdefault/layout
   /pluginRepository
  /pluginRepositories
  ...
 
  
  [ ] +1 for community members who have reviewed and tested the bits
  [ ] +0
  [ ] -1 for fatal flaws that should cause these bits not to be
  released,
and why..
  
 
  Thanks,
  Matthias
 
  [1] 
  http://people.apache.org/~matzew/125-pluginshttp://people.apache.org/%7Ematzew/125-plugins
 
  --
  Matthias Wessendorf
 
  further stuff:
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  mail: matzew-at-apache-dot-org
 
 
 
  --
  Matthias Wessendorf
 
  further stuff:
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  mail: matzew-at-apache-dot-org
 
 
 



Re: svn commit: r599022 - in /myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces: custom/fileupload/ webapp/filter/

2007-11-28 Thread Martin Marinschek
sure, done - sorry.

regards,

Martin

On 11/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 can you add the license headers?
 :-)

 On Nov 28, 2007 4:14 PM,  [EMAIL PROTECTED] wrote:
  Author: mmarinschek
  Date: Wed Nov 28 07:14:17 2007
  New Revision: 599022
 
  URL: http://svn.apache.org/viewvc?rev=599022view=rev
  Log:
  fix for https://issues.apache.org/jira/browse/TOMAHAWK-6 (TOMAHAWK-6):
 Thanks to Alexander Jesse for helping me fixing this and testing the fix
 
  Added:
 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/DiskStorageStrategy.java
 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/StorageStrategy.java
  Modified:
 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlFileUploadRenderer.java
 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlInputFileUpload.java
 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/UploadedFile.java
 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/UploadedFileDefaultFileImpl.java
 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/UploadedFileDefaultMemoryImpl.java
 
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/webapp/filter/MultipartRequestWrapper.java
 
  Added:
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/DiskStorageStrategy.java
  URL:
 http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/DiskStorageStrategy.java?rev=599022view=auto
 
 ==
  ---
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/DiskStorageStrategy.java
 (added)
  +++
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/DiskStorageStrategy.java
 Wed Nov 28 07:14:17 2007
  @@ -0,0 +1,9 @@
  +package org.apache.myfaces.custom.fileupload;
  +
  +import java.io.File;
  +
  +public abstract class DiskStorageStrategy extends StorageStrategy {
  +
  +  public abstract File getTempFile();
  +
  +}
 
  Modified:
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlFileUploadRenderer.java
  URL:
 http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlFileUploadRenderer.java?rev=599022r1=599021r2=599022view=diff
 
 ==
  ---
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlFileUploadRenderer.java
 (original)
  +++
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlFileUploadRenderer.java
 Wed Nov 28 07:14:17 2007
  @@ -31,6 +31,7 @@
 
   import javax.faces.component.UIComponent;
   import javax.faces.context.FacesContext;
  +import javax.faces.FacesException;
   import javax.faces.context.ResponseWriter;
   import javax.faces.context.ExternalContext;
   import javax.faces.convert.ConverterException;
  @@ -126,7 +127,7 @@
 
 ((HtmlInputFileUpload)uiComponent).setSubmittedValue(upFile);
   ((HtmlInputFileUpload)uiComponent).setValid(true);
   }catch(IOException ioe){
  -log.error(ioe);
  +throw new FacesException(Exception while processing
 file upload for file-input :  + uiComponent.getClientId(facesContext),ioe);
   }
   }
   return;
  @@ -165,7 +166,7 @@
 
 ((HtmlInputFileUpload)uiComponent).setSubmittedValue(upFile);
 
 ((HtmlInputFileUpload)uiComponent).setValid(true);
   }catch(IOException ioe){
  -log.error(ioe);
  +  throw new FacesException(Exception while
 processing file upload for file-input :  +
 uiComponent.getClientId(facesContext),ioe);
   }
   }
   }
 
  Modified:
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlInputFileUpload.java
  URL:
 http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlInputFileUpload.java?rev=599022r1=599021r2=599022view=diff
 
 ==
  ---
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlInputFileUpload.java
 (original)
  +++
 myfaces/tomahawk/trunk/core/src/main/java/org/apache/myfaces/custom/fileupload/HtmlInputFileUpload.java
 Wed Nov 28 07:14:17 2007
  @@ -20,8 +20,10 @@
 
   import org.apache.myfaces.component.UserRoleAware;
   import org.apache.myfaces.component.UserRoleUtils;
  +import org.apache.myfaces.shared_tomahawk.util.MessageUtils;
   import org.apache.myfaces.shared_tomahawk.util._ComponentUtils;
 
  +import 

[jira] Created: (TOBAGO-558) StringIndexOutOfBoundsException in MenuBarRenderer

2007-11-28 Thread Volker Weber (JIRA)
StringIndexOutOfBoundsException in MenuBarRenderer
--

 Key: TOBAGO-558
 URL: https://issues.apache.org/jira/browse/TOBAGO-558
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Core, Themes
Affects Versions: 1.0.12
Reporter: Volker Weber
Assignee: Volker Weber
 Fix For: 1.0.13


in a tc:menuRadio a StringIndexOutOfBoundsException occours if e.g.
a label as a underscore at index 9 and the next label has less then 9 chars.

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



[jira] Updated: (TRINIDAD-842) client-side validation and ppr

2007-11-28 Thread JIRA

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

Matthias Weßendorf updated TRINIDAD-842:


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

fix is only validating comps, that are in the DOM...

Thx to Gerhard Petracek for this fix.

 client-side validation and ppr
 --

 Key: TRINIDAD-842
 URL: https://issues.apache.org/jira/browse/TRINIDAD-842
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.0.3-core, 1.0.4-core
 Environment: i found this issue at the trinidad version 1.0.3 and 
 1.0.4 - in my opinion also other versions are affected
Reporter: Gerhard Petracek
Assignee: Matthias Weßendorf
 Fix For: 1.0.5-core

 Attachments: Core.js.patch


 scenario: to show/hide input components via ppr (which are e.g. in a logical 
 area - which is represented by a parent component - if the area is hidden, 
 it isn't in the dom.)
 (the rendered attribute is used here - the parent component (of the previous 
 mentioned parent component) has to be refreshed to show this area via ppr 
 again)
 however, if this area is rendered and the input components of this area use 
 client-side validation - javascript source-code gets added (dynamically) to 
 the form.
 after hiding the area again this client-side validation source-code remains 
 in place (until the whole form gets refreshed).
 - if a user tries to get to the next view, the client-side validation 
 source-code tries to validate components which aren't in the dom any more.
 workaround:
 don't use ppr for this area - trigger ppr for the complete form (i know - 
 it's not nice to do that - it's just a workaround)

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



[jira] Resolved: (TOBAGO-558) StringIndexOutOfBoundsException in MenuBarRenderer

2007-11-28 Thread Volker Weber (JIRA)

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

Volker Weber resolved TOBAGO-558.
-

Resolution: Fixed

 StringIndexOutOfBoundsException in MenuBarRenderer
 --

 Key: TOBAGO-558
 URL: https://issues.apache.org/jira/browse/TOBAGO-558
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Core, Themes
Affects Versions: 1.0.12
Reporter: Volker Weber
Assignee: Volker Weber
 Fix For: 1.0.13


 in a tc:menuRadio a StringIndexOutOfBoundsException occours if e.g.
 a label as a underscore at index 9 and the next label has less then 9 chars.

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



[jira] Created: (TOBAGO-559) Reduce content size of a button with accelerator.

2007-11-28 Thread Bernd Bohmann (JIRA)
Reduce content size of a button with accelerator.
-

 Key: TOBAGO-559
 URL: https://issues.apache.org/jira/browse/TOBAGO-559
 Project: MyFaces Tobago
  Issue Type: Improvement
Affects Versions: 1.0.12
Reporter: Bernd Bohmann
Assignee: Bernd Bohmann
 Fix For: 1.0.13


Move javascript code outside of button tag.

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



An Extensions Filter Bug

2007-11-28 Thread Carlos Adolfo Ortiz Quiros
HI you all

 

After a great amount of time trying to find why web page in the source code 
gets altered I concluded that the Extensions Filter is doing something that 
should not be doing or perhaps I don't know how to fix.

 

Here is the situation.

First code sample

%@ page contentType=text/html;charset=windows-1252%

%@ taglib uri=http://java.sun.com/jsf/html; prefix=h%

%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%

f:view

  html

head

  meta http-equiv=Content-Type

content=text/html; charset=windows-1252/

  meta name=Eddy Johana Angarita Navarro content=TRÉBOL Software 
S.A./meta

script type=text/javascript language=JavaScript





//Valida la longitud de un texto.

function validaLongitud(texto, longitud, e) {

if (!e) e = window.event;

 

if (!isEdicionKey(e)  texto.value.length = longitud) {

alert(No puede digitar más de  + longitud +  caracteres.);

return false;

}

 

return true;

}

// Valida si la tecla presionada es de edición.

// Utilizar unicamente en evento onkeydown.

function isEdicionKey(e) {

if (!e) e = window.event;

var key = e.which ? e.which : e.keyCode;

 

return (key==8 || key==9 || (key = 33  key = 40) || key==45 || key==46);

}

 

function doOnKeyDown(e) {

  var obj = document.getElementById(frmSistemas:nombreSistema);

  validaLongitud(obj.value, 10, e);

}

/script  

  titleThis is a full text sample/title

/head

body onload=alert('más o áéíóúñÑ');This is it verbatim and maacute;s to

   thish:form

h:inputText maxlength=10 onkeypress=return validaLongitud(this, 10, 
event);/

  /h:form/body

  /html

/f:view

 

See the text in bold above.

I am using MyFaces tomahawk and have configured the ExtensionsFilter as stated 
in the page http://myfaces.apache.org/tomahawk/extensionsFilter.html

 

I have put this page in a tomcat server and captured the generated java code 
and the characters are preserved but when I look at the source code in the 
Internet Browser, it gets altered to HTML characters, that is á is changed to 
aacute; or #255;.

 

See in page

%@ page contentType=text/html;charset=windows-1252%

meta http-equiv=Content-Type

content=text/html; charset=windows-1252/

 

To enforce page is interpreted correctly by browser

 

I think this is a bug because the whole page should not be encoded, only what 
needed by the filter.

Is there a way to fix this or it is indeed a bug in the library.

 

CARLOS ADOLFO ORTIZ Q

Ingeniero de Desarrollo

TRÉBOL Software S.A.

Tel : (574)3110663 Fax : (574)3113474

Dirección Cll 16 # 28-195

Medellín - Colombia

http://www.trebol.com.co http://www.trebol.com.co/ 

 

La información de este mensaje y sus anexos son propiedad exclusiva
de TRÉBOL Software S.A. Es  únicamente para el uso del destinatario
intencional  y  pueden  contener  información de carácter privado o
confidencial. Le  informamos que cualquier revisión, retransmisión,
divulgación,  copia  o  uso  indebido  del mismo está estrictamente
prohibida  y será sancionada legalmente.



Information contained in this message and every attachment is property of 
TREBOL Software S.A. Only the destiny user is able to make use of the data here 
contained, which is private and/or confidential. Any revision, broadcasting, 
spreading, copy or illegal use of this information is strictly prohibited and 
will be sanctioned by legal means.

Reminder: i18n Tomahawk Calendar patch

2007-11-28 Thread Hazem Saleh
Hi all,
Please apply this patch if you have sometime.
Here is the JIRA issue url :
https://issues.apache.org/jira/browse/TOMAHAWK-1155
This patch contains the arabization support for the Tomahawk Calendar
Thanks all very much.
I really appreciate your efforts.

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


RE: An Extensions Filter Bug

2007-11-28 Thread Carlos Adolfo Ortiz Quiros
I am using Tomahawk library, JSF1.2, and traed the f:verbatim and nothing 
happened that way. It is the extension filter.

-Mensaje original-
De: Scott O'Bryan [mailto:[EMAIL PROTECTED] 
Enviado el: Wednesday, November 28, 2007 3:42 PM
Para: MyFaces Development
Asunto: Re: An Extensions Filter Bug

Are you using JSF 1.2 or JSF 1.1. If you are using 1.1, you'll either 
want to use the f:verbatum tag to wrap non-faces content.

Scott

Carlos Adolfo Ortiz Quiros wrote:

 HI you all

 After a great amount of time trying to find why web page in the source 
 code gets altered I concluded that the Extensions Filter is doing 
 something that should not be doing or perhaps I don't know how to fix.

 Here is the situation.

 First code sample

 %@ page contentType=text/html;charset=windows-1252%

 %@ taglib uri=http://java.sun.com/jsf/html; prefix=h%

 %@ taglib uri=http://java.sun.com/jsf/core; prefix=f%

 f:view

 html

 head

 meta http-equiv=Content-Type

 content=text/html; charset=windows-1252/

 meta name=Eddy Johana Angarita Navarro content=TRÉBOL Software 
 S.A./meta

 script type=text/javascript language=JavaScript

 //Valida la longitud de un texto.

 function validaLongitud(texto, longitud, e) {

 if (!e) e = window.event;

 if (!isEdicionKey(e)  texto.value.length = longitud) {

 *alert(No puede digitar más de  + longitud +  caracteres.);*

 return false;

 }

 return true;

 }

 // Valida si la tecla presionada es de edición.

 // Utilizar unicamente en evento onkeydown.

 function isEdicionKey(e) {

 if (!e) e = window.event;

 var key = e.which ? e.which : e.keyCode;

 return (key==8 || key==9 || (key = 33  key = 40) || key==45 || 
 key==46);

 }

 function doOnKeyDown(e) {

 var obj = document.getElementById(frmSistemas:nombreSistema);

 validaLongitud(obj.value, 10, e);

 }

 /script

 titleThis is a full text sample/title

 /head

 body onload=*alert('más o áéíóúñÑ'*);This is it verbatim and 
 maacute;s to

 thish:form

 h:inputText maxlength=10 onkeypress=return validaLongitud(this, 
 10, event);/

 /h:form/body

 /html

 /f:view

 See the text in bold above.

 I am using MyFaces tomahawk and have configured the ExtensionsFilter 
 as stated in the page 
 http://myfaces.apache.org/tomahawk/extensionsFilter.html

 I have put this page in a tomcat server and captured the generated 
 java code and the characters are preserved but when I look at the 
 source code in the Internet Browser, it gets altered to HTML 
 characters, that is á is changed to aacute; or #255;.

 See in page

 %@ page contentType=text/html;charset=windows-1252%

 meta http-equiv=Content-Type

 content=text/html; charset=windows-1252/

 To enforce page is interpreted correctly by browser

 I think this is a bug because the whole page should not be encoded, 
 only what needed by the filter.

 Is there a way to fix this or it is indeed a bug in the library.

 **CARLOS ADOLFO ORTIZ Q**

 Ingeniero de Desarrollo

 **TRÉBOL Software S.A.**

 Tel : (574)3110663 Fax : (574)3113474

 Dirección Cll 16 # 28-195

 Medellín - Colombia

 http://www.trebol.com.co http://www.trebol.com.co/

 La información de este mensaje y sus anexos son propiedad exclusiva
 de TRÉBOL Software S.A. Es  únicamente para el uso del destinatario
 intencional  y  pueden  contener  información de carácter privado o
 confidencial. Le  informamos que cualquier revisión, retransmisión,
 divulgación,  copia  o  uso  indebido  del mismo está estrictamente
 prohibida  y será sancionada legalmente.



 Information contained in this message and every attachment is property of 
 TREBOL Software S.A. Only the destiny user is able to make use of the data 
 here contained, which is private and/or confidential. Any revision, 
 broadcasting, spreading, copy or illegal use of this information is strictly 
 prohibited and will be sanctioned by legal means.



La información de este mensaje y sus anexos son propiedad exclusiva
de TRÉBOL Software S.A. Es  únicamente para el uso del destinatario
intencional  y  pueden  contener  información de carácter privado o
confidencial. Le  informamos que cualquier revisión, retransmisión,
divulgación,  copia  o  uso  indebido  del mismo está estrictamente
prohibida  y será sancionada legalmente.



Information contained in this message and every attachment is property of 
TREBOL Software S.A. Only the destiny user is able to make use of the data here 
contained, which is private and/or confidential. Any revision, broadcasting, 
spreading, copy or illegal use of this information is strictly prohibited and 
will be sanctioned by legal means.

Re: An Extensions Filter Bug

2007-11-28 Thread Scott O'Bryan
Are you using JSF 1.2 or JSF 1.1. If you are using 1.1, you'll either 
want to use the f:verbatum tag to wrap non-faces content.


Scott

Carlos Adolfo Ortiz Quiros wrote:


HI you all

After a great amount of time trying to find why web page in the source 
code gets altered I concluded that the Extensions Filter is doing 
something that should not be doing or perhaps I don’t know how to fix.


Here is the situation.

First code sample

%@ page contentType=text/html;charset=windows-1252%

%@ taglib uri=http://java.sun.com/jsf/html; prefix=h%

%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%

f:view

html

head

meta http-equiv=Content-Type

content=text/html; charset=windows-1252/

meta name=Eddy Johana Angarita Navarro content=TRÉBOL Software 
S.A./meta


script type=text/javascript language=JavaScript

//Valida la longitud de un texto.

function validaLongitud(texto, longitud, e) {

if (!e) e = window.event;

if (!isEdicionKey(e)  texto.value.length = longitud) {

*alert(No puede digitar más de  + longitud +  caracteres.);*

return false;

}

return true;

}

// Valida si la tecla presionada es de edición.

// Utilizar unicamente en evento onkeydown.

function isEdicionKey(e) {

if (!e) e = window.event;

var key = e.which ? e.which : e.keyCode;

return (key==8 || key==9 || (key = 33  key = 40) || key==45 || 
key==46);


}

function doOnKeyDown(e) {

var obj = document.getElementById(frmSistemas:nombreSistema);

validaLongitud(obj.value, 10, e);

}

/script

titleThis is a full text sample/title

/head

body onload=*alert('más o áéíóúñÑ'*);This is it verbatim and 
maacute;s to


thish:form

h:inputText maxlength=10 onkeypress=return validaLongitud(this, 
10, event);/


/h:form/body

/html

/f:view

See the text in bold above.

I am using MyFaces tomahawk and have configured the ExtensionsFilter 
as stated in the page 
http://myfaces.apache.org/tomahawk/extensionsFilter.html


I have put this page in a tomcat server and captured the generated 
java code and the characters are preserved but when I look at the 
source code in the Internet Browser, it gets altered to HTML 
characters, that is á is changed to aacute; or #255;.


See in page

%@ page contentType=text/html;charset=windows-1252%

meta http-equiv=Content-Type

content=text/html; charset=windows-1252/

To enforce page is interpreted correctly by browser

I think this is a bug because the whole page should not be encoded, 
only what needed by the filter.


Is there a way to fix this or it is indeed a bug in the library.

**CARLOS ADOLFO ORTIZ Q**

Ingeniero de Desarrollo

**TRÉBOL Software S.A.**

Tel : (574)3110663 Fax : (574)3113474

Dirección Cll 16 # 28-195

Medellín - Colombia

http://www.trebol.com.co http://www.trebol.com.co/

La información de este mensaje y sus anexos son propiedad exclusiva
de TRÉBOL Software S.A. Es  únicamente para el uso del destinatario
intencional  y  pueden  contener  información de carácter privado o
confidencial. Le  informamos que cualquier revisión, retransmisión,
divulgación,  copia  o  uso  indebido  del mismo está estrictamente
prohibida  y será sancionada legalmente.



Information contained in this message and every attachment is property of 
TREBOL Software S.A. Only the destiny user is able to make use of the data here 
contained, which is private and/or confidential. Any revision, broadcasting, 
spreading, copy or illegal use of this information is strictly prohibited and 
will be sanctioned by legal means.




Re: An Extensions Filter Bug

2007-11-28 Thread Scott O'Bryan
Yeah sorry I got side tracked with the syntax.  :)  JSF1.2 handles 
inline html correctly.  :)


Now for your question.  What exactly are you asking?  In your page 
declaration, you are setting the charset to be windows-1252.  This means 
that code will be transmitted to the browser using that encoding.  The 
meta tag tells the browser what character set you are using.  Should it 
be doing something different?


Scott

Carlos Adolfo Ortiz Quiros wrote:

I am using Tomahawk library, JSF1.2, and traed the f:verbatim and nothing 
happened that way. It is the extension filter.

-Mensaje original-
De: Scott O'Bryan [mailto:[EMAIL PROTECTED] 
Enviado el: Wednesday, November 28, 2007 3:42 PM

Para: MyFaces Development
Asunto: Re: An Extensions Filter Bug

Are you using JSF 1.2 or JSF 1.1. If you are using 1.1, you'll either 
want to use the f:verbatum tag to wrap non-faces content.


Scott

Carlos Adolfo Ortiz Quiros wrote:
  

HI you all

After a great amount of time trying to find why web page in the source 
code gets altered I concluded that the Extensions Filter is doing 
something that should not be doing or perhaps I don't know how to fix.


Here is the situation.

First code sample

%@ page contentType=text/html;charset=windows-1252%

%@ taglib uri=http://java.sun.com/jsf/html; prefix=h%

%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%

f:view

html

head

meta http-equiv=Content-Type

content=text/html; charset=windows-1252/

meta name=Eddy Johana Angarita Navarro content=TRÉBOL Software 
S.A./meta


script type=text/javascript language=JavaScript

//Valida la longitud de un texto.

function validaLongitud(texto, longitud, e) {

if (!e) e = window.event;

if (!isEdicionKey(e)  texto.value.length = longitud) {

*alert(No puede digitar más de  + longitud +  caracteres.);*

return false;

}

return true;

}

// Valida si la tecla presionada es de edición.

// Utilizar unicamente en evento onkeydown.

function isEdicionKey(e) {

if (!e) e = window.event;

var key = e.which ? e.which : e.keyCode;

return (key==8 || key==9 || (key = 33  key = 40) || key==45 || 
key==46);


}

function doOnKeyDown(e) {

var obj = document.getElementById(frmSistemas:nombreSistema);

validaLongitud(obj.value, 10, e);

}

/script

titleThis is a full text sample/title

/head

body onload=*alert('más o áéíóúñÑ'*);This is it verbatim and 
maacute;s to


thish:form

h:inputText maxlength=10 onkeypress=return validaLongitud(this, 
10, event);/


/h:form/body

/html

/f:view

See the text in bold above.

I am using MyFaces tomahawk and have configured the ExtensionsFilter 
as stated in the page 
http://myfaces.apache.org/tomahawk/extensionsFilter.html


I have put this page in a tomcat server and captured the generated 
java code and the characters are preserved but when I look at the 
source code in the Internet Browser, it gets altered to HTML 
characters, that is á is changed to aacute; or #255;.


See in page

%@ page contentType=text/html;charset=windows-1252%

meta http-equiv=Content-Type

content=text/html; charset=windows-1252/

To enforce page is interpreted correctly by browser

I think this is a bug because the whole page should not be encoded, 
only what needed by the filter.


Is there a way to fix this or it is indeed a bug in the library.

**CARLOS ADOLFO ORTIZ Q**

Ingeniero de Desarrollo

**TRÉBOL Software S.A.**

Tel : (574)3110663 Fax : (574)3113474

Dirección Cll 16 # 28-195

Medellín - Colombia

http://www.trebol.com.co http://www.trebol.com.co/

La información de este mensaje y sus anexos son propiedad exclusiva
de TRÉBOL Software S.A. Es  únicamente para el uso del destinatario
intencional  y  pueden  contener  información de carácter privado o
confidencial. Le  informamos que cualquier revisión, retransmisión,
divulgación,  copia  o  uso  indebido  del mismo está estrictamente
prohibida  y será sancionada legalmente.



Information contained in this message and every attachment is property of 
TREBOL Software S.A. Only the destiny user is able to make use of the data here 
contained, which is private and/or confidential. Any revision, broadcasting, 
spreading, copy or illegal use of this information is strictly prohibited and 
will be sanctioned by legal means.





La información de este mensaje y sus anexos son propiedad exclusiva
de TRÉBOL Software S.A. Es  únicamente para el uso del destinatario
intencional  y  pueden  contener  información de carácter privado o
confidencial. Le  informamos que cualquier revisión, retransmisión,
divulgación,  copia  o  uso  indebido  del mismo está estrictamente
prohibida  y será sancionada legalmente.



Information contained in this message and every attachment is property of 
TREBOL Software S.A. Only the destiny user is able to make use of the data here 
contained, which is private and/or confidential. Any revision, broadcasting, 
spreading, copy or illegal use of this information is strictly prohibited and 
will be sanctioned by legal means.




RE: An Extensions Filter Bug

2007-11-28 Thread Carlos Adolfo Ortiz Quiros
You are right. I am trying to encode page as Windows-1252 page. The problem as 
you can read the JSP page I have included, in the original message. There I 
have characters like á, I ask the Tomcat server to handle the page and I 
capture the generated Java source for page and the characters like á is therein 
and the page gets to the Internet browser but surprise, when I look at the 
generated code the á is converted to a#255; which is the equivalent to the á 
in HTML encoding.

I am using Tomahawk 1.1.6
MyFaces Tomahawk 1.1.6 Distribution and configured the Extensions Filter 
because I indeed use the t:Tags such as t:inputcalendar, etc, and if I put this 
Extension the page works well (although in the example there is no reference to 
it, but elsewhere the page works but renders á the way I don't want, and if I 
take away the Extension filter and use t:inputCalendar an exception is 
raisedthat's why I suspect this is a bug.

You can try for yourself, I think!


-Mensaje original-
De: Scott O'Bryan [mailto:[EMAIL PROTECTED] 
Enviado el: Wednesday, November 28, 2007 4:16 PM
Para: MyFaces Development
Asunto: Re: An Extensions Filter Bug

Yeah sorry I got side tracked with the syntax.  :)  JSF1.2 handles 
inline html correctly.  :)

Now for your question.  What exactly are you asking?  In your page 
declaration, you are setting the charset to be windows-1252.  This means 
that code will be transmitted to the browser using that encoding.  The 
meta tag tells the browser what character set you are using.  Should it 
be doing something different?

Scott

Carlos Adolfo Ortiz Quiros wrote:
 I am using Tomahawk library, JSF1.2, and traed the f:verbatim and nothing 
 happened that way. It is the extension filter.

 -Mensaje original-
 De: Scott O'Bryan [mailto:[EMAIL PROTECTED] 
 Enviado el: Wednesday, November 28, 2007 3:42 PM
 Para: MyFaces Development
 Asunto: Re: An Extensions Filter Bug

 Are you using JSF 1.2 or JSF 1.1. If you are using 1.1, you'll either 
 want to use the f:verbatum tag to wrap non-faces content.

 Scott

 Carlos Adolfo Ortiz Quiros wrote:
   
 HI you all

 After a great amount of time trying to find why web page in the source 
 code gets altered I concluded that the Extensions Filter is doing 
 something that should not be doing or perhaps I don't know how to fix.

 Here is the situation.

 First code sample

 %@ page contentType=text/html;charset=windows-1252%

 %@ taglib uri=http://java.sun.com/jsf/html; prefix=h%

 %@ taglib uri=http://java.sun.com/jsf/core; prefix=f%

 f:view

 html

 head

 meta http-equiv=Content-Type

 content=text/html; charset=windows-1252/

 meta name=Eddy Johana Angarita Navarro content=TRÉBOL Software 
 S.A./meta

 script type=text/javascript language=JavaScript

 //Valida la longitud de un texto.

 function validaLongitud(texto, longitud, e) {

 if (!e) e = window.event;

 if (!isEdicionKey(e)  texto.value.length = longitud) {

 *alert(No puede digitar más de  + longitud +  caracteres.);*

 return false;

 }

 return true;

 }

 // Valida si la tecla presionada es de edición.

 // Utilizar unicamente en evento onkeydown.

 function isEdicionKey(e) {

 if (!e) e = window.event;

 var key = e.which ? e.which : e.keyCode;

 return (key==8 || key==9 || (key = 33  key = 40) || key==45 || 
 key==46);

 }

 function doOnKeyDown(e) {

 var obj = document.getElementById(frmSistemas:nombreSistema);

 validaLongitud(obj.value, 10, e);

 }

 /script

 titleThis is a full text sample/title

 /head

 body onload=*alert('más o áéíóúñÑ'*);This is it verbatim and 
 maacute;s to

 thish:form

 h:inputText maxlength=10 onkeypress=return validaLongitud(this, 
 10, event);/

 /h:form/body

 /html

 /f:view

 See the text in bold above.

 I am using MyFaces tomahawk and have configured the ExtensionsFilter 
 as stated in the page 
 http://myfaces.apache.org/tomahawk/extensionsFilter.html

 I have put this page in a tomcat server and captured the generated 
 java code and the characters are preserved but when I look at the 
 source code in the Internet Browser, it gets altered to HTML 
 characters, that is á is changed to aacute; or #255;.

 See in page

 %@ page contentType=text/html;charset=windows-1252%

 meta http-equiv=Content-Type

 content=text/html; charset=windows-1252/

 To enforce page is interpreted correctly by browser

 I think this is a bug because the whole page should not be encoded, 
 only what needed by the filter.

 Is there a way to fix this or it is indeed a bug in the library.

 **CARLOS ADOLFO ORTIZ Q**

 Ingeniero de Desarrollo

 **TRÉBOL Software S.A.**

 Tel : (574)3110663 Fax : (574)3113474

 Dirección Cll 16 # 28-195

 Medellín - Colombia

 http://www.trebol.com.co http://www.trebol.com.co/

 La información de este mensaje y sus anexos son propiedad exclusiva
 de TRÉBOL Software S.A. Es  únicamente para el uso del destinatario
 intencional  y  pueden  contener  información de carácter privado o
 confidencial. Le  informamos que 

Re: [result][vote] start up the MyFaces Commons project

2007-11-28 Thread Matthias Wessendorf
Hi,

it is that case, that Bernd I and meet next weekend.
If you guys don't mind, we start the commons project, as discussed here.

Like maven-stuff etc.

-Matthias

On Nov 13, 2007 7:27 PM, Mario Ivankovits [EMAIL PROTECTED] wrote:
 Hi!
  BTW, I do not understand why some of you are so scared by multiple
  jsfcommons artifacts.
 I see it being much work to maintain ... but anyway, since you are the
 one who is going to do the initial maven work :-) I do no longer argue
 against.
 So, can we start now ;-) ?

 Ciao,
 Mario





-- 
Matthias Wessendorf

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


[jira] Created: (TRINIDAD-843) Jdev plugin - Nullpointer exception

2007-11-28 Thread Aino Andriessen (JIRA)
Jdev plugin - Nullpointer exception
---

 Key: TRINIDAD-843
 URL: https://issues.apache.org/jira/browse/TRINIDAD-843
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Plugins
Affects Versions: 1.2.5-plugins,  1.2.4.1-plugins
 Environment: Windows
Reporter: Aino Andriessen


When running the jdev plugin, a nullpointer occurs with the (new) code for 
handling taglibs. The WEB-INF\lib directory of my projects are empty or are not 
present at all.

Stacktrace :

[INFO] 
[INFO] Building Default ADF Faces application : jdevplugin
[INFO]task-segment: [jdev:jdev]
[INFO] 
[INFO] Preparing jdev:jdev
[INFO] No goals needed for project - skipping
[INFO] [jdev:jdev]
[INFO] Generating JDeveloper 10.1.3.0.4 workspace: jdevplugin
[INFO] 
[INFO] Building The generated jdevplugin model project
[INFO]task-segment: [jdev:jdev]
[INFO] 
[INFO] Preparing jdev:jdev
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [jdev:jdev]
[INFO] Generating JDeveloper 10.1.3.0.4 Project jdevplugin-model
[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] null
[INFO] 
[INFO] Trace
java.lang.NullPointerException
at 
org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.replaceLocalTagLibraries(JDeveloperMojo.java:904)
at 
org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.replaceTagLibraries(JDeveloperMojo.java:1113)
at 
org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.generateProject(JDeveloperMojo.java:398)
at 
org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.generateProject(JDeveloperMojo.java:315)
at 
org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.execute(JDeveloperMojo.java:227)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)

at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] 
[INFO] Total time: 3 seconds
[INFO] Finished at: Wed Nov 28 22:02:12 CET 2007
[INFO] Final Memory: 3M/7M
[INFO] 

D:\tmp\test_projects\jdevplugin

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



[jira] Issue Comment Edited: (TRINIDAD-843) Jdev plugin - Nullpointer exception

2007-11-28 Thread Aino Andriessen (JIRA)

[ 
https://issues.apache.org/jira/browse/TRINIDAD-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546417
 ] 

aino_a edited comment on TRINIDAD-843 at 11/28/07 1:42 PM:


It seems that the patch of the related issue causes the problems.

  was (Author: aino_a):
It seems that this patch causes the problems.
  
 Jdev plugin - Nullpointer exception
 ---

 Key: TRINIDAD-843
 URL: https://issues.apache.org/jira/browse/TRINIDAD-843
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Plugins
Affects Versions: 1.2.5-plugins,  1.2.4.1-plugins
 Environment: Windows
Reporter: Aino Andriessen

 When running the jdev plugin, a nullpointer occurs with the (new) code for 
 handling taglibs. The WEB-INF\lib directory of my projects are empty or are 
 not present at all.
 Stacktrace :
 [INFO] 
 
 [INFO] Building Default ADF Faces application : jdevplugin
 [INFO]task-segment: [jdev:jdev]
 [INFO] 
 
 [INFO] Preparing jdev:jdev
 [INFO] No goals needed for project - skipping
 [INFO] [jdev:jdev]
 [INFO] Generating JDeveloper 10.1.3.0.4 workspace: jdevplugin
 [INFO] 
 
 [INFO] Building The generated jdevplugin model project
 [INFO]task-segment: [jdev:jdev]
 [INFO] 
 
 [INFO] Preparing jdev:jdev
 [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [jdev:jdev]
 [INFO] Generating JDeveloper 10.1.3.0.4 Project jdevplugin-model
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] null
 [INFO] 
 
 [INFO] Trace
 java.lang.NullPointerException
 at 
 org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.replaceLocalTagLibraries(JDeveloperMojo.java:904)
 at 
 org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.replaceTagLibraries(JDeveloperMojo.java:1113)
 at 
 org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.generateProject(JDeveloperMojo.java:398)
 at 
 org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.generateProject(JDeveloperMojo.java:315)
 at 
 org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.execute(JDeveloperMojo.java:227)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 [INFO] 
 
 [INFO] Total time: 3 seconds
 [INFO] Finished at: Wed Nov 28 22:02:12 CET 2007
 [INFO] Final Memory: 3M/7M
 [INFO] 
 
 D:\tmp\test_projects\jdevplugin

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



Re: [vote] release of Trinidad plugins (1.2.5)

2007-11-28 Thread Matthias Wessendorf
yes, just noticed that bug...
fix you have a fix, I can replace the JARs tomorrow :-)

On Nov 28, 2007 10:53 PM, Matt Cooper [EMAIL PROTECTED] wrote:
 Perhaps this release should wait on a fix for:
 https://issues.apache.org/jira/browse/TRINIDAD-843



 On Nov 28, 2007 8:29 AM, Matt Cooper  [EMAIL PROTECTED] wrote:
  +1
 
 
 
 
 
  On Nov 27, 2007 1:47 PM, Gary Kind [EMAIL PROTECTED] wrote:
 
   +1
  
  
  
  
   Jeanne Waldman wrote:
+1
   
Gabrielle Crawford wrote:
+1
   
Bruno Aranda wrote:
+1
   
On 27/11/2007, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
   
+1
   
On Nov 27, 2007 10:26 AM, Matthias Wessendorf  [EMAIL PROTECTED]
wrote:
   
Hi,
   
I was running the needed tasks to get the 1.2.5 release of the
 Apache
MyFaces Trinidad Maven 2 Plugins out.
   
The artifacts are deployed to my private Apache account ([1]).
   
Please take a look at the  1.2.5 artifacts and vote.
   
How to test those JARs ?
   
1. there is now a zip file (org.zip) (see [1])
2. use the stage repo inside your pom.xml file:
...
pluginRepositories
 pluginRepository
 idapache.stage/id
 nameApache Stage Repository/name
 urlhttp://people.apache.org/~matzew/125-plugins/url
 layoutdefault/layout
 /pluginRepository
/pluginRepositories
...
   

[ ] +1 for community members who have reviewed and tested the bits
[ ] +0
[ ] -1 for fatal flaws that should cause these bits not to be
released,
  and why..

   
Thanks,
Matthias
   
[1] http://people.apache.org/~matzew/125-plugins
   
--
Matthias Wessendorf
   
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
   
   
   
--
Matthias Wessendorf
   
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
   
   
   
  
 
 





-- 
Matthias Wessendorf

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


[jira] Commented: (TRINIDAD-177) JDev plugin - compiler configuration

2007-11-28 Thread Aino Andriessen (JIRA)

[ 
https://issues.apache.org/jira/browse/TRINIDAD-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546429
 ] 

Aino Andriessen commented on TRINIDAD-177:
--

Patch still needs to be applied. 
Patch is still valid for version 1.2.4 and higher (1.2.4.1 and 1.2.5-SNAPSHOT) 
. 
Tested it today with JDeveloper 10.1.3.3 and the 1.2.4 release. 
The patch applies correctly with the other (later) releases too but I could not 
test the result because of issue TRINIDAD-843. 
Still have to test the version 11 .

 JDev plugin - compiler configuration
 

 Key: TRINIDAD-177
 URL: https://issues.apache.org/jira/browse/TRINIDAD-177
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Plugins
Affects Versions: 1.0.1-incubating-plugins-SNAPSHOT
 Environment: Windows XP, JDeveloper 10.1.3.1 (.0.3984)
Reporter: Aino Andriessen
 Fix For: 1.0.1-incubating-plugins-SNAPSHOT

 Attachments: project.xml.10.1.3.0.4.patch


 The compiler configuration of the plugin conflicts with the business 
 components wizard.
 The jdev plugin configures a reverse filter on the 'Copy File Types to Output 
 Directory' and only adds .java on this list. 
 However, when you create a new business component (actually only the first in 
 a project), a bunch of extensions are added to this list that now contains 
 the following entries: 
 .java;.xml;.jpx;.xcfg;.xml;.xml;.xml;.xml;.xml;.xml;.xml
 When you try to test the model application an exception is raised (I am sorry 
 for the french text) that it cannot find the Model.jpx file:
 JBO-30003: Le pool d'applications (.10F6E9C218F) n'a pas réussi à extraire 
 (check out) un module d'application en raison de l'exception suivante :
 oracle.jbo.JboException: JBO-29000: JBO-29000: JBO-25222: Impossible de créer 
 le module dapplication.
 ...
 javax.naming.NamingException [Root exception is 
 oracle.jbo.NoXMLFileException: JBO-26001: Fichier XML introuvable pour le 
 conteneur /Model.jpx]
 This is as expected, because that file is not copied to the classpath (due to 
 the Reverse Filter), but highly unwanted.

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



Re: [vote] release of Trinidad plugins (1.2.5)

2007-11-28 Thread Matt Cooper
Perhaps this release should wait on a fix for:
https://issues.apache.org/jira/browse/TRINIDAD-843

On Nov 28, 2007 8:29 AM, Matt Cooper [EMAIL PROTECTED] wrote:

 +1


 On Nov 27, 2007 1:47 PM, Gary Kind [EMAIL PROTECTED] wrote:

  +1
 
  Jeanne Waldman wrote:
   +1
  
   Gabrielle Crawford wrote:
   +1
  
   Bruno Aranda wrote:
   +1
  
   On 27/11/2007, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
  
   +1
  
   On Nov 27, 2007 10:26 AM, Matthias Wessendorf  [EMAIL PROTECTED]
   wrote:
  
   Hi,
  
   I was running the needed tasks to get the 1.2.5 release of the
  Apache
   MyFaces Trinidad Maven 2 Plugins out.
  
   The artifacts are deployed to my private Apache account ([1]).
  
   Please take a look at the  1.2.5 artifacts and vote.
  
   How to test those JARs ?
  
   1. there is now a zip file (org.zip) (see [1])
   2. use the stage repo inside your pom.xml file:
   ...
   pluginRepositories
pluginRepository
idapache.stage/id
nameApache Stage Repository/name

   urlhttp://people.apache.org/~matzew/125-pluginshttp://people.apache.org/%7Ematzew/125-plugins
  /url
layoutdefault/layout
/pluginRepository
   /pluginRepositories
   ...
  
   
   [ ] +1 for community members who have reviewed and tested the bits
   [ ] +0
   [ ] -1 for fatal flaws that should cause these bits not to be
   released,
 and why..
   
  
   Thanks,
   Matthias
  
   [1] 
   http://people.apache.org/~matzew/125-pluginshttp://people.apache.org/%7Ematzew/125-plugins
  
   --
   Matthias Wessendorf
  
   further stuff:
   blog: http://matthiaswessendorf.wordpress.com/
   sessions: http://www.slideshare.net/mwessendorf
   mail: matzew-at-apache-dot-org
  
  
  
   --
   Matthias Wessendorf
  
   further stuff:
   blog: http://matthiaswessendorf.wordpress.com/
   sessions: http://www.slideshare.net/mwessendorf
   mail: matzew-at-apache-dot-org
  
  
  
 




[jira] Created: (TRINIDAD-844) JDev plugin - JHeadstart

2007-11-28 Thread Aino Andriessen (JIRA)
JDev plugin - JHeadstart


 Key: TRINIDAD-844
 URL: https://issues.apache.org/jira/browse/TRINIDAD-844
 Project: MyFaces Trinidad
  Issue Type: Wish
  Components: Plugins
Reporter: Aino Andriessen


It would be great if the jpr file could include the JHeadstart tag that 
identifies that JHeadstart is enabled on the project, instead of manually 
adding that tag.
It only requires the element : value n=JHEADSTART_ENABLED v=10.1.3.2.51/
This could be identified in the pom file with a property like 
jheadstart.version (or so).


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



Re: [vote] release of Trinidad plugins (1.2.5)

2007-11-28 Thread Matt Cooper
Okay, I'll -1 this release until TRINIDAD-843 is resolved (appears to be a
side effect of the fix for TRINIDAD-808).

On Nov 28, 2007 2:55 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:

 yes, just noticed that bug...
 fix you have a fix, I can replace the JARs tomorrow :-)

 On Nov 28, 2007 10:53 PM, Matt Cooper [EMAIL PROTECTED] wrote:
  Perhaps this release should wait on a fix for:
  https://issues.apache.org/jira/browse/TRINIDAD-843
 
 
 
  On Nov 28, 2007 8:29 AM, Matt Cooper  [EMAIL PROTECTED] wrote:
   +1
  
  
  
  
  
   On Nov 27, 2007 1:47 PM, Gary Kind [EMAIL PROTECTED] wrote:
  
+1
   
   
   
   
Jeanne Waldman wrote:
 +1

 Gabrielle Crawford wrote:
 +1

 Bruno Aranda wrote:
 +1

 On 27/11/2007, Matthias Wessendorf  [EMAIL PROTECTED] wrote:

 +1

 On Nov 27, 2007 10:26 AM, Matthias Wessendorf 
 [EMAIL PROTECTED]
 wrote:

 Hi,

 I was running the needed tasks to get the 1.2.5 release of the
  Apache
 MyFaces Trinidad Maven 2 Plugins out.

 The artifacts are deployed to my private Apache account ([1]).

 Please take a look at the  1.2.5 artifacts and vote.

 How to test those JARs ?

 1. there is now a zip file (org.zip) (see [1])
 2. use the stage repo inside your pom.xml file:
 ...
 pluginRepositories
  pluginRepository
  idapache.stage/id
  nameApache Stage Repository/name
  
 urlhttp://people.apache.org/~matzew/125-pluginshttp://people.apache.org/%7Ematzew/125-plugins
 /url
  layoutdefault/layout
  /pluginRepository
 /pluginRepositories
 ...

 
 [ ] +1 for community members who have reviewed and tested the
 bits
 [ ] +0
 [ ] -1 for fatal flaws that should cause these bits not to be
 released,
   and why..
 

 Thanks,
 Matthias

 [1] 
 http://people.apache.org/~matzew/125-pluginshttp://people.apache.org/%7Ematzew/125-plugins

 --
 Matthias Wessendorf

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



 --
 Matthias Wessendorf

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



   
  
  
 
 



 --
 Matthias Wessendorf

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



Re: [vote] release of Trinidad plugins (1.2.5)

2007-11-28 Thread Matthias Wessendorf
-1 on this release, because of the 843 issue.
let me check it tomorrow morning.


On Nov 28, 2007 10:55 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 yes, just noticed that bug...
 fix you have a fix, I can replace the JARs tomorrow :-)


 On Nov 28, 2007 10:53 PM, Matt Cooper [EMAIL PROTECTED] wrote:
  Perhaps this release should wait on a fix for:
  https://issues.apache.org/jira/browse/TRINIDAD-843
 
 
 
  On Nov 28, 2007 8:29 AM, Matt Cooper  [EMAIL PROTECTED] wrote:
   +1
  
  
  
  
  
   On Nov 27, 2007 1:47 PM, Gary Kind [EMAIL PROTECTED] wrote:
  
+1
   
   
   
   
Jeanne Waldman wrote:
 +1

 Gabrielle Crawford wrote:
 +1

 Bruno Aranda wrote:
 +1

 On 27/11/2007, Matthias Wessendorf  [EMAIL PROTECTED] wrote:

 +1

 On Nov 27, 2007 10:26 AM, Matthias Wessendorf  [EMAIL PROTECTED]
 wrote:

 Hi,

 I was running the needed tasks to get the 1.2.5 release of the
  Apache
 MyFaces Trinidad Maven 2 Plugins out.

 The artifacts are deployed to my private Apache account ([1]).

 Please take a look at the  1.2.5 artifacts and vote.

 How to test those JARs ?

 1. there is now a zip file (org.zip) (see [1])
 2. use the stage repo inside your pom.xml file:
 ...
 pluginRepositories
  pluginRepository
  idapache.stage/id
  nameApache Stage Repository/name
  urlhttp://people.apache.org/~matzew/125-plugins/url
  layoutdefault/layout
  /pluginRepository
 /pluginRepositories
 ...

 
 [ ] +1 for community members who have reviewed and tested the bits
 [ ] +0
 [ ] -1 for fatal flaws that should cause these bits not to be
 released,
   and why..
 

 Thanks,
 Matthias

 [1] http://people.apache.org/~matzew/125-plugins

 --
 Matthias Wessendorf

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



 --
 Matthias Wessendorf

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



   
  
  
 
 



 --

 Matthias Wessendorf

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




-- 
Matthias Wessendorf

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


[Trinidad] tr:tree component rowSelection attribute

2007-11-28 Thread Abhinav Korlakunta
Hi,
I am trying to use 'rowSelection' attribute on 'tree' component but I am not 
able to find it in the tag documentation attribute list. 
 
But here, http://myfaces.apache.org/trinidad/devguide/tree.html#SelectionEvent 
, in the tree component dev guide the attribute is explained clearly. Is this 
document very old? rowSelection only applies to treeTable component?
 
Thank you,
-Abhinav.
The information transmitted herewith is sensitive  information of Chordiant 
Software or its customers and is intended only for use to the individual or 
entity to which it is addressed. If the reader of this message is not the 
intended recipient, you are hereby notified that any review, retransmission, 
dissemination, distribution, copying or other use of, or taking of any action 
in reliance upon, this information is strictly prohibited. If you have received 
this communication in error, please contact the sender and delete the material 
from your computer.


How to effectivly change the CSS for INPUTCalendar

2007-11-28 Thread Carlos Adolfo Ortiz Quiros
What is the best or suggested way to change the CSS for the InputCalendar?

 

CARLOS ADOLFO ORTIZ Q

Ingeniero de Desarrollo

TRÉBOL Software S.A.

Tel : (574)3110663 Fax : (574)3113474

Dirección Cll 16 # 28-195

Medellín - Colombia

http://www.trebol.com.co http://www.trebol.com.co/ 

 

La información de este mensaje y sus anexos son propiedad exclusiva
de TRÉBOL Software S.A. Es  únicamente para el uso del destinatario
intencional  y  pueden  contener  información de carácter privado o
confidencial. Le  informamos que cualquier revisión, retransmisión,
divulgación,  copia  o  uso  indebido  del mismo está estrictamente
prohibida  y será sancionada legalmente.



Information contained in this message and every attachment is property of 
TREBOL Software S.A. Only the destiny user is able to make use of the data here 
contained, which is private and/or confidential. Any revision, broadcasting, 
spreading, copy or illegal use of this information is strictly prohibited and 
will be sanctioned by legal means.

Re: [result][vote] start up the MyFaces Commons project

2007-11-28 Thread Manfred Geiler
yes, fine!
please consider the following structure:

myfaces-jsfcommons
   | myfaces-jsfcommons-api
   | myfaces-jsfcommons-impl
   | myfaces-jsfcommons-sandbox

(we must avoid the name myfaces-commons for there was once a project
with that name - see maven repo!)

api = the classes and interfaces, that users will directly use (ie.
import) in their code (= compile scope dependency)
impl = internal implementation classes, users will need during runtime
only (= runtime scope dependency)

furthermore:
 - api classes and interfaces must not change between two bugfix
releases (eg. from 1.0.0 to 1.0.1)
 - api classes and interfaces might vary (be extended) between two
minor releases (eg. from 1.0.3 to 1.1.0) - BUT only backwards
compatible!
 - api classes and interfaces might be totally different between two
major releases (eg. from 1.5.3 to 2.0.0) - BUT need not  ;-)
 - impl classes (and interfaces) can be changed, added, removed,
refactored whenever needed

This is no unnecessary effort IMHO. jsfcommons can only be successful
and widely accepted if users can confide in a stable API that is not
subject to change on every single release. In a community driven
project this is only possible with some rules. And systematically
separating API from Impl classes in different JARs make these rules
very simple and intuitive.

--Manfred




On Nov 28, 2007 10:41 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 Hi,

 it is that case, that Bernd I and meet next weekend.
 If you guys don't mind, we start the commons project, as discussed here.

 Like maven-stuff etc.

 -Matthias


 On Nov 13, 2007 7:27 PM, Mario Ivankovits [EMAIL PROTECTED] wrote:
  Hi!
   BTW, I do not understand why some of you are so scared by multiple
   jsfcommons artifacts.
  I see it being much work to maintain ... but anyway, since you are the
  one who is going to do the initial maven work :-) I do no longer argue
  against.
  So, can we start now ;-) ?
 
  Ciao,
  Mario
 
 



 --
 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: [vote] release of Trinidad plugins (1.2.5)

2007-11-28 Thread Gary Kind
I will fix it right away and put out a new patch. 


Matthias Wessendorf wrote:

-1 on this release, because of the 843 issue.
let me check it tomorrow morning.


On Nov 28, 2007 10:55 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  

yes, just noticed that bug...
fix you have a fix, I can replace the JARs tomorrow :-)


On Nov 28, 2007 10:53 PM, Matt Cooper [EMAIL PROTECTED] wrote:


Perhaps this release should wait on a fix for:
https://issues.apache.org/jira/browse/TRINIDAD-843



On Nov 28, 2007 8:29 AM, Matt Cooper  [EMAIL PROTECTED] wrote:
  

+1





On Nov 27, 2007 1:47 PM, Gary Kind [EMAIL PROTECTED] wrote:



+1




Jeanne Waldman wrote:
  

+1

Gabrielle Crawford wrote:


+1

Bruno Aranda wrote:
  

+1

On 27/11/2007, Matthias Wessendorf  [EMAIL PROTECTED] wrote:



+1

On Nov 27, 2007 10:26 AM, Matthias Wessendorf  [EMAIL PROTECTED]
wrote:

  

Hi,

I was running the needed tasks to get the 1.2.5 release of the


Apache
  

MyFaces Trinidad Maven 2 Plugins out.

The artifacts are deployed to my private Apache account ([1]).

Please take a look at the  1.2.5 artifacts and vote.

How to test those JARs ?

1. there is now a zip file (org.zip) (see [1])
2. use the stage repo inside your pom.xml file:
...
pluginRepositories
 pluginRepository
 idapache.stage/id
 nameApache Stage Repository/name
 urlhttp://people.apache.org/~matzew/125-plugins/url
 layoutdefault/layout
 /pluginRepository
/pluginRepositories
...


[ ] +1 for community members who have reviewed and tested the bits
[ ] +0
[ ] -1 for fatal flaws that should cause these bits not to be
released,
  and why..


Thanks,
Matthias

[1] http://people.apache.org/~matzew/125-plugins

--
Matthias Wessendorf

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




--
Matthias Wessendorf

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


  

  


--

Matthias Wessendorf

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






  


[jira] Commented: (TRINIDAD-843) Jdev plugin - Nullpointer exception

2007-11-28 Thread Gary Kind (JIRA)

[ 
https://issues.apache.org/jira/browse/TRINIDAD-843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546481
 ] 

Gary Kind commented on TRINIDAD-843:


The local tag libraries, if any should be located in your maven project's 
${basedir}/src/main/webapp/WEB-INF, not WEB-INF/lib.  
${basedir}/src/main/webapp/WEB-INF is the maven standard generic location for 
its webapp projects.  That being said I do have a bug in the TRINIDAD-808 that 
needs to be fixed.

 Jdev plugin - Nullpointer exception
 ---

 Key: TRINIDAD-843
 URL: https://issues.apache.org/jira/browse/TRINIDAD-843
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Plugins
Affects Versions: 1.2.5-plugins,  1.2.4.1-plugins
 Environment: Windows
Reporter: Aino Andriessen

 When running the jdev plugin, a nullpointer occurs with the (new) code for 
 handling taglibs. The WEB-INF\lib directory of my projects are empty or are 
 not present at all.
 Stacktrace :
 [INFO] 
 
 [INFO] Building Default ADF Faces application : jdevplugin
 [INFO]task-segment: [jdev:jdev]
 [INFO] 
 
 [INFO] Preparing jdev:jdev
 [INFO] No goals needed for project - skipping
 [INFO] [jdev:jdev]
 [INFO] Generating JDeveloper 10.1.3.0.4 workspace: jdevplugin
 [INFO] 
 
 [INFO] Building The generated jdevplugin model project
 [INFO]task-segment: [jdev:jdev]
 [INFO] 
 
 [INFO] Preparing jdev:jdev
 [INFO] [resources:resources]
 [INFO] Using default encoding to copy filtered resources.
 [INFO] [jdev:jdev]
 [INFO] Generating JDeveloper 10.1.3.0.4 Project jdevplugin-model
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] null
 [INFO] 
 
 [INFO] Trace
 java.lang.NullPointerException
 at 
 org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.replaceLocalTagLibraries(JDeveloperMojo.java:904)
 at 
 org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.replaceTagLibraries(JDeveloperMojo.java:1113)
 at 
 org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.generateProject(JDeveloperMojo.java:398)
 at 
 org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.generateProject(JDeveloperMojo.java:315)
 at 
 org.apache.myfaces.trinidadbuild.plugin.jdeveloper.JDeveloperMojo.execute(JDeveloperMojo.java:227)
 at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:447)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
 at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
 at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:333)
 at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:126)
 at org.apache.maven.cli.MavenCli.main(MavenCli.java:282)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
 at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
 at 
 org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
 at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 [INFO] 
 
 [INFO] Total time: 3 seconds
 [INFO] Finished at: Wed Nov 28 22:02:12 CET 2007
 [INFO] Final Memory: 3M/7M
 [INFO] 
 
 D:\tmp\test_projects\jdevplugin

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to 

Re: [vote] release of Trinidad plugins (1.2.5)

2007-11-28 Thread Gary Kind




Matthias, I have a fix for the NPE, should I make a complete
trunk.patch again and put it on Trinidad-808?


Matthias Wessendorf wrote:

  -1 on this release, because of the 843 issue.
let me check it tomorrow morning.


On Nov 28, 2007 10:55 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  
  
yes, just noticed that bug...
fix you have a fix, I can replace the JARs tomorrow :-)


On Nov 28, 2007 10:53 PM, Matt Cooper [EMAIL PROTECTED] wrote:


  Perhaps this release should wait on a fix for:
https://issues.apache.org/jira/browse/TRINIDAD-843



On Nov 28, 2007 8:29 AM, Matt Cooper  [EMAIL PROTECTED] wrote:
  
  
+1





On Nov 27, 2007 1:47 PM, Gary Kind [EMAIL PROTECTED] wrote:



  +1




Jeanne Waldman wrote:
  
  
+1

Gabrielle Crawford wrote:


  +1

Bruno Aranda wrote:
  
  
+1

On 27/11/2007, Matthias Wessendorf  [EMAIL PROTECTED] wrote:



  +1

On Nov 27, 2007 10:26 AM, Matthias Wessendorf  [EMAIL PROTECTED]
wrote:

  
  
Hi,

I was running the needed tasks to get the 1.2.5 release of the

  

  

  

  
  Apache
  
  

  

  

  
MyFaces Trinidad Maven 2 Plugins out.

The artifacts are deployed to my private Apache account ([1]).

Please take a look at the " 1.2.5" artifacts and vote.

How to test those JARs ?

1. there is now a zip file (org.zip) (see [1])
2. use the stage repo inside your pom.xml file:
...
pluginRepositories
 pluginRepository
 idapache.stage/id
 nameApache Stage Repository/name
 urlhttp://people.apache.org/~matzew/125-plugins/url
 layoutdefault/layout
 /pluginRepository
/pluginRepositories
...


[ ] +1 for community members who have reviewed and tested the bits
[ ] +0
[ ] -1 for fatal flaws that should cause these bits not to be
released,
  and why..


Thanks,
Matthias

[1] http://people.apache.org/~matzew/125-plugins

--
Matthias Wessendorf

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



  
  --
Matthias Wessendorf

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


  

  

  



  
  
  



--

Matthias Wessendorf

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


  
  


  





Re: [vote] release of Trinidad plugins (1.2.5)

2007-11-28 Thread Gary Kind




I have uploaded a new patch to Trinidad-808 with the fix for
Trinidad-843.

Gary Kind wrote:

  
Matthias, I have a fix for the NPE, should I make a complete
trunk.patch again and put it on Trinidad-808?
  
  
Matthias Wessendorf wrote:
  
-1 on this release, because of the 843 issue.
let me check it tomorrow morning.


On Nov 28, 2007 10:55 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  

  yes, just noticed that bug...
fix you have a fix, I can replace the JARs tomorrow :-)


On Nov 28, 2007 10:53 PM, Matt Cooper [EMAIL PROTECTED] wrote:

  
Perhaps this release should wait on a fix for:
https://issues.apache.org/jira/browse/TRINIDAD-843



On Nov 28, 2007 8:29 AM, Matt Cooper  [EMAIL PROTECTED] wrote:
  

  +1





On Nov 27, 2007 1:47 PM, Gary Kind [EMAIL PROTECTED] wrote:


  
+1




Jeanne Waldman wrote:
  

  +1

Gabrielle Crawford wrote:

  
+1

Bruno Aranda wrote:
  

  +1

On 27/11/2007, Matthias Wessendorf  [EMAIL PROTECTED] wrote:


  
+1

On Nov 27, 2007 10:26 AM, Matthias Wessendorf  [EMAIL PROTECTED]
wrote:

  

  Hi,

I was running the needed tasks to get the 1.2.5 release of the


  

  

  

Apache
  

  

  

  

  MyFaces Trinidad Maven 2 Plugins out.

The artifacts are deployed to my private Apache account ([1]).

Please take a look at the " 1.2.5" artifacts and vote.

How to test those JARs ?

1. there is now a zip file (org.zip) (see [1])
2. use the stage repo inside your pom.xml file:
...
pluginRepositories
 pluginRepository
 idapache.stage/id
 nameApache Stage Repository/name
 urlhttp://people.apache.org/~matzew/125-plugins/url
 layoutdefault/layout
 /pluginRepository
/pluginRepositories
...


[ ] +1 for community members who have reviewed and tested the bits
[ ] +0
[ ] -1 for fatal flaws that should cause these bits not to be
released,
  and why..


Thanks,
Matthias

[1] http://people.apache.org/~matzew/125-plugins

--
Matthias Wessendorf

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




--
Matthias Wessendorf

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


  
  

  

  
  

  
  
  
--

Matthias Wessendorf

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






  
  





Re: [vote] release of Trinidad plugins (1.2.5)

2007-11-28 Thread Scott O'Bryan
Actually Gary, I think 808 is already committed, so the smaller patch 
which just fixes 843 might be easier to apply.  If this can't be done, 
the patch may have to do.  But if it can I think it would be preferable.


Scott

Gary Kind wrote:

I have uploaded a new patch to Trinidad-808 with the fix for Trinidad-843.

Gary Kind wrote:
Matthias, I have a fix for the NPE, should I make a complete 
trunk.patch again and put it on Trinidad-808?



Matthias Wessendorf wrote:

-1 on this release, because of the 843 issue.
let me check it tomorrow morning.


On Nov 28, 2007 10:55 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  

yes, just noticed that bug...
fix you have a fix, I can replace the JARs tomorrow :-)


On Nov 28, 2007 10:53 PM, Matt Cooper [EMAIL PROTECTED] wrote:


Perhaps this release should wait on a fix for:
https://issues.apache.org/jira/browse/TRINIDAD-843



On Nov 28, 2007 8:29 AM, Matt Cooper  [EMAIL PROTECTED] wrote:
  

+1





On Nov 27, 2007 1:47 PM, Gary Kind [EMAIL PROTECTED] wrote:



+1




Jeanne Waldman wrote:
  

+1

Gabrielle Crawford wrote:


+1

Bruno Aranda wrote:
  

+1

On 27/11/2007, Matthias Wessendorf  [EMAIL PROTECTED] wrote:



+1

On Nov 27, 2007 10:26 AM, Matthias Wessendorf  [EMAIL PROTECTED]
wrote:

  

Hi,

I was running the needed tasks to get the 1.2.5 release of the


Apache
  

MyFaces Trinidad Maven 2 Plugins out.

The artifacts are deployed to my private Apache account ([1]).

Please take a look at the  1.2.5 artifacts and vote.

How to test those JARs ?

1. there is now a zip file (org.zip) (see [1])
2. use the stage repo inside your pom.xml file:
...
pluginRepositories
 pluginRepository
 idapache.stage/id
 nameApache Stage Repository/name
 urlhttp://people.apache.org/~matzew/125-plugins/url
 layoutdefault/layout
 /pluginRepository
/pluginRepositories
...


[ ] +1 for community members who have reviewed and tested the bits
[ ] +0
[ ] -1 for fatal flaws that should cause these bits not to be
released,
  and why..


Thanks,
Matthias

[1] http://people.apache.org/~matzew/125-plugins

--
Matthias Wessendorf

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




--
Matthias Wessendorf

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


  

  

--

Matthias Wessendorf

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






  




Re: [vote] release of Trinidad plugins (1.2.5)

2007-11-28 Thread Gary Kind

Okay, I am still unfamiliar with procedures.  Will do.

Scott O'Bryan wrote:
Actually Gary, I think 808 is already committed, so the smaller patch 
which just fixes 843 might be easier to apply.  If this can't be done, 
the patch may have to do.  But if it can I think it would be preferable.


Scott

Gary Kind wrote:
I have uploaded a new patch to Trinidad-808 with the fix for 
Trinidad-843.


Gary Kind wrote:
Matthias, I have a fix for the NPE, should I make a complete 
trunk.patch again and put it on Trinidad-808?



Matthias Wessendorf wrote:

-1 on this release, because of the 843 issue.
let me check it tomorrow morning.


On Nov 28, 2007 10:55 PM, Matthias Wessendorf [EMAIL PROTECTED] 
wrote:
 

yes, just noticed that bug...
fix you have a fix, I can replace the JARs tomorrow :-)


On Nov 28, 2007 10:53 PM, Matt Cooper [EMAIL PROTECTED] wrote:
   

Perhaps this release should wait on a fix for:
https://issues.apache.org/jira/browse/TRINIDAD-843



On Nov 28, 2007 8:29 AM, Matt Cooper  [EMAIL PROTECTED] wrote:
 

+1





On Nov 27, 2007 1:47 PM, Gary Kind [EMAIL PROTECTED] wrote:

   

+1




Jeanne Waldman wrote:
 

+1

Gabrielle Crawford wrote:
   

+1

Bruno Aranda wrote:
 

+1

On 27/11/2007, Matthias Wessendorf  [EMAIL PROTECTED] wrote:

   

+1

On Nov 27, 2007 10:26 AM, Matthias Wessendorf  
[EMAIL PROTECTED]

wrote:

 

Hi,

I was running the needed tasks to get the 1.2.5 release of 
the


Apache
 

MyFaces Trinidad Maven 2 Plugins out.

The artifacts are deployed to my private Apache account 
([1]).


Please take a look at the  1.2.5 artifacts and vote.

How to test those JARs ?

1. there is now a zip file (org.zip) (see [1])
2. use the stage repo inside your pom.xml file:
...
pluginRepositories
 pluginRepository
 idapache.stage/id
 nameApache Stage Repository/name
 urlhttp://people.apache.org/~matzew/125-plugins/url
 layoutdefault/layout
 /pluginRepository
/pluginRepositories
...


[ ] +1 for community members who have reviewed and tested 
the bits

[ ] +0
[ ] -1 for fatal flaws that should cause these bits not to be
released,
  and why..


Thanks,
Matthias

[1] http://people.apache.org/~matzew/125-plugins

--
Matthias Wessendorf

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




--
Matthias Wessendorf

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


  

  

--

Matthias Wessendorf

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






  




[jira] Created: (PORTLETBRIDGE-16) Path problems in PortletExternalContextImpl.

2007-11-28 Thread Michael Freedman (JIRA)
Path problems in PortletExternalContextImpl.


 Key: PORTLETBRIDGE-16
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-16
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0-SNAPSHOT
Reporter: Michael Freedman
 Fix For: 1.0.0-SNAPSHOT


encodeResourceURL currently only creates a context-path relative path when 
asked to encode a relative path before passing to the portlet container for 
encoding -- however the portlet API requires this be a fully qualified path 
(i.e. include the ContextPath).

isAbsoluteURL doesn't properly test if the url is absolute or not -- What it 
needs to do is only return true if the url starts with a valid scheme.  I.e. 
the characters before the : don't contain any of the URI reserved characters.  
for example javascript:; currently claims it isn't absolute when it should 
be marked as it is.

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



[jira] Updated: (PORTLETBRIDGE-17) Bridge faces-config.xml doesn't configure the bridge's StateManager

2007-11-28 Thread Michael Freedman (JIRA)

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

Michael Freedman updated PORTLETBRIDGE-17:
--

Status: Patch Available  (was: Open)

 Bridge faces-config.xml doesn't configure the bridge's StateManager
 ---

 Key: PORTLETBRIDGE-17
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-17
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0-SNAPSHOT
Reporter: Michael Freedman
 Fix For: 1.0.0-SNAPSHOT

 Attachments: statemgrcgf.patch


 We recently supplied a patch that included a fix that had the bridge update 
 the VIEW_STATE id it cached across action/renders to account for navigations 
 after the action.  This involved having the bridge provide a StateManager 
 impl so it could parse out the value for this id being written into the 
 rendition.  Unfortunately the patch neglected to carry the corresponding 
 change to the bridges faces-config.xml and hence the feature was never 
 enabled.  
 To test for this -- perform an action whose result is to navigate to a 
 different view (for rendering).  After the first rendition suceeds -- do a 
 browser refresh.  Without the configuration the resulting rendering will be 
 of the action view page not the rendition view page.

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



[jira] Created: (PORTLETBRIDGE-17) Bridge faces-config.xml doesn't configure the bridge's StateManager

2007-11-28 Thread Michael Freedman (JIRA)
Bridge faces-config.xml doesn't configure the bridge's StateManager
---

 Key: PORTLETBRIDGE-17
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-17
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0-SNAPSHOT
Reporter: Michael Freedman
 Fix For: 1.0.0-SNAPSHOT
 Attachments: statemgrcgf.patch

We recently supplied a patch that included a fix that had the bridge update the 
VIEW_STATE id it cached across action/renders to account for navigations after 
the action.  This involved having the bridge provide a StateManager impl so it 
could parse out the value for this id being written into the rendition.  
Unfortunately the patch neglected to carry the corresponding change to the 
bridges faces-config.xml and hence the feature was never enabled.  

To test for this -- perform an action whose result is to navigate to a 
different view (for rendering).  After the first rendition suceeds -- do a 
browser refresh.  Without the configuration the resulting rendering will be of 
the action view page not the rendition view page.

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



[orchestra] Conversation issues with master-detail

2007-11-28 Thread rkull

I am trying to create a master-detail screen scenario and am following the
best-practices guide in the wiki (the simple CRUD cycle -
http://wiki.apache.org/myfaces/A_simple_Crud_Cycle) and it does not actually
work.  Am I doing something wrong?  Here is what I have:

MasterView has a BO which it uses to fetch a list of all target objects
(just like in the example).

DetailView is in its own detail related flash conversation (as mentioned in
the bottom of the example), and has a reference to the BO as well. 
(manual/flash makes no difference whatsoever)

When I do a save on the DetailView, if I call refreshList on the MasterView
after saving using the DetailView instance of the BO, the list does NOT
contain my changes.  I understand why this is happening.  The BO in the
MasterView has its own entity manager as it is in a different conversation
than the DetailView.  It does not help to do
Conversation.getCurrentInstance().invalidate() in the DetailView before
doing a list refresh on the master view as there is still nothing to force
the entity manager in the MasterView to dump its cached objects.

The example is quite unclear on many details and was wondering if I am doing
something wrong here.  I have found several ways to make it work as
expected, but they are NOT like the example, and are a bit more difficult to
figure out as to what is going on without documentation.

My test is extremely simple and is NOT working as advertised!

Can anyone help?

-- 
View this message in context: 
http://www.nabble.com/-orchestra--Conversation-issues-with-master-detail-tf4894353.html#a14017094
Sent from the My Faces - Dev mailing list archive at Nabble.com.



[jira] Resolved: (PORTLETBRIDGE-17) Bridge faces-config.xml doesn't configure the bridge's StateManager

2007-11-28 Thread Scott O'Bryan (JIRA)

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

Scott O'Bryan resolved PORTLETBRIDGE-17.


Resolution: Fixed

Committed to trunk.  Thanks Mike for catching and reporting this issue.

 Bridge faces-config.xml doesn't configure the bridge's StateManager
 ---

 Key: PORTLETBRIDGE-17
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-17
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0-SNAPSHOT
Reporter: Michael Freedman
Assignee: Scott O'Bryan
 Fix For: 1.0.0-SNAPSHOT

 Attachments: statemgrcgf.patch


 We recently supplied a patch that included a fix that had the bridge update 
 the VIEW_STATE id it cached across action/renders to account for navigations 
 after the action.  This involved having the bridge provide a StateManager 
 impl so it could parse out the value for this id being written into the 
 rendition.  Unfortunately the patch neglected to carry the corresponding 
 change to the bridges faces-config.xml and hence the feature was never 
 enabled.  
 To test for this -- perform an action whose result is to navigate to a 
 different view (for rendering).  After the first rendition suceeds -- do a 
 browser refresh.  Without the configuration the resulting rendering will be 
 of the action view page not the rendition view page.

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



[jira] Resolved: (PORTLETBRIDGE-16) Path problems in PortletExternalContextImpl.

2007-11-28 Thread Scott O'Bryan (JIRA)

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

Scott O'Bryan resolved PORTLETBRIDGE-16.


Resolution: Fixed

This has been checked in to the trunk.  Thanks for the patch Mike.

 Path problems in PortletExternalContextImpl.
 

 Key: PORTLETBRIDGE-16
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-16
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0-SNAPSHOT
Reporter: Michael Freedman
Assignee: Scott O'Bryan
 Fix For: 1.0.0-SNAPSHOT

 Attachments: extctxpath.patch


 encodeResourceURL currently only creates a context-path relative path when 
 asked to encode a relative path before passing to the portlet container for 
 encoding -- however the portlet API requires this be a fully qualified path 
 (i.e. include the ContextPath).
 isAbsoluteURL doesn't properly test if the url is absolute or not -- What it 
 needs to do is only return true if the url starts with a valid scheme.  I.e. 
 the characters before the : don't contain any of the URI reserved characters. 
  for example javascript:; currently claims it isn't absolute when it 
 should be marked as it is.

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



[jira] Commented: (PORTLETBRIDGE-17) Bridge faces-config.xml doesn't configure the bridge's StateManager

2007-11-28 Thread Scott O'Bryan (JIRA)

[ 
https://issues.apache.org/jira/browse/PORTLETBRIDGE-17?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546514
 ] 

Scott O'Bryan commented on PORTLETBRIDGE-17:


No to mention fixing..  :)

 Bridge faces-config.xml doesn't configure the bridge's StateManager
 ---

 Key: PORTLETBRIDGE-17
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-17
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0-SNAPSHOT
Reporter: Michael Freedman
Assignee: Scott O'Bryan
 Fix For: 1.0.0-SNAPSHOT

 Attachments: statemgrcgf.patch


 We recently supplied a patch that included a fix that had the bridge update 
 the VIEW_STATE id it cached across action/renders to account for navigations 
 after the action.  This involved having the bridge provide a StateManager 
 impl so it could parse out the value for this id being written into the 
 rendition.  Unfortunately the patch neglected to carry the corresponding 
 change to the bridges faces-config.xml and hence the feature was never 
 enabled.  
 To test for this -- perform an action whose result is to navigate to a 
 different view (for rendering).  After the first rendition suceeds -- do a 
 browser refresh.  Without the configuration the resulting rendering will be 
 of the action view page not the rendition view page.

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



[jira] Created: (TRINIDAD-845) choice between IFrame-PPR or XHR should be possible

2007-11-28 Thread JIRA
choice between IFrame-PPR or  XHR should be possible


 Key: TRINIDAD-845
 URL: https://issues.apache.org/jira/browse/TRINIDAD-845
 Project: MyFaces Trinidad
  Issue Type: New Feature
Affects Versions: 1.2.2-core
Reporter: Jan Görß


It should be possible to change the interactive server communication between 
IFrame-PPR and XHR.
Our customers are banking houses and they define the security constrains  
(IE5.5+ with deactived ActiveX).

IE 5.5  - 6 are the problem.
IE 7 has a possibility to run XHR without ActiveX.

At the beginning of our projects we decide to take Trinidad because of it's 
IFrame-PPR solution and our WebApps must run without AJAX.

I think other users of trinidad have the same problem also.


Taken from [EMAIL PROTECTED]

Hi,

I know all the issues with not able to use IE w/ activated ActiveX.
Sure, a solution is possible, but it is (as always) a matter of time.

Are you willing to help out on this?

I'll also check our internal requirements, since we have also customers, that 
may upgrade
to Trinidad, coming from ADF Faces 10.x.

Can you file an issue in our jira w/ some details, that we don't forget it?

Thx,
Matthias

On Nov 28, 2007 1:38 PM, Goerss, Jan [EMAIL PROTECTED] wrote:

 The problem is that our customers are banking houses.
 They define the security constrains (IE5.5+ with deactivated ActiveX).

 We use Trinidad 1.2.1 and we can't switch to latest version of Trinidad with 
 AJAX.

 I hope, a fallback option is possible, otherwise we can't use the latest 
 version of Trinidad and our project can work with Trinidad version 1.2.1 only.
 The problems are with this constrain:
   - we get no bugfixing more
   - we can't use new components and features (new releases)
   - we can't use new trinidad development


 I hope a solution is possible.

 Thanks,

 Jan


 -Ursprüngliche Nachricht-
 Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag 
 von Matthias Wessendorf
 Gesendet: Mittwoch, 28. November 2007 11:04
 An: MyFaces Discussion
 Betreff: Re: Trinidad Ajax


 Hi Jan,

 yes, we switched to XHR with the release of 1.0.2 (and 1.2.2).
 There is no way to use IFrame instead of XHR.

 This will remain, because Ajax is pretty common these days and other 
 JSF-libs have that as well.

 Providing an option to fallback might be possible, but not sure if 
 that will be done.

 Is IE 5.5 really still supported by M$?
 If not, I'd strongly recommend to kick that guy out.
 Sure... only the IE7 doesn't require ActiveX for XHR, but IE does.

 I am not aware of a solution for that.

 Do you have any ideas ?

 -Matthias

 On Nov 28, 2007 10:48 AM, Goerss, Jan [EMAIL PROTECTED] wrote:
 
 
 
 
  Hello all,
 
 
 
  we noticed that MyFaces Trinidad is changing the PPR mechanism 
  towards real AJAX and the XmlHttpRequest object.
 
 
 
  We are using Trinidad is the finance sector. There it is normal that 
  the clients use the Internet Explorer with deactivated ActiveX.
 
  Furthermore they use not the newest browsers, so we although need to 
  support at least IE 5.5+.
 
 
 
  At the beginning of our project we decide to take Trinidad because 
  of it's IFrame-PPR solution.
 
 
 
  It seems as if it is not possible to choose between the two modes: 
  PPR or AJAX.
 
 
 
  Will this remain? If so why? Otherwise, we think that a lot of 
  Trinidad library users will encounter problems with their clientsJ
 
 
 
  Thanks in advance,
 
  Jan
 
 
 
 
 
 



 --
 Matthias Wessendorf

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




--
Matthias Wessendorf

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


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



Re: [vote] release of Trinidad plugins (1.2.5)

2007-11-28 Thread Matthias Wessendorf
coool, will check that all.

On Nov 29, 2007 1:11 AM, Gary Kind [EMAIL PROTECTED] wrote:
 Done.


 Scott O'Bryan wrote:
  Actually Gary, I think 808 is already committed, so the smaller patch
  which just fixes 843 might be easier to apply.  If this can't be done,
  the patch may have to do.  But if it can I think it would be preferable.
 
  Scott
 
  Gary Kind wrote:
  I have uploaded a new patch to Trinidad-808 with the fix for
  Trinidad-843.
 
  Gary Kind wrote:
  Matthias, I have a fix for the NPE, should I make a complete
  trunk.patch again and put it on Trinidad-808?
 
 
  Matthias Wessendorf wrote:
  -1 on this release, because of the 843 issue.
  let me check it tomorrow morning.
 
 
  On Nov 28, 2007 10:55 PM, Matthias Wessendorf [EMAIL PROTECTED]
  wrote:
 
  yes, just noticed that bug...
  fix you have a fix, I can replace the JARs tomorrow :-)
 
 
  On Nov 28, 2007 10:53 PM, Matt Cooper [EMAIL PROTECTED] wrote:
 
  Perhaps this release should wait on a fix for:
  https://issues.apache.org/jira/browse/TRINIDAD-843
 
 
 
  On Nov 28, 2007 8:29 AM, Matt Cooper  [EMAIL PROTECTED] wrote:
 
  +1
 
 
 
 
 
  On Nov 27, 2007 1:47 PM, Gary Kind [EMAIL PROTECTED] wrote:
 
 
  +1
 
 
 
 
  Jeanne Waldman wrote:
 
  +1
 
  Gabrielle Crawford wrote:
 
  +1
 
  Bruno Aranda wrote:
 
  +1
 
  On 27/11/2007, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
 
 
  +1
 
  On Nov 27, 2007 10:26 AM, Matthias Wessendorf 
  [EMAIL PROTECTED]
  wrote:
 
 
  Hi,
 
  I was running the needed tasks to get the 1.2.5 release of
  the
 
  Apache
 
  MyFaces Trinidad Maven 2 Plugins out.
 
  The artifacts are deployed to my private Apache account
  ([1]).
 
  Please take a look at the  1.2.5 artifacts and vote.
 
  How to test those JARs ?
 
  1. there is now a zip file (org.zip) (see [1])
  2. use the stage repo inside your pom.xml file:
  ...
  pluginRepositories
   pluginRepository
   idapache.stage/id
   nameApache Stage Repository/name
   urlhttp://people.apache.org/~matzew/125-plugins/url
   layoutdefault/layout
   /pluginRepository
  /pluginRepositories
  ...
 
  
  [ ] +1 for community members who have reviewed and tested
  the bits
  [ ] +0
  [ ] -1 for fatal flaws that should cause these bits not to be
  released,
and why..
  
 
  Thanks,
  Matthias
 
  [1] http://people.apache.org/~matzew/125-plugins
 
  --
  Matthias Wessendorf
 
  further stuff:
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  mail: matzew-at-apache-dot-org
 
 
 
  --
  Matthias Wessendorf
 
  further stuff:
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  mail: matzew-at-apache-dot-org
 
 
 
 
 
  --
 
  Matthias Wessendorf
 
  further stuff:
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  mail: matzew-at-apache-dot-org
 
 
 
 
 
 
 




-- 
Matthias Wessendorf

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