date:20080225

Wildcard patterns in javax.faces.CONFIG_FILES parameter

2008-02-25 Thread Danny Robinson

Guys,

I don't think it's possible to dynamically specify wildcard config loading
patterns for JSF currently.  However, most all other frameworks today seem
to be able to handle something similar for loading files by naming/location
conventions.  I know JSF will pick-up META-INF/faces-confg.xml inside the
jars, but my concern is mainly with navigation rules and creating modular UI
bundles.

Would there be appetite to have this as feature in the MyFaces
implementation, disabled by default (for compliant with spec.), but enabled
via a config setting?

Thanks,

Danny

-- 
Chordiant Software Inc.
www.chordiant.com

[continuum] upgrading

2008-02-25 Thread Manfred Geiler

FYI

MyFaces Continuum is currently down for maintainance.

Trying to upgrade to 1.1 final

--Manfred

[continuum] upgrading

2008-02-25 Thread Manfred Geiler

???
Is somebody logged in as mrmaven and killing my processes?


--Manfred


-- Forwarded message --
From: Manfred Geiler [EMAIL PROTECTED]
Date: Mon, Feb 25, 2008 at 1:54 PM
Subject: [continuum] upgrading
To: MyFaces Development dev@myfaces.apache.org


FYI

 MyFaces Continuum is currently down for maintainance.

 Trying to upgrade to 1.1 final

 --Manfred



-- 
http://www.irian.at
Your JSF powerhouse - JSF Consulting,
Development and Courses in English and
German

Professional Support for Apache MyFaces

[Trinidad] EOL settings not on files

2008-02-25 Thread Andrew Robinson

I have noticed that the text files for Trinidad do not have the eol
SVN property set. Many files have been committed using windows EOL.
Would anyone object to setting svn:eol-style to native on the trinidad
non-binary files so that the correct line endings are used on the
developers machines?

-Andrew

Re: [Trinidad] EOL settings not on files

2008-02-25 Thread Andrew Robinson

Done (trunk_1.2.x = svn rev 630918, trunk = svn rev 630928)

For all those who are not aware,

1) You should set the eol-style to native for every new text file that
you add to SVN. This can be automated in you SVN settings. See [1] and
[2] on how to do this.
2) when merging between branches that have different settings for eol,
use this flag to prevent conflicts:
svn merge -x --ignore-eol-style ...

-Andrew

[1] http://svnbook.red-bean.com/en/1.1/ch07s02.html#svn-ch-7-sect-2.3.5
[2] http://www.zope.org/DevHome/Subversion/SubversionConfigurationForLineEndings


On Mon, Feb 25, 2008 at 9:13 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 yeah, possible,
  we fixed that already in the past.

  go ahead and apply the property

  -M



  On Mon, Feb 25, 2008 at 5:11 PM, Andrew Robinson
  [EMAIL PROTECTED] wrote:
   I have noticed that the text files for Trinidad do not have the eol
SVN property set. Many files have been committed using windows EOL.
Would anyone object to setting svn:eol-style to native on the trinidad
non-binary files so that the correct line endings are used on the
developers machines?
  
-Andrew
  



  --
  Matthias Wessendorf

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

[jira] Created: (MYFACES-1823) pom.xml uses deprecated syntax

2008-02-25 Thread Andrew Robinson (JIRA)

pom.xml uses deprecated syntax
--

 Key: MYFACES-1823
 URL: https://issues.apache.org/jira/browse/MYFACES-1823
 Project: MyFaces Core
  Issue Type: Task
  Components: build process
Affects Versions: 1.2.2
Reporter: Andrew Robinson
Priority: Trivial


${version} is a deprecated maven property. It should be changed to 
${pom.version} or ${project.version}.

Matches (grep style output):
./shared/shared-tomahawk/pom.xml:41:  
version${version}/version
./shared/shared-orchestra/pom.xml:41:  
version${version}/version
./shared/shared-impl/pom.xml:41:  version${version}/version
./core/assembly/pom.xml:43:  version${version}/version
./core/assembly/pom.xml:50:  version${version}/version
./core/assembly/pom.xml:69:  version${version}/version
./core/assembly/pom.xml:88:  version${version}/version
./core/assembly/pom.xml:94:  version${version}/version
./core/assembly/pom.xml:118:  
finalNamemyfaces-core-${version}/finalName
./core/assembly/pom.xml:144:  version${version}/version
./core/assembly/pom.xml:150:  version${version}/version
./tomahawk/sandbox/assembly/pom.xml:42:
version${version}/version
./tomahawk/sandbox/assembly/pom.xml:62:
version${version}/version
./tomahawk/sandbox/assembly/pom.xml:81:
version${version}/version
./tomahawk/sandbox/assembly/pom.xml:98:
version${version}/version
./tomahawk/sandbox/assembly/pom.xml:117:
finalNametomahawk-sandbox-${version}/finalName
./tomahawk/sandbox/assembly/pom.xml:155:
version${version}/version
./tomahawk/sandbox/core/pom.xml:30:version${version}/version
./tomahawk/sandbox/examples/assembly/pom.xml:40:
version${version}/version
./tomahawk/sandbox/examples/assembly/pom.xml:57:
finalNametomahawk-sandbox-examples-${version}/finalName
./tomahawk/sandbox/examples/pom.xml:45: 
   version${version}/version
./tomahawk/sandbox/examples/pom.xml:281:
version${version}/version
./tomahawk/assembly/pom.xml:43:  version${version}/version
./tomahawk/assembly/pom.xml:61:  version${version}/version
./tomahawk/assembly/pom.xml:79:  version${version}/version
./tomahawk/assembly/pom.xml:98:  version${version}/version
./tomahawk/assembly/pom.xml:124:  
finalNametomahawk-${version}/finalName
./tomahawk/assembly/pom.xml:149:  version${version}/version
./tomahawk/examples/blank/pom.xml:43:   
 version${version}/version
./tomahawk/examples/simple/pom.xml:43:  
  version${version}/version
./tomahawk/examples/assembly/pom.xml:39:
version${version}/version
./tomahawk/examples/assembly/pom.xml:45:
version${version}/version
./tomahawk/examples/assembly/pom.xml:51:
version${version}/version
./tomahawk/examples/assembly/pom.xml:57:
version${version}/version
./tomahawk/examples/assembly/pom.xml:74:
finalNametomahawk-examples-${version}/finalName
./tomahawk/examples/tiles/pom.xml:43:   
 version${version}/version
./tomahawk/examples/wap/pom.xml:43:
version${version}/version
./tomahawk/examples/pom.xml:61:version${version}/version
./tomahawk/sandbox15/core/pom.xml:30:version${version}/version
./tomahawk/sandbox15/core/pom.xml:37:version${version}/version
./tomahawk/sandbox15/examples/pom.xml:45:   
 version${version}/version
./tomahawk/sandbox15/examples/pom.xml:190:
version${version}/version
./tomahawk/sandbox15/examples/pom.xml:195:
version${version}/version


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

[continuum] AAARGH! (was: svn commit: r628196 - /myfaces/myfaces-master-pom/trunk/pom.xml)

2008-02-25 Thread Manfred Geiler

Scott, your faulty master pom commit (timezome instead of
timezone) cost me half a day.

How come?
- Continuum did no longer build the master pom correctly
   -- your fault
- The continuum messages (see [1]) where totally misleading
   -- NOT your fault of course  ;-)
- Since I could not determine the cause (clearing working dir or
restarting continuum did not work) I decided to upgrade to continuum
1.1 final - due anyway
   -- MY fault!
- I was able to install the new version but migrating the data from
1.1-beta2 to 1.1 was a total flop - although I tried hard, believe me!
  (see http://wiki.apache.org/myfaces/Continuum_Build for details)
- So I stepped back to continuum 1.1-beta2
- I removed the build definition for the myfaces master
- I was not able to create a new build definition
- Now the continuum exceptions luckily lead me to the actual cause

@Scott
Please note:
I'm NOT posting this publicly to dev@ to blame you.
Yes, I'm angry. But not because of your mistake (could happen) but
because of Continuum.
And I want to prevent others form stepping into the same traps.  ;-)

@All
What should we do regarding Continuum builds?
Anyone volunteering to migrate all build definitions and users manually?

--Manfred


[1]

Build Error:

org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error
executing action 'update-project-from-working-directory'
   at 
org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:432)
   at 
org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:137)
   at 
org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50)
   at 
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
   at 
edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
   at 
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
   at 
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
   at 
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
   at java.lang.Thread.run(Thread.java:595)
Caused by: org.apache.maven.continuum.execution.ContinuumBuildExecutorException:
Error while mapping metadata:add.project.project.building.error
add.project.unknown.error

   at 
org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:159)
   at 
org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:75)
   at 
org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:406)
   ... 8 more



[2]
-- Forwarded message --
From:  [EMAIL PROTECTED]
Date: Fri, Feb 15, 2008 at 11:58 PM
Subject: svn commit: r628196 - /myfaces/myfaces-master-pom/trunk/pom.xml
To: [EMAIL PROTECTED]


Author: sobryan
 Date: Fri Feb 15 14:58:57 2008
 New Revision: 628196

 URL: http://svn.apache.org/viewvc?rev=628196view=rev
 Log:
 Added myself as a developer to MyFaces...

 Modified:
myfaces/myfaces-master-pom/trunk/pom.xml

 Modified: myfaces/myfaces-master-pom/trunk/pom.xml
 URL: 
http://svn.apache.org/viewvc/myfaces/myfaces-master-pom/trunk/pom.xml?rev=628196r1=628195r2=628196view=diff
 ==
 --- myfaces/myfaces-master-pom/trunk/pom.xml (original)
 +++ myfaces/myfaces-master-pom/trunk/pom.xml Fri Feb 15 14:58:57 2008
 @@ -205,6 +205,19 @@
 timezone+1/timezone
 /developer
 developer
 +idsobryan/id
 +nameScott O'Bryan/name
 +email[EMAIL PROTECTED]/email
 +organizationOracle, U.S.A/organization
 +organizationUrlhttp://www.oracle.com/organizationUrl
 +roles
 +rolePortlet Bridge Project Lead/role
 +roleJSR-301 JSF Portlet Bridge EG Member/role
 +rolePortlet Guru/role
 +/roles
 +timezome-7/timezone
 +/developer
 +developer
 idschof/id
 nameSean Schofield/name
 email[EMAIL PROTECTED]/email

[jira] Deleted: (MYFACES-1824) pom.xml uses deprecated syntax

2008-02-25 Thread Andrew Robinson (JIRA)


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

Andrew Robinson deleted MYFACES-1824:
-


 pom.xml uses deprecated syntax
 --

 Key: MYFACES-1824
 URL: https://issues.apache.org/jira/browse/MYFACES-1824
 Project: MyFaces Core
  Issue Type: Task
Reporter: Andrew Robinson
Priority: Trivial

 ${version} is a deprecated maven property. It should be changed to 
 ${pom.version} or ${project.version}.
 Matches (grep style output):
 ./shared/shared-tomahawk/pom.xml:41:  
 version${version}/version
 ./shared/shared-orchestra/pom.xml:41:  
 version${version}/version
 ./shared/shared-impl/pom.xml:41:  
 version${version}/version
 ./core/assembly/pom.xml:43:  version${version}/version
 ./core/assembly/pom.xml:50:  version${version}/version
 ./core/assembly/pom.xml:69:  version${version}/version
 ./core/assembly/pom.xml:88:  version${version}/version
 ./core/assembly/pom.xml:94:  version${version}/version
 ./core/assembly/pom.xml:118:  
 finalNamemyfaces-core-${version}/finalName
 ./core/assembly/pom.xml:144:  version${version}/version
 ./core/assembly/pom.xml:150:  version${version}/version
 ./tomahawk/sandbox/assembly/pom.xml:42:
 version${version}/version
 ./tomahawk/sandbox/assembly/pom.xml:62:
 version${version}/version
 ./tomahawk/sandbox/assembly/pom.xml:81:
 version${version}/version
 ./tomahawk/sandbox/assembly/pom.xml:98:
 version${version}/version
 ./tomahawk/sandbox/assembly/pom.xml:117:
 finalNametomahawk-sandbox-${version}/finalName
 ./tomahawk/sandbox/assembly/pom.xml:155:
 version${version}/version
 ./tomahawk/sandbox/core/pom.xml:30:version${version}/version
 ./tomahawk/sandbox/examples/assembly/pom.xml:40:  
   version${version}/version
 ./tomahawk/sandbox/examples/assembly/pom.xml:57:
 finalNametomahawk-sandbox-examples-${version}/finalName
 ./tomahawk/sandbox/examples/pom.xml:45:   
  version${version}/version
 ./tomahawk/sandbox/examples/pom.xml:281:
 version${version}/version
 ./tomahawk/assembly/pom.xml:43:  version${version}/version
 ./tomahawk/assembly/pom.xml:61:  version${version}/version
 ./tomahawk/assembly/pom.xml:79:  version${version}/version
 ./tomahawk/assembly/pom.xml:98:  version${version}/version
 ./tomahawk/assembly/pom.xml:124:  
 finalNametomahawk-${version}/finalName
 ./tomahawk/assembly/pom.xml:149:  version${version}/version
 ./tomahawk/examples/blank/pom.xml:43: 
version${version}/version
 ./tomahawk/examples/simple/pom.xml:43:
 version${version}/version
 ./tomahawk/examples/assembly/pom.xml:39:
 version${version}/version
 ./tomahawk/examples/assembly/pom.xml:45:
 version${version}/version
 ./tomahawk/examples/assembly/pom.xml:51:
 version${version}/version
 ./tomahawk/examples/assembly/pom.xml:57:
 version${version}/version
 ./tomahawk/examples/assembly/pom.xml:74:
 finalNametomahawk-examples-${version}/finalName
 ./tomahawk/examples/tiles/pom.xml:43: 
version${version}/version
 ./tomahawk/examples/wap/pom.xml:43:   
  version${version}/version
 ./tomahawk/examples/pom.xml:61:
 version${version}/version
 ./tomahawk/sandbox15/core/pom.xml:30:version${version}/version
 ./tomahawk/sandbox15/core/pom.xml:37:version${version}/version
 ./tomahawk/sandbox15/examples/pom.xml:45: 
version${version}/version
 ./tomahawk/sandbox15/examples/pom.xml:190:
 version${version}/version
 ./tomahawk/sandbox15/examples/pom.xml:195:
 version${version}/version

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

[jira] Created: (MYFACES-1824) pom.xml uses deprecated syntax

2008-02-25 Thread Andrew Robinson (JIRA)

pom.xml uses deprecated syntax
--

 Key: MYFACES-1824
 URL: https://issues.apache.org/jira/browse/MYFACES-1824
 Project: MyFaces Core
  Issue Type: Task
  Components: build process
Affects Versions: 1.2.2
Reporter: Andrew Robinson
Priority: Trivial


${version} is a deprecated maven property. It should be changed to 
${pom.version} or ${project.version}.

Matches (grep style output):
./shared/shared-tomahawk/pom.xml:41:  
version${version}/version
./shared/shared-orchestra/pom.xml:41:  
version${version}/version
./shared/shared-impl/pom.xml:41:  version${version}/version
./core/assembly/pom.xml:43:  version${version}/version
./core/assembly/pom.xml:50:  version${version}/version
./core/assembly/pom.xml:69:  version${version}/version
./core/assembly/pom.xml:88:  version${version}/version
./core/assembly/pom.xml:94:  version${version}/version
./core/assembly/pom.xml:118:  
finalNamemyfaces-core-${version}/finalName
./core/assembly/pom.xml:144:  version${version}/version
./core/assembly/pom.xml:150:  version${version}/version
./tomahawk/sandbox/assembly/pom.xml:42:
version${version}/version
./tomahawk/sandbox/assembly/pom.xml:62:
version${version}/version
./tomahawk/sandbox/assembly/pom.xml:81:
version${version}/version
./tomahawk/sandbox/assembly/pom.xml:98:
version${version}/version
./tomahawk/sandbox/assembly/pom.xml:117:
finalNametomahawk-sandbox-${version}/finalName
./tomahawk/sandbox/assembly/pom.xml:155:
version${version}/version
./tomahawk/sandbox/core/pom.xml:30:version${version}/version
./tomahawk/sandbox/examples/assembly/pom.xml:40:
version${version}/version
./tomahawk/sandbox/examples/assembly/pom.xml:57:
finalNametomahawk-sandbox-examples-${version}/finalName
./tomahawk/sandbox/examples/pom.xml:45: 
   version${version}/version
./tomahawk/sandbox/examples/pom.xml:281:
version${version}/version
./tomahawk/assembly/pom.xml:43:  version${version}/version
./tomahawk/assembly/pom.xml:61:  version${version}/version
./tomahawk/assembly/pom.xml:79:  version${version}/version
./tomahawk/assembly/pom.xml:98:  version${version}/version
./tomahawk/assembly/pom.xml:124:  
finalNametomahawk-${version}/finalName
./tomahawk/assembly/pom.xml:149:  version${version}/version
./tomahawk/examples/blank/pom.xml:43:   
 version${version}/version
./tomahawk/examples/simple/pom.xml:43:  
  version${version}/version
./tomahawk/examples/assembly/pom.xml:39:
version${version}/version
./tomahawk/examples/assembly/pom.xml:45:
version${version}/version
./tomahawk/examples/assembly/pom.xml:51:
version${version}/version
./tomahawk/examples/assembly/pom.xml:57:
version${version}/version
./tomahawk/examples/assembly/pom.xml:74:
finalNametomahawk-examples-${version}/finalName
./tomahawk/examples/tiles/pom.xml:43:   
 version${version}/version
./tomahawk/examples/wap/pom.xml:43:
version${version}/version
./tomahawk/examples/pom.xml:61:version${version}/version
./tomahawk/sandbox15/core/pom.xml:30:version${version}/version
./tomahawk/sandbox15/core/pom.xml:37:version${version}/version
./tomahawk/sandbox15/examples/pom.xml:45:   
 version${version}/version
./tomahawk/sandbox15/examples/pom.xml:190:
version${version}/version
./tomahawk/sandbox15/examples/pom.xml:195:
version${version}/version


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

[jira] Created: (TOMAHAWK-1201) pom.xml uses deprecated syntax

2008-02-25 Thread Andrew Robinson (JIRA)

pom.xml uses deprecated syntax
--

 Key: TOMAHAWK-1201
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1201
 Project: MyFaces Tomahawk
  Issue Type: Task
  Components: Build Process (Assembly)
Affects Versions: 1.1.6
Reporter: Andrew Robinson
Priority: Trivial


${version} is a deprecated maven property. It should be changed to 
${pom.version} or ${project.version}.

Tomahawk Matches (grep style output): 

./shared/shared-tomahawk/pom.xml:41:  
version${version}/version
./tomahawk/sandbox/assembly/pom.xml:42:
version${version}/version
./tomahawk/sandbox/assembly/pom.xml:62:
version${version}/version
./tomahawk/sandbox/assembly/pom.xml:81:
version${version}/version
./tomahawk/sandbox/assembly/pom.xml:98:
version${version}/version
./tomahawk/sandbox/assembly/pom.xml:117:
finalNametomahawk-sandbox-${version}/finalName
./tomahawk/sandbox/assembly/pom.xml:155:
version${version}/version
./tomahawk/sandbox/core/pom.xml:30:version${version}/version
./tomahawk/sandbox/examples/assembly/pom.xml:40:
version${version}/version
./tomahawk/sandbox/examples/assembly/pom.xml:57:
finalNametomahawk-sandbox-examples-${version}/finalName
./tomahawk/sandbox/examples/pom.xml:45: 
   version${version}/version
./tomahawk/sandbox/examples/pom.xml:281:
version${version}/version
./tomahawk/assembly/pom.xml:43:  version${version}/version
./tomahawk/assembly/pom.xml:61:  version${version}/version
./tomahawk/assembly/pom.xml:79:  version${version}/version
./tomahawk/assembly/pom.xml:98:  version${version}/version
./tomahawk/assembly/pom.xml:124:  
finalNametomahawk-${version}/finalName
./tomahawk/assembly/pom.xml:149:  version${version}/version
./tomahawk/examples/blank/pom.xml:43:   
 version${version}/version
./tomahawk/examples/simple/pom.xml:43:  
  version${version}/version
./tomahawk/examples/assembly/pom.xml:39:
version${version}/version
./tomahawk/examples/assembly/pom.xml:45:
version${version}/version
./tomahawk/examples/assembly/pom.xml:51:
version${version}/version
./tomahawk/examples/assembly/pom.xml:57:
version${version}/version
./tomahawk/examples/assembly/pom.xml:74:
finalNametomahawk-examples-${version}/finalName
./tomahawk/examples/tiles/pom.xml:43:   
 version${version}/version
./tomahawk/examples/wap/pom.xml:43:
version${version}/version
./tomahawk/examples/pom.xml:61:version${version}/version
./tomahawk/sandbox15/core/pom.xml:30:version${version}/version
./tomahawk/sandbox15/core/pom.xml:37:version${version}/version
./tomahawk/sandbox15/examples/pom.xml:45:   
 version${version}/version
./tomahawk/sandbox15/examples/pom.xml:190:
version${version}/version
./tomahawk/sandbox15/examples/pom.xml:195:
version${version}/version

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

Re: Wildcard patterns in javax.faces.CONFIG_FILES parameter

2008-02-25 Thread Martin Marinschek

Hi Danny,

yes!!!

regards,

Martin

On Mon, Feb 25, 2008 at 10:56 AM, Danny Robinson
[EMAIL PROTECTED] wrote:
 Guys,

 I don't think it's possible to dynamically specify wildcard config loading
 patterns for JSF currently.  However, most all other frameworks today seem
 to be able to handle something similar for loading files by naming/location
 conventions.  I know JSF will pick-up META-INF/faces-confg.xml inside the
 jars, but my concern is mainly with navigation rules and creating modular UI
 bundles.

 Would there be appetite to have this as feature in the MyFaces
 implementation, disabled by default (for compliant with spec.), but enabled
 via a config setting?

 Thanks,

 Danny

 --
 Chordiant Software Inc.
  www.chordiant.com



-- 

http://www.irian.at

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

Professional Support for Apache MyFaces

Re: [ajax] UIViewRoot and (optimized) custom lifecycle

2008-02-25 Thread Martin Marinschek

Bug in the spec ;)

regards,

Martin

On Fri, Feb 22, 2008 at 6:35 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 Hi,

  it can be the case, that this mail may be a bit long..., but the main
  question I think is:
  Is there a public getPhaseListeners() method missing on UIVIewRoot ?

  Some general information since JSF 1.2... there is a public
  addPhaseListener() on UIViewRoot.
  So you can register a PhaseListener with the current view root (per
  view) to have beforePhase and afterPhase called
  on these lifecycle phases:
  -ApplyReqValue
  -processValidation
  -UpdateModel
  -Invoke App
  -RenderResponse

  You can add such a PL (PhaseListener) via the mentioned Java API or:
  f:phaseListener type=blah.MyPL /
  (this internally uses the Java API )

  Fine.

  now when you render a page and do a (regular) postback the
  phaselistener (its methods...) is executed.
  Fine.

  Now the ajax scenario.

  Some libraries (like ADF Faces Rich Client or Apache MyFaces
  Tobago(not Trinidad ;-) )) offer a custom lifecycle to call the
  lifecycle methods (such as processXyz()) only
  on the components, that are part of the ajax postback (why doing a
  decode on not effected components?).

  we do it like:
  uiViewRoot.invokeOnComponent(context, clientId, callback);

  where the *callback* is something like:
  static private class UpdateModelValuesCallback implements ContextCallback
  {
   public void invokeContextCallback(FacesContext context,
 UIComponent target)
   {
 target.processUpdates(context);
   }
  }

  usually these *optimized* lifecycles offer optimization for these phases:
  -ApplyReqValue
  -processValidation
  -UpdateModel

  not on:
  -Invoke App
  -RenderResponse

  For these, we just do a delegate back to the standard (default) behavior, 
 like:
  viewRoot.processApplication(context);

  So now the processXyz (like processUpdates()) is only! called on
  the ajax components!
  (Tobago does that in a similar way. They *fake* invokeOnComponent,
  since that lib is JSF 1.1 based)

  What does that mean, when submitting an ajax postback (maybe triggered
  by inputText autoSubmit=true /) ?
  The (to uiviewRoot) attached PL is only invoked for these phases:
  -Invoke App
  -RenderResponse

  Why?
  The big problem (IMO) is, that the PhaseListener(s) attached to the
  current (per view) UIViewRoot are *triggered* by the processXyz() of
  UIViewRoot itself (and encodeEnd and encodeBegin for RenderResponse phase).
  So... when only invoking them on the effected ajax components the
  before/afterPhase is never triggered (for the optimized phase).

  The optimized lifecycle could get the attached PhaseListeners, in case
  there where a public getPhaseListeners() method on UIViewRoot.
  I am wondering why there is none ? Simply forgotten?

  Please note, that (also since JSF 1.2) you can register methodExpression 
 like:
  f:view beforePhase=#{methodExpression} 
 afterPhase=#{otherMethodExpression}

  but... there is acutally a public getBeforePhaseListener() and a
  getAfterPhaseListener() as well.
  So a optimized lifecycle could get these MethodExpressions.

  What is your take on that?

  Thanks for reading,
  Matthias

  --
  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: [continuum] AAARGH! (was: svn commit: r628196 - /myfaces/myfaces-master-pom/trunk/pom.xml)

2008-02-25 Thread Scott O'Bryan

Sigh...  I'm sorry about that Manfred.  I should have been more 
careful.  It was a simple change, but apparently it was a simple change 
with a typo...


Anyway, thanks for the information and the upgrade...  ;-)

Scott

Manfred Geiler wrote:

Scott, your faulty master pom commit (timezome instead of
timezone) cost me half a day.

How come?
- Continuum did no longer build the master pom correctly
   -- your fault
- The continuum messages (see [1]) where totally misleading
   -- NOT your fault of course  ;-)
- Since I could not determine the cause (clearing working dir or
restarting continuum did not work) I decided to upgrade to continuum
1.1 final - due anyway
   -- MY fault!
- I was able to install the new version but migrating the data from
1.1-beta2 to 1.1 was a total flop - although I tried hard, believe me!
  (see http://wiki.apache.org/myfaces/Continuum_Build for details)
- So I stepped back to continuum 1.1-beta2
- I removed the build definition for the myfaces master
- I was not able to create a new build definition
- Now the continuum exceptions luckily lead me to the actual cause

@Scott
Please note:
I'm NOT posting this publicly to dev@ to blame you.
Yes, I'm angry. But not because of your mistake (could happen) but
because of Continuum.
And I want to prevent others form stepping into the same traps.  ;-)

@All
What should we do regarding Continuum builds?
Anyone volunteering to migrate all build definitions and users manually?

--Manfred


[1]

Build Error:

org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error
executing action 'update-project-from-working-directory'
   at 
org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:432)
   at 
org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:137)
   at 
org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50)
   at 
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
   at 
edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
   at 
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
   at 
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
   at 
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
   at java.lang.Thread.run(Thread.java:595)
Caused by: org.apache.maven.continuum.execution.ContinuumBuildExecutorException:
Error while mapping metadata:add.project.project.building.error
add.project.unknown.error

   at 
org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:159)
   at 
org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:75)
   at 
org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:406)
   ... 8 more



[2]
-- Forwarded message --
From:  [EMAIL PROTECTED]
Date: Fri, Feb 15, 2008 at 11:58 PM
Subject: svn commit: r628196 - /myfaces/myfaces-master-pom/trunk/pom.xml
To: [EMAIL PROTECTED]


Author: sobryan
 Date: Fri Feb 15 14:58:57 2008
 New Revision: 628196

 URL: http://svn.apache.org/viewvc?rev=628196view=rev
 Log:
 Added myself as a developer to MyFaces...

 Modified:
myfaces/myfaces-master-pom/trunk/pom.xml

 Modified: myfaces/myfaces-master-pom/trunk/pom.xml
 URL: 
http://svn.apache.org/viewvc/myfaces/myfaces-master-pom/trunk/pom.xml?rev=628196r1=628195r2=628196view=diff
 ==
 --- myfaces/myfaces-master-pom/trunk/pom.xml (original)
 +++ myfaces/myfaces-master-pom/trunk/pom.xml Fri Feb 15 14:58:57 2008
 @@ -205,6 +205,19 @@
 timezone+1/timezone
 /developer
 developer
 +idsobryan/id
 +nameScott O'Bryan/name
 +email[EMAIL PROTECTED]/email
 +organizationOracle, U.S.A/organization
 +organizationUrlhttp://www.oracle.com/organizationUrl
 +roles
 +rolePortlet Bridge Project Lead/role
 +roleJSR-301 JSF Portlet Bridge EG Member/role
 +rolePortlet Guru/role
 +/roles
 +timezome-7/timezone
 +/developer
 +developer
 idschof/id
 nameSean Schofield/name
 email[EMAIL PROTECTED]/email

Re: svn commit: r628919 - in /myfaces/trinidad/trunk_1.2.x: src/site/xdoc/devguide/ trinidad-api/src/main/java/org/apache/myfaces/trinidad/render/ trinidad-api/src/main/java/org/apache/myfaces/trinida

2008-02-25 Thread Jeanne Waldman


Blake, I'll have a look.
Thanks,
Jeanne

Blake Sullivan wrote:

Jeanne,

Can't we use the old code path in the case where the form component is 
not a naming container and the scoped id contains less than 2 colons.  
This is probably by far the most common case and I believe that the 
result is the same across all three schemes.


-- Blake

[EMAIL PROTECTED] wrote:

Author: jwaldman
Date: Mon Feb 18 15:24:14 2008
New Revision: 628919

URL: http://svn.apache.org/viewvc?rev=628919view=rev
Log:
TRINIDAD-936 changed the partialTrigger syntax so '::' pops out of 
naming container.

added test cases
changed RenderUtils's getRelativeId to work the same way.

Added:

myfaces/trinidad/trunk_1.2.x/trinidad-api/src/test/java/org/apache/myfaces/trinidad/render/ 

  - copied from r628838, 
myfaces/trinidad/branches/jwaldman_1.2-issue936/trinidad-api/src/test/java/org/apache/myfaces/trinidad/render/ 


myfaces/trinidad/trunk_1.2.x/trinidad-api/src/test/java/org/apache/myfaces/trinidad/render/RenderUtilsTest.java 

  - copied unchanged from r628838, 
myfaces/trinidad/branches/jwaldman_1.2-issue936/trinidad-api/src/test/java/org/apache/myfaces/trinidad/render/RenderUtilsTest.java 


myfaces/trinidad/trunk_1.2.x/trinidad-api/src/test/java/org/apache/myfaces/trinidad/util/FindRelativeComponentTest.java 

  - copied unchanged from r628838, 
myfaces/trinidad/branches/jwaldman_1.2-issue936/trinidad-api/src/test/java/org/apache/myfaces/trinidad/util/FindRelativeComponentTest.java 


myfaces/trinidad/trunk_1.2.x/trinidad-examples/trinidad-demo/src/main/java/org/apache/myfaces/trinidaddemo/TestRelativePartialTriggers.java 

  - copied unchanged from r628838, 
myfaces/trinidad/branches/jwaldman_1.2-issue936/trinidad-examples/trinidad-demo/src/main/java/org/apache/myfaces/trinidaddemo/TestRelativePartialTriggers.java 


myfaces/trinidad/trunk_1.2.x/trinidad-examples/trinidad-demo/src/main/webapp/demos/testRelativePartialTriggers.jspx 

  - copied, changed from r628838, 
myfaces/trinidad/branches/jwaldman_1.2-issue936/trinidad-examples/trinidad-demo/src/main/webapp/demos/testRelativePartialTriggers.jspx 


myfaces/trinidad/trunk_1.2.x/trinidad-examples/trinidad-demo/src/main/webapp/demos/testRelativePartialTriggersPrevRelease.jspx 

  - copied unchanged from r628838, 
myfaces/trinidad/branches/jwaldman_1.2-issue936/trinidad-examples/trinidad-demo/src/main/webapp/demos/testRelativePartialTriggersPrevRelease.jspx 


myfaces/trinidad/trunk_1.2.x/trinidad-impl/src/test/java/org/apache/myfaces/trinidadinternal/context/PartialTriggersTest.java 

  - copied unchanged from r628838, 
myfaces/trinidad/branches/jwaldman_1.2-issue936/trinidad-impl/src/test/java/org/apache/myfaces/trinidadinternal/context/PartialTriggersTest.java 


Modified:
myfaces/trinidad/trunk_1.2.x/src/site/xdoc/devguide/ppr.xml

myfaces/trinidad/trunk_1.2.x/trinidad-api/src/main/java/org/apache/myfaces/trinidad/render/RenderUtils.java 


myfaces/trinidad/trunk_1.2.x/trinidad-api/src/main/java/org/apache/myfaces/trinidad/util/ComponentUtils.java 


myfaces/trinidad/trunk_1.2.x/trinidad-api/src/main/xrts/org/apache/myfaces/trinidad/resource/LoggerBundle.xrts 


myfaces/trinidad/trunk_1.2.x/trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/core/includes/CommonAttrs.xml 


myfaces/trinidad/trunk_1.2.x/trinidad-examples/trinidad-demo/src/main/webapp/WEB-INF/faces-config.xml 


myfaces/trinidad/trunk_1.2.x/trinidad-examples/trinidad-demo/src/main/webapp/demos/pprDemos.jspx 


myfaces/trinidad/trunk_1.2.x/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/context/RequestContextImpl.java 


myfaces/trinidad/trunk_1.2.x/trinidad-impl/src/main/xrts/org/apache/myfaces/trinidadinternal/resource/LoggerBundle.xrts 



Modified: myfaces/trinidad/trunk_1.2.x/src/site/xdoc/devguide/ppr.xml
URL: 
http://svn.apache.org/viewvc/myfaces/trinidad/trunk_1.2.x/src/site/xdoc/devguide/ppr.xml?rev=628919r1=628918r2=628919view=diff 

== 

--- myfaces/trinidad/trunk_1.2.x/src/site/xdoc/devguide/ppr.xml 
(original)
+++ myfaces/trinidad/trunk_1.2.x/src/site/xdoc/devguide/ppr.xml Mon 
Feb 18 15:24:14 2008

@@ -155,21 +155,17 @@
 
 P
 Also, if you've got JSF NamingContainers (e.g., f:subview) between 
the trigger and its target,

-you'll need to incorporate that into the partialTriggers definition:
+you'll need to incorporate that into the partialTriggers definition. 
The syntax is:

 ul
 liIf you need to go down through a naming container to get to the 
trigger, include the naming container's ID with a colon (e.g., 
partialTriggers=theSubform:theLink/li
 liIf you need to start at the root of the page to get the trigger 
component, start with a single colon (e.g., 
partialTriggers=:someRootComponent/li
-liIf you need to go up and out of a parent naming container to get 
the trigger component,

Re: Wildcard patterns in javax.faces.CONFIG_FILES parameter

2008-02-25 Thread simon

Sounds like a good idea to me too.

On Mon, 2008-02-25 at 18:29 +0100, Martin Marinschek wrote:
 Hi Danny,
 
 yes!!!
 
 regards,
 
 Martin
 
 On Mon, Feb 25, 2008 at 10:56 AM, Danny Robinson
 [EMAIL PROTECTED] wrote:
  Guys,
 
  I don't think it's possible to dynamically specify wildcard config loading
  patterns for JSF currently.  However, most all other frameworks today seem
  to be able to handle something similar for loading files by naming/location
  conventions.  I know JSF will pick-up META-INF/faces-confg.xml inside the
  jars, but my concern is mainly with navigation rules and creating modular UI
  bundles.
 
  Would there be appetite to have this as feature in the MyFaces
  implementation, disabled by default (for compliant with spec.), but enabled
  via a config setting?
 
  Thanks,
 
  Danny
 
  --
  Chordiant Software Inc.
   www.chordiant.com

[jira] Updated: (TRINIDAD-918) Create an oracle skin in Trinidad that looks like 10.1.3, for migrating customers

2008-02-25 Thread JIRA


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

Matthias Weßendorf updated TRINIDAD-918:


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

committed this already early of FEB 2008

 Create an oracle skin in Trinidad that looks like 10.1.3, for migrating 
 customers
 -

 Key: TRINIDAD-918
 URL: https://issues.apache.org/jira/browse/TRINIDAD-918
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Reporter: Sandy Schaffner
Priority: Minor
 Fix For: 1.0.7-core, 1.2.7-core

 Attachments: suede.zip, suede080130.patch


 Customers who currently have 10.1.3 want to upgrade to Trinidad, but want 
 their applications to have the appearance of 10.1.3, not Trinidad.  Create a 
 skin for Trinidad that is similar to 10.1.3.

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

Re: Wildcard patterns in javax.faces.CONFIG_FILES parameter

2008-02-25 Thread Paul Spencer


Danny,
Sounds like a good idea.  I am not sure if the non-spec compliant use of 
the parameter javax.faces.CONFIG_FILES in conjunction with a parameter 
not defined by the spec,  like 
org.apache.myfaces.ENABLE_WILD_CARD_IN_CONFIG_FILES,
would violate the spec.  At the very least it would complicate the 
documentation of javax.faces.CONFIG_FILES.


Would a better solution be to create a parameter, like 
org.apache.myfaces.ADDITIONAL_CONFIG_FILES, which supports wildcards and 
pattern matching?  The resulting set of configuration files would be the 
config files identified by BOTH parameters.


Paul Spencer



Danny Robinson wrote:

Guys,

I don't think it's possible to dynamically specify wildcard config loading
patterns for JSF currently.  However, most all other frameworks today seem
to be able to handle something similar for loading files by naming/location
conventions.  I know JSF will pick-up META-INF/faces-confg.xml inside the
jars, but my concern is mainly with navigation rules and creating modular UI
bundles.

Would there be appetite to have this as feature in the MyFaces
implementation, disabled by default (for compliant with spec.), but enabled
via a config setting?

Thanks,

Danny

[jira] Created: (TRINIDAD-969) Text field validation causes NullPointerException

2008-02-25 Thread Steve Horne (JIRA)

Text field validation causes NullPointerException
-

 Key: TRINIDAD-969
 URL: https://issues.apache.org/jira/browse/TRINIDAD-969
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.0.5-core
 Environment: Win/XP, JBoss/Tomcat, Facelets
Reporter: Steve Horne


This bug manifests itself when an inputText field is used without a label 
attribute and is required, for example:

tr:inputText simple=true required=true/

AND The page also contains a messages tag:

tr:messages/

Entering nothing into the field results in a message displayed that the field 
is required.  Entering only whitespace characters results in a null pointer 
exception:

16:48:03,927 INFO  [STDOUT] 16:48:03,927 ERROR [[faces]] Servlet.service() for 
servlet faces threw exception
java.lang.NullPointerException
at 
org.apache.catalina.connector.CoyoteWriter.write(CoyoteWriter.java:171)
at 
org.apache.myfaces.trinidadinternal.io.HtmlResponseWriter.write(HtmlResponseWriter.java:340)
at com.sun.facelets.StateWriter.write(StateWriter.java:116)
at 
org.apache.myfaces.trinidadinternal.io.HtmlResponseWriter.write(HtmlResponseWriter.java:340)
at 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.MessageBoxRenderer._renderMessageAnchor(MessageBoxRenderer.java:305)
at 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.MessageBoxRenderer._renderComponentMessages(MessageBoxRenderer.java:263)
at 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.MessageBoxRenderer._renderContent(MessageBoxRenderer.java:204)
at 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.MessageBoxRenderer$BoxRenderer.renderBody(MessageBoxRenderer.java:453)
at 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBoxRenderer._renderMiddleRow(PanelBoxRenderer.java:267)
at 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBoxRenderer.encodeAll(PanelBoxRenderer.java:115)
at 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.MessageBoxRenderer.encodeAll(MessageBoxRenderer.java:142)
at 
org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:220)
at 
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:711)
at 
org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode._renderComponent(UIComponentUINode.java:337)
at 
org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render(UIComponentUINode.java:279)
at 
org.apache.myfaces.trinidadinternal.uinode.UIComponentUINode.render(UIComponentUINode.java:256)
at 
org.apache.myfaces.trinidadinternal.ui.composite.ContextPoppingUINode$ContextPoppingRenderer.render(ContextPoppingUINode.java:240)
at 
org.apache.myfaces.trinidadinternal.ui.BaseUINode.render(BaseUINode.java:358)
at 
org.apache.myfaces.trinidadinternal.ui.BaseUINode.render(BaseUINode.java:313)
at 
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderChild(BaseRenderer.java:425)
at 
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:343)
at 
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:235)
at 
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderContent(BaseRenderer.java:142)
at 
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.render(BaseRenderer.java:93)
at 
org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafRenderer.render(XhtmlLafRenderer.java:84)
at 
org.apache.myfaces.trinidadinternal.ui.BaseUINode.render(BaseUINode.java:358)
at 
org.apache.myfaces.trinidadinternal.ui.BaseUINode.render(BaseUINode.java:313)
at 
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderChild(BaseRenderer.java:425)
at 
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:343)
at 
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:235)
at 
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderContent(BaseRenderer.java:142)
at 
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.render(BaseRenderer.java:93)
at 
org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafRenderer.render(XhtmlLafRenderer.java:84)
at 
org.apache.myfaces.trinidadinternal.ui.BaseUINode.render(BaseUINode.java:358)
at 
org.apache.myfaces.trinidadinternal.ui.BaseUINode.render(BaseUINode.java:313)
at 
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderChild(BaseRenderer.java:425)
at 
org.apache.myfaces.trinidadinternal.ui.BaseRenderer.renderIndexedChild(BaseRenderer.java:343)
at

Re: [continuum] AAARGH! (was: svn commit: r628196 - /myfaces/myfaces-master-pom/trunk/pom.xml)

2008-02-25 Thread Manfred Geiler

On Mon, Feb 25, 2008 at 7:43 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
 Sigh...  I'm sorry about that Manfred.  I should have been more
  careful.  It was a simple change, but apparently it was a simple change
  with a typo...

Yeah, no problem. As I said before, my anger was at Continuum not at you.

But as we have learned: always look at the bright side. Now, I
actually learned how to start/stop/install/upgrade continuum. Hooray!
:-)

--Manfred






  Anyway, thanks for the information and the upgrade...  ;-)

  Scott



  Manfred Geiler wrote:
   Scott, your faulty master pom commit (timezome instead of
   timezone) cost me half a day.
  
   How come?
   - Continuum did no longer build the master pom correctly
  -- your fault
   - The continuum messages (see [1]) where totally misleading
  -- NOT your fault of course  ;-)
   - Since I could not determine the cause (clearing working dir or
   restarting continuum did not work) I decided to upgrade to continuum
   1.1 final - due anyway
  -- MY fault!
   - I was able to install the new version but migrating the data from
   1.1-beta2 to 1.1 was a total flop - although I tried hard, believe me!
 (see http://wiki.apache.org/myfaces/Continuum_Build for details)
   - So I stepped back to continuum 1.1-beta2
   - I removed the build definition for the myfaces master
   - I was not able to create a new build definition
   - Now the continuum exceptions luckily lead me to the actual cause
  
   @Scott
   Please note:
   I'm NOT posting this publicly to dev@ to blame you.
   Yes, I'm angry. But not because of your mistake (could happen) but
   because of Continuum.
   And I want to prevent others form stepping into the same traps.  ;-)
  
   @All
   What should we do regarding Continuum builds?
   Anyone volunteering to migrate all build definitions and users manually?
  
   --Manfred
  
  
   [1]
   
 
   Build Error:
   
 
   org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error
   executing action 'update-project-from-working-directory'
  at 
 org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:432)
  at 
 org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:137)
  at 
 org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50)
  at 
 org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
  at 
 edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
  at 
 edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
  at 
 edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
  at 
 edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
  at java.lang.Thread.run(Thread.java:595)
   Caused by: 
 org.apache.maven.continuum.execution.ContinuumBuildExecutorException:
   Error while mapping metadata:add.project.project.building.error
   add.project.unknown.error
  
  at 
 org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.updateProjectFromCheckOut(MavenTwoBuildExecutor.java:159)
  at 
 org.apache.maven.continuum.core.action.UpdateProjectFromWorkingDirectoryContinuumAction.execute(UpdateProjectFromWorkingDirectoryContinuumAction.java:75)
  at 
 org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:406)
  ... 8 more
  
  
  
   [2]
   -- Forwarded message --
   From:  [EMAIL PROTECTED]
   Date: Fri, Feb 15, 2008 at 11:58 PM
   Subject: svn commit: r628196 - /myfaces/myfaces-master-pom/trunk/pom.xml
   To: [EMAIL PROTECTED]
  
  
   Author: sobryan
Date: Fri Feb 15 14:58:57 2008
New Revision: 628196
  
URL: http://svn.apache.org/viewvc?rev=628196view=rev
Log:
Added myself as a developer to MyFaces...
  
Modified:
   myfaces/myfaces-master-pom/trunk/pom.xml
  
Modified: myfaces/myfaces-master-pom/trunk/pom.xml
URL: 
 http://svn.apache.org/viewvc/myfaces/myfaces-master-pom/trunk/pom.xml?rev=628196r1=628195r2=628196view=diff

 ==
--- myfaces/myfaces-master-pom/trunk/pom.xml (original)
+++ myfaces/myfaces-master-pom/trunk/pom.xml Fri Feb 15 14:58:57 2008
@@ -205,6 +205,19 @@
timezone+1/timezone
/developer
developer
+idsobryan/id
+nameScott O'Bryan/name
+email[EMAIL PROTECTED]/email
+

[Trinidad demos] update needed

2008-02-25 Thread Sandy Schaffner

I recently updated the Trinidad demos to include links to the Trinidad Tag doc 
and Trinidad Skin Selectors.  
And I updated the skin-selectors.xml to alphabetize the component names and 
remove obsolete items.
These pages were then committed.
https://issues.apache.org/jira/browse/TRINIDAD-964

What is the process to push the updated pages out so they will appear here?
http://www.irian.at/trinidad-demo/faces/componentDemos.jspx
http://myfaces.apache.org/trinidad/skin-selectors.html

Thanks, Sandy

[jira] Created: (TRINIDAD-970) PPR and multiple forms

2008-02-25 Thread Tomas Cerny (JIRA)

PPR and multiple forms
--

 Key: TRINIDAD-970
 URL: https://issues.apache.org/jira/browse/TRINIDAD-970
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 1.2.6-core, 1.2.5-core
 Environment: JSF 1.2 Sun, Facelets 1.1.14
Reporter: Tomas Cerny
 Fix For: 1.2.7-plugins


I tried to use newer Trinidad, (I had 1.2.1) and got in troubles with multiple 
forms.

I have a dialog that sets a value to my bean. When I have just one form in my 
view then everything is ok. 
When I have more forms than it will set the value, but on form submit it 
crashes because property is null. 

Could be id generation problem which does not set id to form hidden input

input type=hidden value=teamFormMain 
name=org.apache.myfaces.trinidad.faces.FORM/


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

Re: [Trinidad demos] update needed

2008-02-25 Thread Matthias Wessendorf

Hi,

the trinidad demos are updated on a volunteer base.
I think perhaps we may have a (like demos.myfaces.apache.org) machine,
where other projects (tobago) also
can deploy their demos ?

-M

On Mon, Feb 25, 2008 at 11:05 PM, Sandy Schaffner
[EMAIL PROTECTED] wrote:
 I recently updated the Trinidad demos to include links to the Trinidad Tag 
 doc and Trinidad Skin Selectors.
  And I updated the skin-selectors.xml to alphabetize the component names and 
 remove obsolete items.
  These pages were then committed.
  https://issues.apache.org/jira/browse/TRINIDAD-964

  What is the process to push the updated pages out so they will appear here?
  http://www.irian.at/trinidad-demo/faces/componentDemos.jspx
  http://myfaces.apache.org/trinidad/skin-selectors.html

  Thanks, Sandy





-- 
Matthias Wessendorf

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

Wildcard patterns in javax.faces.CONFIG_FILES parameter

[continuum] upgrading

[continuum] upgrading

[Trinidad] EOL settings not on files

Re: [Trinidad] EOL settings not on files

[jira] Created: (MYFACES-1823) pom.xml uses deprecated syntax

[continuum] AAARGH! (was: svn commit: r628196 - /myfaces/myfaces-master-pom/trunk/pom.xml)

[jira] Deleted: (MYFACES-1824) pom.xml uses deprecated syntax

[jira] Created: (MYFACES-1824) pom.xml uses deprecated syntax

[jira] Created: (TOMAHAWK-1201) pom.xml uses deprecated syntax

Re: Wildcard patterns in javax.faces.CONFIG_FILES parameter

Re: [ajax] UIViewRoot and (optimized) custom lifecycle

Re: [continuum] AAARGH! (was: svn commit: r628196 - /myfaces/myfaces-master-pom/trunk/pom.xml)

Re: svn commit: r628919 - in /myfaces/trinidad/trunk_1.2.x: src/site/xdoc/devguide/ trinidad-api/src/main/java/org/apache/myfaces/trinidad/render/ trinidad-api/src/main/java/org/apache/myfaces/trinida

Re: Wildcard patterns in javax.faces.CONFIG_FILES parameter

[jira] Updated: (TRINIDAD-918) Create an oracle skin in Trinidad that looks like 10.1.3, for migrating customers

Re: Wildcard patterns in javax.faces.CONFIG_FILES parameter

[jira] Created: (TRINIDAD-969) Text field validation causes NullPointerException

Re: [continuum] AAARGH! (was: svn commit: r628196 - /myfaces/myfaces-master-pom/trunk/pom.xml)

[Trinidad demos] update needed

[jira] Created: (TRINIDAD-970) PPR and multiple forms

Re: [Trinidad demos] update needed

22 matches

Site Navigation

Mail list logo

Footer information