Re: variable resolver/dependency injection problem

[Craig McClanahan]

On 8/21/06, Fausey,Jonathan <[EMAIL PROTECTED]> wrote:


I grabbed shale-sql-browser-20060821.zip, extracted
shale-core-1.0.4-SNAPSHOT.jar and
shale-tiger-1.0.4-SNAPSHOT.jar, replaced their previous counterparts in
my webapp
deployment, and the behavior didn't change.  Declaring the dependant
property (wrappedData)
first and the property it dependeds on (viewIdProperty) second works and
the reverse doesn't.



Sorry for the extra workout, and thanks for double checking.  Sounds like we
have a current bug to deal with here.

-Jon


Craig

-Original Message-

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig
McClanahan
Sent: Monday, August 21, 2006 3:51 PM
To: user@shale.apache.org
Subject: Re: variable resolver/dependency injection problem

On 8/21/06, Fausey,Jonathan <[EMAIL PROTECTED]> wrote:
>
> I used the shale-framework-1.0.3-SNAPSHOT, which I downloaded on July
> 27.
>
> I'd be happy to test a newer snapshot or nightly shale-framework
> build, but I can't find one...



Wow ... that's wierd ... its[1] got the sample apps but not the
framework.
I'll see what I can do about pushing out a daily build of the framework
stuff this afternoon.  In the mean time, you could grab one of the
samples if you wanted, and rip shale-core.jar and shale-tiger.core etc.
out of the WEB-INF/lib directory of the war file.

Craig

[1]  http://people.apache.org/builds/shale/nightly/

RE: variable resolver/dependency injection problem

[Fausey,Jonathan]

No problem.  Just a few questions since I haven't tracked a bug here
before.

Will you be reporting it?  Is
http://issues.apache.org/struts/secure/IssueNavigator.jspa?...
the appropriate place to track it?  What should I search for to find it?

Thanks. 

-Jon

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig
McClanahan
Sent: Monday, August 21, 2006 4:25 PM
To: user@shale.apache.org
Subject: Re: variable resolver/dependency injection problem

On 8/21/06, Fausey,Jonathan <[EMAIL PROTECTED]> wrote:
>
> I grabbed shale-sql-browser-20060821.zip, extracted 
> shale-core-1.0.4-SNAPSHOT.jar and shale-tiger-1.0.4-SNAPSHOT.jar, 
> replaced their previous counterparts in my webapp deployment, and the 
> behavior didn't change.  Declaring the dependant property 
> (wrappedData) first and the property it dependeds on (viewIdProperty) 
> second works and the reverse doesn't.


Sorry for the extra workout, and thanks for double checking.  Sounds
like we have a current bug to deal with here.

-Jon


Craig

-Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of 
> Craig McClanahan
> Sent: Monday, August 21, 2006 3:51 PM
> To: user@shale.apache.org
> Subject: Re: variable resolver/dependency injection problem
>
> On 8/21/06, Fausey,Jonathan <[EMAIL PROTECTED]> wrote:
> >
> > I used the shale-framework-1.0.3-SNAPSHOT, which I downloaded on 
> > July 27.
> >
> > I'd be happy to test a newer snapshot or nightly shale-framework 
> > build, but I can't find one...
>
>
>
> Wow ... that's wierd ... its[1] got the sample apps but not the 
> framework.
> I'll see what I can do about pushing out a daily build of the 
> framework stuff this afternoon.  In the mean time, you could grab one 
> of the samples if you wanted, and rip shale-core.jar and
shale-tiger.core etc.
> out of the WEB-INF/lib directory of the war file.
>
> Craig
>
> [1]  http://people.apache.org/builds/shale/nightly/
>

Re: Questions about the logo contest

[James Mitchell]

On Sep 6, 2006, at 7:22 AM, Randahl Fink Isaksen wrote:


Three questions:

1. Are we not supposed to wait until September 19 before voting?



No, there's no harm in voting early.


2. On the contest page it says "Everyone is welcome to vote,  
however, only binding votes will be used to determine the winner."  
- could anyone explain what that means?




The point of all this is to get a consensus of what we (as a  
community) would like to see for our new logo.  The reason that only  
committer votes are binding is because (my opinion here)  because  
we all know who the committers are.


What I mean is, let's say we held a vote and anyone and everyone was  
allowed to vote.  What's to stop someone from registering 50 gmail  
addresses and sending in his/her votes?  Whether it was an author of  
one entry or not, it still isn't fair.  While I hate to base my logic  
on a foundation of mistrust, I know for a fact that there are several  
individuals out there who would do just that.  Therefore, the Shale  
PMC encourages everyone to discuss and vote on their favorites and  
while a user vote might not be binding, it can be influential.  I  
mean, if 20 people *really* like a particular entrychances are  
pretty good that I'm going to go and take a second look.


Keep in mind that all of the entries should be cleared through ASF  
legal@ and pr@ (public relations) before any winner can be  
announced.  I'm about to send that right now.


Also, to all the authors, we will need the source file(s) for these  
entries, preferably Photoshop (.psd).





3. Are the contributors themselves supposed to vote?



Sure, all are welcome.


Randahl



David Delbecq wrote:
Here is my user vote :) 1st choice: Walied Amer {81} 2nd choice:  
Michael Ameduri {15} 3rd choice: Jacob Hookom {3} 4th choice:  
Santy {77 } 5th choice: Norbert Busch {90} Daniela Kolarova a écrit :
Shale logo contest vote: 1st choice: # {Entry #} 2nd choice: #  
{Entry #} 3rd choice: # {Entry #} 4th choice: # {Entry #} 5th  
choice: # {Entry #}


--
James Mitchell
678.910.8017

Re: cactus and shale test framework

[Craig McClanahan]

On 9/6/06, Jason Vincent <[EMAIL PROTECTED]> wrote:


Hi there,

I'm trying to create some junit tests for my VC's.  All my current
domain tests use Cactus so that they can use the DB connectivity.

To use cactus, my test cases are extending ServletTestCase.  So when I
want to test the VC's I would also need to extend
AbstractViewControllerTestCase - and there lies my problem.

Has anyone used Cactus with the Shale Testing framework?
Any suggestions?



The Shale test framework is really focused on supporting standalone unit
tests, while Cactus is all about testing inside the container.  It would
seem likely that a Cactus adapter layer (which would include, for example, a
base test case for testing view controllers inside the container) would be
useful -- but its implementation would be very different than the one in the
current test framework, which is all about setting up a mock objects
simulation of the runtime environment inside the container.


Jason





Craig

Re: Shale validation with custom rules

[Gary VanMatre]

>From: "Wendy Smoak" <[EMAIL PROTECTED]> 
>
> I'm having trouble with a custom validation rule. This used to work, 
> before we had and before the switch to 
> commons-validator 1.3.0. (Not that either of those changes is 
> necessarily the cause of this problem, just trying to establish a 
> timeline. :) ) 
>

 
There are several issues logged in the commons validator that required some 
change.  I think you are missing the formset/form info for your custom rule.

  
  
  
  
  
  
   




 I'll try to summarize some of the issues:


https://issues.apache.org/struts/browse/SHALE-31
https://issues.apache.org/struts/browse/SHALE-37 – client side validation for 
immediate
https://issues.apache.org/struts/browse/SHALE-65 – client validation in data 
list
https://issues.apache.org/struts/browse/SHALE-73 – ignores dependencies
https://issues.apache.org/struts/browse/SHALE-180
https://issues.apache.org/struts/browse/SHALE-194
https://issues.apache.org/struts/browse/SHALE-217 – value binding in the data 
table
https://issues.apache.org/struts/browse/SHALE-247
https://issues.apache.org/struts/browse/SHALE-248 




The big ones are 37, 65, 73, 217. They are not listed in the order they were 
completed. 


SHALE-73 – This one reported that rule dependencies were not be evaluated 
server side. This ended up being a pretty big deal due to the way the validator 
rules were being invoked. 


In Struts, the validator functions were all wrapped in a method that had a 
common signature. The actual validation rule was invoked from the wrapper 
function. The way it was implemented in shale was that the commons validator 
directly invoked the validation function – no wrapping function. 


The problem with invoking a dependent validation rule before the target, was 
that here was not any way to determine what the value of the formal parameter 
should be passed of the dependent function.


To solve this problem, I used the validator form XML nodes to define the order 
of the parameters and the name of the parameter being passed. I created a dummy 
form to hold this extra meta-data. The form only has be be defined once per 
custom validation rule. It's kind of a weird requirement but it's better than 
having to define this information for each form you want to use the validation 
on. In Struts, this was not abnormal since it's action oriented versus 
component based. In JSF, it is more natural to capture validation parameter for 
each instance of the validator. 


I tried to communicate this in the JavaDoc 
(http://shale.apache.org/shale-core/apidocs/org/apache/shale/validator/CommonsValidator.html)


I also created a bunch of test cases that invoke the validation (server side) 
and test the rendering of the javascript by the ValidatorScript component.


http://svn.apache.org/viewvc/shale/framework/trunk/shale-core/src/test/java/org/apache/shale/validator/CommonsValidatorTestCase.java?view=markup




SHALE-37 – In Strtus, we have a couple types of buttons. The submit button and 
the cancel button. The cancel button added a bit of javascript that bypassed 
client side validation. This issue is about mimicking the same behavior for 
command's (commandLink, commandButton) that have their immediate flag turned 
on. The trick here is to inject a bit of javascript without having to rewrite 
the commands renderer's. The approach was to wrapper the RenderKit and wrapper 
the renderer's of the command family. The decorated renderer's hijack the 
response writer for just the rendering and swap back the original. We found 
that it was only safe to do this for the command components that are required 
by the RI because other components play the same games.


SHALE-65 – This is also another interesting issue having to do with client side 
validation within a UIData component. Components that extend UIData display a 
grid of information. These components implement the fly weight pattern meaning 
that they only contain components that represent a single row of the backing 
model. As rendering occurs, the model is enumerated. This was a problem for the 
ValidatorScript component that builds all of the client side javascript buy 
looking at the tree after most of the tree had already been rendered. The 
client side script needed to have the client id's of each input component in a 
dataTable. The only way to capture the component client ids is at render time. 
The same renderer decorate trick was used to capture the client id's of each 
component before rendering and tuck them into a collection stored in the 
components attributes collection.




SHALE-217 – This one also had to do with client side script within a UIData 
component. The validator attributes for the canned rules support value binding 
expressions. The binding expressions were only invoked once per component 
within the UIData component. This didn't work for client side validation since 
the bi

Re: Shale validation with custom rules

[Wendy Smoak]

On 9/25/06, Gary VanMatre <[EMAIL PROTECTED]> wrote:


There are several issues logged in the commons validator that required some 
change.  I think you are missing the formset/form info for your custom rule.


Thanks, that was it.

Can you clarify something in the Javadoc [1]?

It says "Within the field definition, arg's are used to define the
parameters in order for message substitution and method argument value
resolution. There are two reserved name values for the arg node used
to define messages and parameters."

In the second sentence, what are the two 'reserved name values'?

(I think you might mean 'arg' and 'submittedValue'... but those are
'key values'.)

I'm also not sure why three 'message' args are shown, when the
errors.invalid message only uses {0}.

[1]  
http://shale.apache.org/shale-core/apidocs/org/apache/shale/validator/CommonsValidator.html

Thanks,
Wendy

Re: Shale validation with custom rules

[Gary VanMatre]

>From: "Wendy Smoak" <[EMAIL PROTECTED]> 
>
> On 9/25/06, Gary VanMatre wrote: 
> 
> > There are several issues logged in the commons validator that required some 
> change. I think you are missing the formset/form info for your custom rule. 
> 
> Thanks, that was it. 
> 
> Can you clarify something in the Javadoc [1]? 
> 
> It says "Within the field definition, arg's are used to define the 
> parameters in order for message substitution and method argument value 
> resolution. There are two reserved name values for the arg node used 
> to define messages and parameters." 
> 
> In the second sentence, what are the two 'reserved name values'? 
> 
> (I think you might mean 'arg' and 'submittedValue'... but those are 
> 'key values'.) 
> 

No, I was trying to point to the literal value of the name attribute in the 
arg's node as having two reserved enumerations "message|parameter".

 I'm also not sure why three 'message' args are shown, when the 
> errors.invalid message only uses {0}. 
> 

The validator message can be overridden within the view.  By being able to 
specify multiple message parameters, you can customize your own message.
You can give all options that apply to the validation rule and let the 
developer 
choose what fits the context.

For example, the mask rule defines three message parameters.





You might choose to override the default with a custom message.

 [1] 
> http://shale.apache.org/shale-core/apidocs/org/apache/shale/validator/CommonsVal
>  
> idator.html 
> 
> Thanks, 
> Wendy 


Gary

Re: Shale-Tiles and JSF 1.2

[Craig McClanahan]

On 9/29/06, Steven Oglesby <[EMAIL PROTECTED]> wrote:


I originally posted a message because I could not get this working.
However,
it does not seem to have ever reached the mailing list.



I have now solved my problem. The TilesViewHandler does not seem to handle
the JSF 1.2 spec. It does not fulfil the requirements of wrapping and
buffering the response. This has been introduced in the JSF 1.2 spec in
order to solve the JSF / JSP content interweaving problems.



My (rather inelegant) solution is to have copied the renderView method
implementation (and all the subsequent methods it calls) from the
ViewHandlerImpl class of the Sun RI of JSF 1.2. I have then made the
necessary changes so that the executePageToBuildView method dispatches to
the tile rather than the original viewId that was asked for.



If I can come up with a more elegant solution I will attempt to contribute
it to the project. Otherwise I hope this may be of some assistance.



Thanks a bunch for doing this research.  To make sure we get it addressed,
could you please file a bug in our issue tracking system (
http://issues.apache.org/struts) against the Tiles component of Shale, and
report your findings there?

Craig


Steven

Re: Order of validating the components

[Craig McClanahan]

On 10/5/06, a k <[EMAIL PROTECTED]> wrote:


Hi,

I was looking at the source for Token and I saw this comment in there:

// WARNING - for this test to be successful, the token component
must
// be the last input component child of the parent form to be
// processed

I understand why the control needs to be validated after all the other
controls are validated but I am not sure where you specify to validate
this
control at the end. Can we specify the order and if so where?



At any given level of the component tree, validations occur in the order
that the parent component's getChildren() method returns them.  In turn,
that is based on the order they are specified in the source code.  Thus, for
the purposes of making sure the token component is validated last, simply
make it the last component (or at least the last input component) inside the
containing form component.

Thanks in advance!




Craig

Re: Tiles Failure in GlassFish: org.apache.tiles.NoSuchDefinitionException

[Antonio Petrelli]

Gregg Leichtman ha scritto:

/index.jsp:


  


The problem is that you are trying to forward to a layout page, without 
filling its attributes.

You have to forward to a page that contains:

 (I guess this is what you need)

where "/welcomePage" is the name of the definition.

Ciao
Antonio

Re: Tiles Failure in GlassFish: org.apache.tiles.NoSuchDefinitionException

[Gregg Leichtman]

I suppose that I could create a different definition like:












and then use 



however, I have used the previous method for rendering the "put" described 
_within_ the definition successfully under Tomcat with shale-1.0.3. This is 
also described by Dick Starr at:


http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#a6288731

where he inserts the title and body "puts" successfully. Are both of use doing 
different things? If so, can you point out what I'm doing that is different or 
something that is now obsolete in shale-1.0.4?

 -=> Gregg <=-





Antonio Petrelli wrote:
> Gregg Leichtman ha scritto:
>> /index.jsp:
>>
>> 
>>   
>
> The problem is that you are trying to forward to a layout page,
> without filling its attributes.
> You have to forward to a page that contains:
>
>  (I guess this is what you need)
>
> where "/welcomePage" is the name of the definition.
>
> Ciao
> Antonio
>



signature.asc
Description: OpenPGP digital signature

Re: Tiles Failure in GlassFish: org.apache.tiles.NoSuchDefinitionException

[Antonio Petrelli]

Gregg Leichtman ha scritto:

I suppose that I could create a different definition like:












and then use 



  


This is the *right* way!


however, I have used the previous method for rendering the "put" described 
_within_ the definition successfully under Tomcat with shale-1.0.3. This is also 
described by Dick Starr at:


http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#a6288731
  


I suppose that Dick describes an already fixed bug, since its NPE stack 
trace points to a line where there is no code.



Are both of use doing different things?


Sure! You are trying to forward to a layout page without filling 
attributes, you have to forward to a page that contains a name="definitionName" />

Dick did the right thing.


 If so, can you point out what I'm doing that is different or something that is 
now obsolete in shale-1.0.4?
  


It has nothing to do with Shale, eventually it is a Tiles bug (though in 
this case is a bug of yours :-) ).


Ciao
Antonio

Re: Tiles Failure in GlassFish: org.apache.tiles.NoSuchDefinitionException

[Gregg Leichtman]

I'm referring to the following post from Mr. Starr:


    RE: Shale 1.0.3 and Tiles Question - Tag Question

<http://www.nabble.com/RE%3A-Shale-1.0.3-and-Tiles-Question---Tag-Question-p6288731.html>

Click to flag this post 

by Dick Starr <http://www.nabble.com/user/UserProfile.jtp?user=4421> Sep
13, 2006; 12:06pm :: Rate this Message: Click to rate as Poor Post
<http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#>Click
to rate as Below Average Post
<http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#>Click
to rate as Average Post
<http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#>Click
to rate as Above Average Post
<http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#>Click
to rate as Excellent Post
<http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#>Click
to clear rating
<http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#>
- Use ratings to moderate (? <http://www.nabble.com/help/Answer.jtp?id=16>)

Reply <http://www.nabble.com/forum/Reply.jtp?post=6288731> | Reply to
Author <http://www.nabble.com/user/SendEmail.jtp?type=pm&post=6288731> |
View Threaded  |
Link to this Message
<http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#a6288731>


I installed the 20060911 version and got NullPointerExceptions. It is
working now however, with the following fixes:

(1) My index.jsp contained 

where my /tiles/system/SaLogon.jsp now contains

(to get it to work I added the type="definition").

(2)
In my tiles.xml I have

  put name="header" ...
  put name="menuBar" ...
  put name="body" value=""/>
  ...




(saLogon.jsp is an 
...

...

...

My tiles inserts work whether or not each insert is bracketed by a
subview.


Dick

Sorry, I'm still confused as to how my original approach is different
from Mr. Starr's. As far as I can see, he seems to be inserting tiles 
in his /tiles/layouts/classicLayout _directly_ from the "puts" for title
and body, not from an extended definition wrapped around either the
title or body. Is his approach correct because he is inserting from
"puts" that are defined within an extended definition?

  -=> Gregg <=-

Antonio Petrelli wrote:
> Gregg Leichtman ha scritto:
>> I suppose that I could create a different definition like:
>>
>> 
>> 
>> > value="/tiles/headerTile.jsp"/>
>> > value="/tiles/rightSideBarTile.jsp"/>
>> > value="/tiles/footerTile.jsp"/>
>> 
>>
>> 
>> > value="/tiles/htmlHeaderTile.jsp"/>
>> 
>>
>> and then use
>> 
>>   
>
> This is the *right* way!
>
>> however, I have used the previous method for rendering the "put"
>> described _within_ the definition successfully under Tomcat with
>> shale-1.0.3. This is also described by Dick Starr at:
>>
>> 
>> http://www.nabble.com/Shale-1.0.3-and-Tiles-Question---Tag-Question-t2204571.html#a6288731
>>
>>   
>
> I suppose that Dick describes an already fixed bug, since its NPE
> stack trace points to a line where there is no code.
>
>> Are both of use doing different things?
>
> Sure! You are trying to forward to a layout page without filling
> attributes, you have to forward to a page that contains a
> 
> Dick did the right thing.
>
>>  If so, can you point out what I'm doing that is different or
>> something that is now obsolete in shale-1.0.4?
>>   
>
> It has nothing to do with Shale, eventually it is a Tiles bug (though
> in this case is a bug of yours :-) ).
>
> Ciao
> Antonio
>



signature.asc
Description: OpenPGP digital signature

Re: Tiles Failure in GlassFish: org.apache.tiles.NoSuchDefinitionException

[Antonio Petrelli]

Gregg Leichtman ha scritto:

Sorry, I'm still confused as to how my original approach is different
from Mr. Starr's. As far as I can see, he seems to be inserting tiles 
in his /tiles/layouts/classicLayout _directly_ from the "puts" for title

and body, not from an extended definition wrapped around either the
title or body. Is his approach correct because he is inserting from
"puts" that are defined within an extended definition?
  


No, it has nothing to do with extended definitions.
Again, your "index.jsp" pages says:

*snip*



*snap*

I suppose that siteLayout.faces points to siteLayout.jsp, right?
Ok, as far as I can see, your siteLayout.jsp is a layout page. A layout 
page is made of NOT FILLED attributes. You can fill them through the use 
of definitions, as you did in:


*snip*

   
   
   
   
   
   

   
   
   

*snap*

But you forward to "siteLayout.faces" (that forwards to 
"siteLayout.jsp") that is used by "/mainLayout" definition. Instead you 
need to "forward" to the definition itself, not its layout page!

Therefore, prepare a JSP page containing:


HTH
Antonio

P.S.: I committed some code that corrects some misleading exception 
messages. Anyway to check it, you should download the source code from SVN.

RE: Tiles Failure in GlassFish: org.apache.tiles.NoSuchDefinitionException

[Dick Starr]

I never did like the fact that my index.jsp couldn't just reference a
tile, but it was the only way I could make it work (all my other jsp's
could reference tiles). However, I have continued to upgrade to the
latest releases in the hopes of improving things, and I am now running
the 10/4/06 release of Shale.

My index.jsp now says  where
"systemLogon.faces" is a tile def as follows:


  


Dick

-Original Message-
From: Antonio Petrelli [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 11, 2006 6:50 AM
To: user@shale.apache.org
Subject: Re: Tiles Failure in GlassFish:
org.apache.tiles.NoSuchDefinitionException

Gregg Leichtman ha scritto:
> Sorry, I'm still confused as to how my original approach is different
> from Mr. Starr's. As far as I can see, he seems to be inserting tiles 
> in his /tiles/layouts/classicLayout _directly_ from the "puts" for
title
> and body, not from an extended definition wrapped around either the
> title or body. Is his approach correct because he is inserting from
> "puts" that are defined within an extended definition?
>   

No, it has nothing to do with extended definitions.
Again, your "index.jsp" pages says:

*snip*



*snap*

I suppose that siteLayout.faces points to siteLayout.jsp, right?
Ok, as far as I can see, your siteLayout.jsp is a layout page. A layout 
page is made of NOT FILLED attributes. You can fill them through the use

of definitions, as you did in:

*snip*












*snap*

But you forward to "siteLayout.faces" (that forwards to 
"siteLayout.jsp") that is used by "/mainLayout" definition. Instead you 
need to "forward" to the definition itself, not its layout page!
Therefore, prepare a JSP page containing:


HTH
Antonio

P.S.: I committed some code that corrects some misleading exception 
messages. Anyway to check it, you should download the source code from
SVN.

Re: Tiles Failure in GlassFish: org.apache.tiles.NoSuchDefinitionException

[Greg Reddin]

On Oct 11, 2006, at 6:06 AM, Gregg Leichtman wrote:


I suppose that I could create a different definition like:











	



and then use



however, I have used the previous method for rendering the "put"  
described _within_ the definition successfully under Tomcat with  
shale-1.0.3. This is also described by Dick Starr at:


Antonio was correct, but I think his point somehow got lost.  You  
don't actually need another definition.  You need another JSP page.   
Let's break it down with a simple example:


Suppose you have a definition:


  
  
  


Then here's foobar.jsp:




  
  
  




If you just type "/foobar.jsp" into your browser Tiles is going to  
blow up saying you're trying to insert a definition called "header"  
which it can't find.  It doesn't realize you are already *in* a  
definition called "foobar" and you're trying to insert an *attribute*  
called "header" because you never invoked Tiles to get the definition  
called "foobar".  Therefore Tiles thinks you're looking for a  
definition called "header".


To make the above example work you need an intermediate JSP.  Let's  
call it intermediate.jsp.  Here's what it would look like in its  
entirety:


<%@ taglib uri="http://struts.apache.org/tags-tiles"; prefix="tiles" %>


Then, instead of typing "/foobar.jsp" in your browser you'd type "/ 
intermediate.jsp" in your browser.  Tiles will go find the definition  
called "foobar", invoke the foobar.jsp template and process your  
header, body, and footer.


In JSF, by doing > you are calling /siteLayout.jsp directly - as if you simply typed  
the name of that page in your browser.  You are not using Tiles to  
invoke the template, you are invoking it directly.  Using the example  
above you need to do something like this:


index.jsp:



intermediate.jsp:

<%@ taglib uri="http://struts.apache.org/tags-tiles"; prefix="tiles" %>


Or in your case, intermediate.jsp would look like this:

<%@ taglib uri="http://struts.apache.org/tags-tiles"; prefix="tiles" %>


There are two reasons why this is confusing:

1)  Tiles has no controller.   You would like to be able to invoke  
Tiles by simply calling the template page, but you can't.  You have  
to either call an intermediate page that invokes the template using  
the  tag to insert the definition.  Or you have to use  
a controller architecture like Struts or JSF that knows how to  
forward to a Tiles definition.  In essence, Struts and JSF are doing  
the  for you in the  
TielsRequestProcessor and TilesViewHandler respectively.  Those  
components know how to call into Tiles, get a Tiles definition, and  
process it.


Perhaps you'd like Tiles to have a controller so you could type a URL  
like "http://mywebapp/mainLayout.tiles"; and a Servlet or something  
would insert the "mainLayout" definition.  But we probably won't do  
that because Tiles was not meant to be a controller, it was meant to  
work with other controllers like Struts or JSF.  In "standalone" mode  
it requires an intermediate JSP.


Another option for improvement would be to make Tiles work more like  
Facelets.  Facelets does not require the intermediate page.  In  
Facelets you define your template in a page called / 
siteLayout.xhtml".  Then, if you have a page called "foobar" that  
extends the template, you directly invoke "/foobar.xhtml"  This page  
then "includes" the template.  Tiles requires the intermediate page  
because it works the other way around.  Instead of having pages that  
include templates, Tiles has definitions that extend templates and  
include pages.  I could give an example but it would just make this  
post a lot longer.


2)  The  tag is overloaded to mean too many things.   
 can be used to insert definitions, attributes, pages,  
strings, and probably scrambled eggs :-)  So when you see a  
 tag you need to look further to see what context it is  
in.  Is it trying to insert an attribute?  a definition?  We're  
trying to figure out the best way to address this issue.  It will  
probably mean different tags to do different things.


I hope that clears it up.
Thanks,
Greg

RE: Tiles Failure in GlassFish: org.apache.tiles.NoSuchDefinitionException

[Dick Starr]

Correction: Typo error in my example definition:

My example definition did not include slashes. I have used slashes
because navigation rules required them (although I seem to remember a
post saying that restriction has been removed - but I havn't tested
this) My example definition should be:


  


-Original Message-
From: Dick Starr 
Sent: Wednesday, October 11, 2006 8:42 AM
To: user@shale.apache.org
Subject: RE: Tiles Failure in GlassFish:
org.apache.tiles.NoSuchDefinitionException

I never did like the fact that my index.jsp couldn't just reference a
tile, but it was the only way I could make it work (all my other jsp's
could reference tiles). However, I have continued to upgrade to the
latest releases in the hopes of improving things, and I am now running
the 10/4/06 release of Shale.

My index.jsp now says  where
"systemLogon.faces" is a tile def as follows:


  


Dick

-Original Message-
From: Antonio Petrelli [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 11, 2006 6:50 AM
To: user@shale.apache.org
Subject: Re: Tiles Failure in GlassFish:
org.apache.tiles.NoSuchDefinitionException

Gregg Leichtman ha scritto:
> Sorry, I'm still confused as to how my original approach is different
> from Mr. Starr's. As far as I can see, he seems to be inserting tiles 
> in his /tiles/layouts/classicLayout _directly_ from the "puts" for
title
> and body, not from an extended definition wrapped around either the
> title or body. Is his approach correct because he is inserting from
> "puts" that are defined within an extended definition?
>   

No, it has nothing to do with extended definitions.
Again, your "index.jsp" pages says:

*snip*



*snap*

I suppose that siteLayout.faces points to siteLayout.jsp, right?
Ok, as far as I can see, your siteLayout.jsp is a layout page. A layout 
page is made of NOT FILLED attributes. You can fill them through the use

of definitions, as you did in:

*snip*












*snap*

But you forward to "siteLayout.faces" (that forwards to 
"siteLayout.jsp") that is used by "/mainLayout" definition. Instead you 
need to "forward" to the definition itself, not its layout page!
Therefore, prepare a JSP page containing:


HTH
Antonio

P.S.: I committed some code that corrects some misleading exception 
messages. Anyway to check it, you should download the source code from
SVN.

Re: clay and tomahawk's panelNavigation2 component

[Tomasz Pasierb]

Anyone?

Tomasz Pasierb napisał(a):

Hey Guys,

have anyone of you used Tomahawk's panelNavigation2 component with 
clay successfully? I put commandNavigation2 tags inside that render 
links. This is all static defined in a html component.


I'm actually having some problems with this.
I have the component defined in one of the tiles. It appears the 
component's state is not retrieved correctly after the action is 
invoked on the menu and a new page is loaded (defined as a clay 
component). The menu appears with all the menu options closed while it 
should render with all the options containing the one that was clicked 
opened. Additionally marking options (commandNavigation2) as disabled 
doesn't seem to have any effect.


I have tried this component without clay - basically I copied the jsp 
fragment to a "clean" myfaces application - and it works as expected. 
When the new view is rendered the last option clicked is highlighted 
as it should. Disabled options are rendered as text not links so this 
works fine here too.


The message I get from myfaces when invoking an action that loads a 
new view (when using clay) goes like this:


   INFO-WARNING: Component _id0 just got an automatic id, because there
   was no id assigned yet. If this component was created dynamically
   (i.e. not by a JSP tag) you should assign it an explicit static id
   or assign it the id you get from the createUniqueId from the current
   UIViewRoot component right after creation!

I guess clay renders or assigns this component a new id when a new 
view is invoked/rendered and that's why the state isn't retrieved 
correctly. Assigning ids statically (in jsp) to panelNavigation2 and 
all the commandNavigation2 components/elements doesn't help.


Is there any solution to this or is it a bug?

Regards,
Tom Pasierb

--
Jestes kierowca? To poczytaj! >>> http://link.interia.pl/f199e

Re: Shale and Hibernate integration example

[Craig McClanahan]

On 10/13/06, ying lcs <[EMAIL PROTECTED]> wrote:


Hi,
Is there any example for Shale and Hibernate integration?



We can't ship such a demo from Apache due to license incompatibility issues,
but there is a demo in the process of being built at the Shale Goodies
project on Google's project hosting site:

 http://code.google.com/p/shale-goodies/


Thank you.





Craig

Re: Tomahawk t:stylesheet component in Clay

[Ryan Wynn]

On 10/16/06, Hermod Opstvedt <[EMAIL PROTECTED]> wrote:

Hi

Since my 
does not work anymore, I thought I would give the Tomahawk t:stylesheet
component a try. However it does not seem to work properly:

In my Clay template .html file I have:




I think what you may want here instead is



I think the way you had it path was being interpreted as a symbol
(clay component has no such attribute) instead of a property.



But instead of rendering:

It renders:


Am I barking up the wrong tree here or is this maybe a bug in Clay or the
tomahawk-1.1.3.xml definition?

Hermod

Re: Shale Tiger - using module jars.

[Craig McClanahan]

On 10/23/06, Jason Vincent <[EMAIL PROTECTED]> wrote:


Hi all,

I'm interested in using Tiger to help configure some of my common
components that are shared across several web apps.

For every web app I've been creating, I have a common JAR file that is
included in the WAR when the web app is constructed.  This common JAR
comtains all the common validators and renderers that are shared.

I came across a statement in the Shale Tiger documentation that
mentioned that JARs included in the WAR would not be investigated
unless it had a faces-config.xml file in the META-INF directory of the
JAR.

Does this mean I can have more than one faces-config.xml file for the
same webapp? (one in the WAR file, configuring all the VC's and one in
the JAR file, configuring all the components).



Yes, you can indeed have multiple faces-config.xml files, including a
META-INF/faces-config.xml file in each JAR.  Even without the Tiger
extensions, this is a standard JSF feature ... you can register the elements
in that JAR file with the JSF runtime simply by having a
faces-config.xmlfile there.

If you look inside many of the Shale JARs, you will see such a
META-INF/faces-config.xml file to register resources that provide the
service that JAR provides, without the app having to register anything
explicitly.

 Is there a order of

preference that I should be wary about?



Unless you have two JARs registering the same resources, you should not have
to worry about the order in which things are loaded.

If I use Tiger for all my common components - I guess I can just put

an empty faces-config.xml in that included JAR to cause Shale to parse
the JAR - is that correct?



Yes, that's all it should take, except for one other thing ... be sure to
include the JAR files themselves in the WEB-INF/lib directory.  You'll be
tempted to put them in a shared directory provided by the servlet container
(such as common/lib or shared/lib in Tomcat), but the Tiger extensions (or
JSF, for that matter) do not check there.

Thanks all,

Jason



Craig

Re: Myfaces Sandbox ConversationTag & Clay possible?

[Craig McClanahan]

On 10/23/06, Torsten Krah <[EMAIL PROTECTED]> wrote:


Is this possible, or not needed when using the upcoming dialog2?



This is definitely something we should test, but I would not anticipate any
problems.

On the other hand, I have a nontrivial amount of discomfort with the fact
that ConversationTag (and even the SaveState tag, for that matter) require
the person writing your view pages to deal with these issues.  That seems
like something that ought to be limited to the person writing the
application logic -- only that person has a deep understanding of what state
needs to be saved, and for how long.  Especially when you get into
situations where you want to use the same view in more than one dialog ...

Btw ist 1.0.4 usable, especially the scxml dialog2?



From an API perspective, I think we're done (although a bit more testing

around browser navigation buttons is still needed).  From an implementation
point of view, the scxml implementation passes all the same tests that the
basic version does, which is a "good thing" :-).  But, because its
capabilities are different, I can't speak from personal experience to how
shaken out the underlying SCXML implementation stuff is.  Rahul should be
able to add some insights here.

Torsten




Craig

Re: Myfaces Sandbox ConversationTag & Clay possible?

[Rahul Akolkar]

On 10/23/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:

On 10/23/06, Torsten Krah <[EMAIL PROTECTED]> wrote:
>



> Btw ist 1.0.4 usable, especially the scxml dialog2?


From an API perspective, I think we're done (although a bit more testing
around browser navigation buttons is still needed).  From an implementation
point of view, the scxml implementation passes all the same tests that the
basic version does, which is a "good thing" :-).  But, because its
capabilities are different, I can't speak from personal experience to how
shaken out the underlying SCXML implementation stuff is.  Rahul should be
able to add some insights here.




Here is a pointer to the browser buttons bit [1], you should evaluate
the impact for your application.

The underlying Commons SCXML implementation is quite stable, folks
have been using the core bits (those that are used by
shale-dialog-scxml) for quite a while. The W3C specification may bring
changes since its not a Candidate Recommendation yet (its a Working
Draft), but the API will evolve in line with Commons standards, which
are quite high, so that risk is well mitigated, IMO. You will find
most of the details and a user guide on the Commons SCXML site [2],
the background for the Shale dialogs piece is here [3]. I'm hoping to
port some of that and then add some docs in this (currently empty)
space [4] later in the week.

All the things you can do with the basic impl can be done easily with
the SCXML impl (lone exception is if you've subclassed the object
model for the basic state machine impl, that might require some
thinking while porting).

Additionally, you get certain things for "free". Some examples:
* Closer UML2 semantics, crisp mapping to state chart diagrams
* Per state contexts (for scratch space workflow variables)
* Arbitrary expression evaluation (rather than just method binding)
in dialog definition
* Histories, for navigation of the style - go back to (the view)
where I was at some prior point

And thats without exposing any SCXML implementation specific APIs
(just using the shale-dialog abstraction APIs). Therefore, there is
value to starting new applications with the SCXML dialogs
implementation, rather than the basic one. Most basic dialog
definitions can just be styled into SCXML dialog definitions, so its
possible to move existing basic dialog definitions over fairly
quickly, if thats the decision.

At some point in the future, it makes sense to expose some of the
underlying Commons SCXML APIs (such as the actual SCXML execution
engine instance) via the (SCXML) DialogContext to developers. This
will add another set of features that will become available to
developers if they can be assured that the dialog implementation is
the SCXML impl -- which they should be if they choose it ;-) -- but
one step at a time.

-Rahul

[1] https://issues.apache.org/struts/browse/SHALE-61
[2] http://jakarta.apache.org/commons/scxml/
[3] http://jakarta.apache.org/commons/scxml/usecases/scxml-in-shale-dialogs.html
[4] http://shale.apache.org/shale-dialog-scxml/index.html



Torsten
>
>
Craig

Re: Myfaces Sandbox ConversationTag & Clay possible?

[Torsten Krah]

thx for your answers - i think i am going to evaluate 1.0.4 and its new
dialog implementation.

Torsten

Am Dienstag, den 24.10.2006, 01:48 -0400 schrieb Rahul Akolkar:
> On 10/23/06, Craig McClanahan <[EMAIL PROTECTED]> wrote:
> > On 10/23/06, Torsten Krah <[EMAIL PROTECTED]> wrote:
> > >
> 
> > > Btw ist 1.0.4 usable, especially the scxml dialog2?
> >
> >
> > From an API perspective, I think we're done (although a bit more testing
> > around browser navigation buttons is still needed).  From an implementation
> > point of view, the scxml implementation passes all the same tests that the
> > basic version does, which is a "good thing" :-).  But, because its
> > capabilities are different, I can't speak from personal experience to how
> > shaken out the underlying SCXML implementation stuff is.  Rahul should be
> > able to add some insights here.
> >
> 
> 
> Here is a pointer to the browser buttons bit [1], you should evaluate
> the impact for your application.
> 
> The underlying Commons SCXML implementation is quite stable, folks
> have been using the core bits (those that are used by
> shale-dialog-scxml) for quite a while. The W3C specification may bring
> changes since its not a Candidate Recommendation yet (its a Working
> Draft), but the API will evolve in line with Commons standards, which
> are quite high, so that risk is well mitigated, IMO. You will find
> most of the details and a user guide on the Commons SCXML site [2],
> the background for the Shale dialogs piece is here [3]. I'm hoping to
> port some of that and then add some docs in this (currently empty)
> space [4] later in the week.
> 
> All the things you can do with the basic impl can be done easily with
> the SCXML impl (lone exception is if you've subclassed the object
> model for the basic state machine impl, that might require some
> thinking while porting).
> 
> Additionally, you get certain things for "free". Some examples:
>  * Closer UML2 semantics, crisp mapping to state chart diagrams
>  * Per state contexts (for scratch space workflow variables)
>  * Arbitrary expression evaluation (rather than just method binding)
> in dialog definition
>  * Histories, for navigation of the style - go back to (the view)
> where I was at some prior point
> 
> And thats without exposing any SCXML implementation specific APIs
> (just using the shale-dialog abstraction APIs). Therefore, there is
> value to starting new applications with the SCXML dialogs
> implementation, rather than the basic one. Most basic dialog
> definitions can just be styled into SCXML dialog definitions, so its
> possible to move existing basic dialog definitions over fairly
> quickly, if thats the decision.
> 
> At some point in the future, it makes sense to expose some of the
> underlying Commons SCXML APIs (such as the actual SCXML execution
> engine instance) via the (SCXML) DialogContext to developers. This
> will add another set of features that will become available to
> developers if they can be assured that the dialog implementation is
> the SCXML impl -- which they should be if they choose it ;-) -- but
> one step at a time.
> 
> -Rahul
> 
> [1] https://issues.apache.org/struts/browse/SHALE-61
> [2] http://jakarta.apache.org/commons/scxml/
> [3] 
> http://jakarta.apache.org/commons/scxml/usecases/scxml-in-shale-dialogs.html
> [4] http://shale.apache.org/shale-dialog-scxml/index.html
> 
> 
> > Torsten
> > >
> > >
> > Craig
> >
> >

Re[2]: Problems with example war

[Thomas Walland]

I downloaded the war file from
http://people.apache.org/dist/shale/v1.0.3/shale-clay-usecases-1.0.3.zip and 
deployed it to my tomcat.

I also have windows xp, tomcat 5.5 and java 5 but it doesn't work.
Maybe I should try to check out the newest version from svn. But then
i have to build the source by my own?

Re[3]: Problems with example war

[Thomas Walland]

Because I don't want to build the source by my own, i tried also the
nightly build version of the example. But with the same result:

org.apache.jasper.JasperException: Exception in JSP: /welcome.jsp:1

1: 


Stacktrace:

org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:506)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:377)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

org.apache.shale.application.faces.ShaleApplicationFilter.doFilter(ShaleApplicationFilter.java:267)

root cause

javax.servlet.ServletException: Servlet.init() for servlet faces threw exception

org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java:688)

org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:658)
org.apache.jsp.welcome_jsp._jspService(welcome_jsp.java:43)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:334)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

org.apache.shale.application.faces.ShaleApplicationFilter.doFilter(ShaleApplicationFilter.java:267)

root cause

java.lang.IllegalStateException: No Factories configured for this Application. 
This happens if the faces-initialization does not work at all - make sure that 
you properly include all configuration settings necessary for a basic faces 
application and that all the necessary libs are included. Also check the 
logging output of your web application and your container for any exceptions!
If you did that and find nothing, the mistake might be due to the fact that you 
use some special web-containers which do not support registering 
context-listeners via TLD files and a context listener is not setup in your 
web.xml.
A typical config looks like this;

  
org.apache.myfaces.webapp.StartupServletContextListener


javax.faces.FactoryFinder.getFactory(FactoryFinder.java:90)
javax.faces.webapp.FacesServlet.init(FacesServlet.java:88)

org.apache.jasper.runtime.PageContextImpl.doForward(PageContextImpl.java:688)

org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:658)
org.apache.jsp.welcome_jsp._jspService(welcome_jsp.java:43)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:334)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

org.apache.shale.application.faces.ShaleApplicationFilter.doFilter(ShaleApplicationFilter.java:267)

Seems there is something wrong with the jsf-config or something? Do I
need something additional? Again, I have windows xp with java 1.5 and
tomcat 5.5. I don't have experience with jsf. Until now I have developed
struts-applications. But my next project should be realized with shale
because of the advantages.

Re[5]: Problems with example war

[Thomas Walland]

these are very strange errors. I've tried the following: If I copy the
jar-lib's from the war file to the commons/lib directory of tomcat, I
can start the webapp and see the first page of the example.

But I cannot click anything? If I click, i get other errors...

Re[6]: Problems with example war

[Thomas Walland]

I still have some troubles with shale. I found out that myfaces only
works, if i paste this to the web.xml:


   
   org.apache.myfaces.webapp.StartupServletContextListener
   


After that I get another error which looks like this:

javax.servlet.ServletException: ComponentConfigBean is not loaded.
javax.faces.webapp.FacesServlet.service(FacesServlet.java:121)

org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationFilter.java:268)

root cause

java.lang.NullPointerException: ComponentConfigBean is not loaded.
org.apache.shale.clay.component.Clay.getRootElement(Clay.java:266)
org.apache.shale.clay.component.Clay.encodeBegin(Clay.java:314)

org.apache.shale.clay.faces.ClayViewHandler.recursiveRender(ClayViewHandler.java:463)

org.apache.shale.clay.faces.ClayViewHandler.renderView(ClayViewHandler.java:394)

org.apache.shale.view.faces.ViewViewHandler.renderView(ViewViewHandler.java:151)

org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:352)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:107)

org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationFilter.java:268)

Could somebody tell me please what goes wrong with my configuration? I
just want to get the example war's started? Today I tried out an
simple example of myfaces. After pasting the listener above it works.

Thomas :-)

Re[8]: Problems with example war

[Thomas Walland]

I am sure, that tomcat 5.5 is running. I start the server on the
console with tomcat5.exe. When i do this, i get the following:

C:\Programme\Apache Software Foundation\Tomcat 5.5\bin>tomcat5.exe
30.10.2006 09:33:34 org.apache.catalina.core.AprLifecycleListener lifecycleEvent

INFO: The Apache Tomcat Native library which allows optimal performance in produ
ction environments was not found on the java.library.path: C:\Programme\Apache S
oftware Foundation\Tomcat 5.5\bin;.;C:\WINDOWS\system32;C:\WINDOWS;C:\Programme\
MiKTeX 2.5\miktex\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:
\Programme\Gemeinsame Dateien\GTK\2.0\bin;C:\Programme\OpenVPN\bin
30.10.2006 09:33:34 org.apache.coyote.http11.Http11BaseProtocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
30.10.2006 09:33:34 org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 951 ms
30.10.2006 09:33:34 org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
30.10.2006 09:33:34 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.5.20
30.10.2006 09:33:34 org.apache.catalina.core.StandardHost start
INFO: XML validation disabled
30.10.2006 09:33:35 org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive shale-clay-usecases.war
log4j:WARN No appenders could be found for logger (org.apache.commons.digester.D
igester.sax).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN No appenders could be found for logger (org.apache.commons.digester.D
igester.sax).
log4j:WARN Please initialize the log4j system properly.
30.10.2006 09:33:43 org.apache.coyote.http11.Http11BaseProtocol start
INFO: Starting Coyote HTTP/1.1 on http-8080
30.10.2006 09:33:43 org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
30.10.2006 09:33:43 org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/70  config=null
30.10.2006 09:33:43 org.apache.catalina.storeconfig.StoreLoader load
INFO: Find registry server-registry.xml at classpath resource
30.10.2006 09:33:43 org.apache.catalina.startup.Catalina start
INFO: Server startup in 9113 ms


CATALINA_HOME is set to the C:\Prog\Tomcat 5.5\. Also JAVA_HOME
points to my java folder.

Thomas

Re[10]: Problems with example war

[Thomas Walland]

I solved the problem!

I don't know if this is only a problem on my machine. I used a german
windows xp professional edition and installed tomcat in de suggested
default path unter c:\programms\apache software foundation\tomcat
5.5\...

Seems this is a too long name for shale or something other or some
part of the framework or something other is not able to handle blanks
in directory names.

Now i have reinstalled tomcat under c:\tomcat55. A very short
directory name without blanks. After putting the war to this directory
and starting the server the example works well.

maybe this is only a problem with windows users or with german windows
users? i don't know. But the default path to install doesn't work
well.

Thank's for your help :-)

Thomas

Re: New to shale and jsf

[Craig McClanahan]

On 11/1/06, Jonathan Smith <[EMAIL PROTECTED]> wrote:



Hi I am new to shale and JSFI was wondering if there was a shale example
in
which a list get iterated through and displayed. like a list of employees
or
items in a store, something like that. Or if there is a JSF or shale
component that can display a list or objects. Like if you have a list of
employee objects and each employee has a name, and personel info. any help
or examples are warmly welcome.



The most likely suspect component :-) for you is the Data Table component
( if you are using JSP).  You can see this used, among other
places, in the"shale-mailreader"  example apps ... on the
registration.jsppage, the set of subscriptions for a logged in user is
listed in such at
table.

Version 1.0.3 is available at http://people.apache.org/dist/shale/v1.0.3/ or
you can grab the latest nightly builds (
http://people.apache.org/builds/shale/nightly/).

Craig



_

Try the next generation of search with Windows Live Search today!

http://imagine-windowslive.com/minisites/searchlaunch/?locale=en-us&source=hmtagline

Re: New to shale and jsf

[Matthias Wessendorf]

Jonathan-

the Shale framework is more an extension of JSF. JSF++ I'd like to call it :)

The best is the ViewController, check the use case for that. Also
sweet is the remoting, the tiger and the testing-support. Dialog is
also in there. Enable you to do *wizards* based on a xml conf.

(these things I used; I can't speak about Clay for instance)

One last thing. even you don't need ajax(shale remoting), dialogs,
tests or Java5 [EMAIL PROTECTED] or test. but you really want
ViewController ;)

-M

On 11/1/06, Jonathan Smith <[EMAIL PROTECTED]> wrote:


Hi I am new to shale and JSFI was wondering if there was a shale example in
which a list get iterated through and displayed. like a list of employees or
items in a store, something like that. Or if there is a JSF or shale
component that can display a list or objects. Like if you have a list of
employee objects and each employee has a name, and personel info. any help
or examples are warmly welcome.

_
Try the next generation of search with Windows Live Search today!
http://imagine-windowslive.com/minisites/searchlaunch/?locale=en-us&source=hmtagline





--
Matthias Wessendorf
http://tinyurl.com/fmywh

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: Not really a Shale-Problem...

[Craig McClanahan]

On 11/6/06, Thomas Walland <[EMAIL PROTECTED]> wrote:


Sorry for that mail, but I have a questions which belongs not really
to shale.

Maybe someone of you can help me?

I want to declare a link with the xlink-specification of the W3C but
it doesn't work, like I want it to work.

What I want to do is the following:

bar

I want to open a resource in a frame called "foo". I tried several
ways to get this kind of link defined with xlink, but nothing worked.

The link is always opened in "_self" and not in "foo".

Maybe someone of you could tell me how to define such a link with
xlink or could tell me where to find more information. I googled
around, but I didn't really find a solution for this problem.

Thanks a lot and excuse me for this "non-shale"-qestion :-)



With the standard JSF components,  should be able to do what
you want, with one small tweak:

   

This component takes its label content (the part that is underlined) from
component children inside ... so I converted that to be output by a
component instead of being literal text.

Thomas




Craig

Re: [scxml] dialog not found problem

[Torsten Krah]

Hm seconds after posting it and reading the configs xx times i saw the
change in dialog-config.xml, its not any longer , but
 , thx to me ;)

Torsten

Am Dienstag, den 07.11.2006, 17:08 +0100 schrieb Torsten Krah:
> Got it working once, but now i don't find out whats going wrong since
> i've changed some dialog configs, the log says:
> 
>  WARN http-8080-Processor25
> org.apache.shale.dialog.scxml.SCXMLDialogManager - No dialog
> configuration information present.  No default configuration found
> at: /WEB-INF/dialog-config.xml.  No embedded configuration found at:
> META-INF/dialog-config.xml
>  ERROR http-8080-Processor25
> org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/app] -
> No definition for dialog name 'newadmin' can be found
> 
> 
> web.xml:
> 
>   
>   
> org.apache.shale.dialog.scxml.CONFIGURATION
>   /WEB-INF/dialog-config.xml
>   
> 
> dialog-config.xml:
> 
> 
>  dataclassname="my.app.jsf.beans.UserBeanWrapper" />
> 
> 
> What did i miss?
> 
> A dialog-config.xml is there, a dialog named newadmin too - why does the
> manager does not find it? Any ideas?
> 
> Torsten


smime.p7s
Description: S/MIME cryptographic signature

Re: [scxml] dialog not found problem

[Rahul Akolkar]

On 11/7/06, Torsten Krah <[EMAIL PROTECTED]> wrote:

Hm seconds after posting it and reading the configs xx times i saw the
change in dialog-config.xml, its not any longer , but
 , thx to me ;)




Sorry, I changed the root element. I try to update the site
documentation whenever I make any changes (that should matter to
others) so please look at:

http://shale.apache.org/shale-dialog-scxml/

if you suspect that is the case (I don't really expect to make any
changes that might break existing configs anymore, but until this
module is released, its not set in stone).

A comment below:



Torsten

Am Dienstag, den 07.11.2006, 17:08 +0100 schrieb Torsten Krah:
> Got it working once, but now i don't find out whats going wrong since
> i've changed some dialog configs, the log says:
>
>  WARN http-8080-Processor25
> org.apache.shale.dialog.scxml.SCXMLDialogManager - No dialog
> configuration information present.  No default configuration found
> at: /WEB-INF/dialog-config.xml.  No embedded configuration found at:
> META-INF/dialog-config.xml
>  ERROR http-8080-Processor25
> org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/app] -
> No definition for dialog name 'newadmin' can be found
>
>
> web.xml:
>
>   
>   
org.apache.shale.dialog.scxml.CONFIGURATION
>   /WEB-INF/dialog-config.xml
>   
>



If you're using the canonical name of the dialog config file, which
you are here, then you can leave out the web.xml clutter, the dialog
manager will check there in any case.

-Rahul



> dialog-config.xml:
>
> 
>  dataclassname="my.app.jsf.beans.UserBeanWrapper" />
> 
>
> What did i miss?
>
> A dialog-config.xml is there, a dialog named newadmin too - why does the
> manager does not find it? Any ideas?
>
> Torsten

Re: [scxml] dialog not found problem

[Rahul Akolkar]

On 11/7/06, Hermod Opstvedt <[EMAIL PROTECTED]> wrote:

Hi

Should it not be: WEB-INF/dialog-config.xml? (Note the missing leading
slash)




Thats fine. Its doing a ExternalContext#getResource(String) under the
hood, and the leading slash is needed (things are relative to current
context root).

-Rahul



Hermod

Re: s:token tag as last component.

[Craig McClanahan]

On 11/9/06, Jason Vincent <[EMAIL PROTECTED]> wrote:


Hi all,

I've read that the s:token tag must now be the last component in the
form's child compnents.
I was hoping that perhaps there is an autmatic way to get all forms to
use the token tag, without me having to remember to put in the page
source as the last component.

I tried a FormRenderer class that extends the JSF FormRenderer that
attempted to add a Token component as the last child of the form.  It
didn't work - probably since the calling class has already established
the list of components to render without expecting to have new ones
appened.



It's likely that the issue here was actually the saved state of the
component tree, which has to be calculated BEFORE the page is actually
rendered so that it can be emitted (by the form component) as a hidden
variable if you're using client side state saving.

Any ideas?

Perhaps a s:form tag that has a singleSubmit=true attribute?
Some other way to insert a component in a tree that has already
started to render?



Interesting idea ... and the default should probably be to emit the token by
default, because otherwise there'd be no reason to use the special form
component.

In Shale, we're trying to stay away from becoming yet another library of
visual JSF components; rather, the only components we should have are those
that integrate framework features (like the token, and validators).  Seems
like this would qualify on that standard :-).

In a JSF 1.2 environment, we could put this kind of functionality (add a
token component if necessary) into the createView() method of ViewHandler,
since the entire component tree will have been precreated and we could just
scan for components that are "instanceof UIForm".  Alas, that doesn't work
for 1.1 environments where you're using JSP, since the component tree is
built on the fly.  So, a specialized form component sounds like a reasonable
alternative in the short run.

I've added a new JIRA issue[1] to track this RFE.  Thanks for the
suggestion!

Thanks,

Jason



Craig

[1] https://issues.apache.org/struts/browse/SHALE-329

Re: Tiger extension - beans/views ignored

[Torsten Krah]

To be more exact, the corresponding jar file got the faces-config.xml in
meta-inf:

10-Nov-2006 16:07:07 PM [INFO]
(FacesConfigurator.java:feedClassloaderConfigurations:250) Reading
config
jar:file:/home/tkrah/Development/bin/app/WEB-INF/lib/app-dev.jar!/META-INF/faces-config.xml

Tiger installed its variable resolver:

10-Nov-2006 16:07:08 PM [INFO] (VariableResolverImpl.java::102)
Installed the Tiger VariableResolverImpl wrapping original instance
[EMAIL PROTECTED]

But my beans which are annotated and in app-dev.jar are ignored.

Torsten

ps: i am using clay for the view part, shouldn't matter.

Am Freitag, den 10.11.2006, 15:44 +0100 schrieb Torsten Krah:
> I put an empty faces-config.xml in my app/META-INF directory.
> The annotated classes are in a jar file which is in app/WEB-INF/lib .
> This should be enough to make my annotations work with tiger - right?
> 
> However - all my definitions does not work, something i've missed or can
> do to debug this?
> I am using tomcat6, myfaces 1.1.4, shale 1.0.4 current svn snapshot.
> 
> Torsten


smime.p7s
Description: S/MIME cryptographic signature

Re: Tiger extension - beans/views ignored

[Craig McClanahan]

On 11/10/06, Torsten Krah <[EMAIL PROTECTED]> wrote:


I put an empty faces-config.xml in my app/META-INF directory.
The annotated classes are in a jar file which is in app/WEB-INF/lib .
This should be enough to make my annotations work with tiger - right?



The empty faces-config.xml needs to be in the META-INF directory of the jar
file itself, not at the application level.

Craig

However - all my definitions does not work, something i've missed or can

do to debug this?
I am using tomcat6, myfaces 1.1.4, shale 1.0.4 current svn snapshot.

Torsten

Re: Tiger extension - beans/views ignored

[Torsten Krah]

Yeah, noticed that in my anser to myself - i have the xml file in the
jar file itself, look at the answer to myself. However its not working.

Torsten

Am Freitag, den 10.11.2006, 10:53 -0800 schrieb Craig McClanahan:
> On 11/10/06, Torsten Krah <[EMAIL PROTECTED]> wrote:
> >
> > I put an empty faces-config.xml in my app/META-INF directory.
> > The annotated classes are in a jar file which is in app/WEB-INF/lib .
> > This should be enough to make my annotations work with tiger - right?
> 
> 
> The empty faces-config.xml needs to be in the META-INF directory of the jar
> file itself, not at the application level.
> 
> Craig
> 
> However - all my definitions does not work, something i've missed or can
> > do to debug this?
> > I am using tomcat6, myfaces 1.1.4, shale 1.0.4 current svn snapshot.
> >
> > Torsten
> >
> >
> >


smime.p7s
Description: S/MIME cryptographic signature

Re: Tiger extension - beans/views ignored

[Craig McClanahan]

On 11/12/06, Torsten Krah <[EMAIL PROTECTED]> wrote:


Yeah, noticed that in my anser to myself - i have the xml file in the
jar file itself, look at the answer to myself. However its not working.



Does the shale-sql-browser sample app work for you?  It requires the
annotations in order to succeed (try "SELECT * FROM ZIP_CODES").  There is
also a unit test application (shale-test-tiger) you can try if you are
building from source.

Torsten


Craig

Am Freitag, den 10.11.2006, 10:53 -0800 schrieb Craig McClanahan:

> On 11/10/06, Torsten Krah <[EMAIL PROTECTED]> wrote:
> >
> > I put an empty faces-config.xml in my app/META-INF directory.
> > The annotated classes are in a jar file which is in app/WEB-INF/lib .
> > This should be enough to make my annotations work with tiger - right?
>
>
> The empty faces-config.xml needs to be in the META-INF directory of the
jar
> file itself, not at the application level.
>
> Craig
>
> However - all my definitions does not work, something i've missed or can
> > do to debug this?
> > I am using tomcat6, myfaces 1.1.4, shale 1.0.4 current svn snapshot.
> >
> > Torsten
> >
> >
> >

Re: Tiger extension - beans/views ignored

[Torsten Krah]

Build and using tiger already from sources, so it should work. The sql
app cannot be tested yet because 56k modem is too slow to download
things, i'll test tomorrow.

Am Sonntag, den 12.11.2006, 07:53 -0800 schrieb Craig McClanahan:
> On 11/12/06, Torsten Krah <[EMAIL PROTECTED]> wrote:
> >
> > Yeah, noticed that in my anser to myself - i have the xml file in the
> > jar file itself, look at the answer to myself. However its not working.
> 
> 
> Does the shale-sql-browser sample app work for you?  It requires the
> annotations in order to succeed (try "SELECT * FROM ZIP_CODES").  There is
> also a unit test application (shale-test-tiger) you can try if you are
> building from source.
> 
> Torsten
> 
> 
> Craig
> 
> Am Freitag, den 10.11.2006, 10:53 -0800 schrieb Craig McClanahan:
> > > On 11/10/06, Torsten Krah <[EMAIL PROTECTED]> wrote:
> > > >
> > > > I put an empty faces-config.xml in my app/META-INF directory.
> > > > The annotated classes are in a jar file which is in app/WEB-INF/lib .
> > > > This should be enough to make my annotations work with tiger - right?
> > >
> > >
> > > The empty faces-config.xml needs to be in the META-INF directory of the
> > jar
> > > file itself, not at the application level.
> > >
> > > Craig
> > >
> > > However - all my definitions does not work, something i've missed or can
> > > > do to debug this?
> > > > I am using tomcat6, myfaces 1.1.4, shale 1.0.4 current svn snapshot.
> > > >
> > > > Torsten
> > > >
> > > >
> > > >
> >
> >
> >


smime.p7s
Description: S/MIME cryptographic signature

Re: Tiger extension - beans/views ignored

[Torsten Krah]

Ok works now - ant screwed all up :-(, but now it works - sorry for the
noise.

Torsten

Am Sonntag, den 12.11.2006, 19:35 +0100 schrieb Torsten Krah:
> Build and using tiger already from sources, so it should work. The sql
> app cannot be tested yet because 56k modem is too slow to download
> things, i'll test tomorrow.
> 
> Am Sonntag, den 12.11.2006, 07:53 -0800 schrieb Craig McClanahan:
> > On 11/12/06, Torsten Krah <[EMAIL PROTECTED]> wrote:
> > >
> > > Yeah, noticed that in my anser to myself - i have the xml file in the
> > > jar file itself, look at the answer to myself. However its not working.
> > 
> > 
> > Does the shale-sql-browser sample app work for you?  It requires the
> > annotations in order to succeed (try "SELECT * FROM ZIP_CODES").  There is
> > also a unit test application (shale-test-tiger) you can try if you are
> > building from source.
> > 
> > Torsten
> > 
> > 
> > Craig
> > 
> > Am Freitag, den 10.11.2006, 10:53 -0800 schrieb Craig McClanahan:
> > > > On 11/10/06, Torsten Krah <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > I put an empty faces-config.xml in my app/META-INF directory.
> > > > > The annotated classes are in a jar file which is in app/WEB-INF/lib .
> > > > > This should be enough to make my annotations work with tiger - right?
> > > >
> > > >
> > > > The empty faces-config.xml needs to be in the META-INF directory of the
> > > jar
> > > > file itself, not at the application level.
> > > >
> > > > Craig
> > > >
> > > > However - all my definitions does not work, something i've missed or can
> > > > > do to debug this?
> > > > > I am using tomcat6, myfaces 1.1.4, shale 1.0.4 current svn snapshot.
> > > > >
> > > > > Torsten
> > > > >
> > > > >
> > > > >
> > >
> > >
> > >


smime.p7s
Description: S/MIME cryptographic signature

Re: Cannot subscribe to the list

[Wendy Smoak]

On 11/12/06, Adrian Mitev <[EMAIL PROTECTED]> wrote:

Hi! i`m trying to subscribe to the user@shale.apache.org but i got as reply
the following:

Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 12): 552 spam score (5.5) exceeded threshold


Was the message completely empty?  Try putting something in the
subject line and/or body.  We've seen other reports of SpamAssassin
filtering blank messages.

--
Wendy

Re: Cannot subscribe to the list

[James Mitchell]

Sending as HTML also helps to boost the score up on the spam scale,  
be sure you send as text.



--
James Mitchell
678.910.8017




On Nov 12, 2006, at 7:23 PM, Wendy Smoak wrote:


On 11/12/06, Adrian Mitev <[EMAIL PROTECTED]> wrote:
Hi! i`m trying to subscribe to the user@shale.apache.org but i got  
as reply

the following:

Technical details of permanent failure:
PERM_FAILURE: SMTP Error (state 12): 552 spam score (5.5) exceeded  
threshold


Was the message completely empty?  Try putting something in the
subject line and/or body.  We've seen other reports of SpamAssassin
filtering blank messages.

--
Wendy

Re: This Shale/Tiles configuration works

[Alarc]

Hi, I am interested to discuss new features to a
future version of Shale and I would like to know if
there is interest on discussing them; if so, please
reply.

Meanwhile, I am writing down the details.

Un abrazo,
Vladimir.

PS: Sorry for my english :(

--- Dick Starr <[EMAIL PROTECTED]> wrote:

> I have been trying to get my Tiles app working with
> the current Shale release (thanks Craig and Greg for
> your help), and am currently working with the
> shale-framework-20061116 jars. My running version
> used only the shale-framework-20061004 jars. I have
> discovered that I can use the 20061116 shale-tiles
> and tiles-core with the 20061004 Shale release, and
> have successfully implemented the Tiles 2 FAQ
> changes.
> 
> Once I replace my 20061004 shale-xxx jars (except
> for the two newer Tiles jars) with the 20061116 jars
> my app fails like before with this log data:
> 
> INFO: Undeploying context [/starraShale]
> log4j:WARN No appenders could be found for logger
> (org.apache.commons.digester.Digester.sax).
> log4j:WARN Please initialize the log4j system
> properly.
> Nov 17, 2006 10:14:26 AM
> org.apache.tiles.listener.TilesListener
> contextInitialized
> INFO: Initializing TilesListener
> Nov 17, 2006 10:14:26 AM
> org.apache.tiles.listener.TilesListener
> readFactoryConfig
> INFO: CONFIG FILES DEFINED IN WEB.XML
> Nov 17, 2006 10:14:26 AM
> org.apache.tiles.listener.TilesListener
> initDefinitionsFactory
> INFO: initializing definitions factory...
> SaInitializer.contextInitialized
> Nov 17, 2006 10:14:26 AM
> org.apache.catalina.core.StandardContext start
> SEVERE: Error filterStart
> Nov 17, 2006 10:14:26 AM
> org.apache.catalina.core.StandardContext start
> SEVERE: Context [/starraShale] startup failed due to
> previous errors
> 
> My log4j is as follows:
> 
> log4j.debug=true
> log4j.appender.C1=org.apache.log4j.ConsoleAppender
> log4j.appender.C1.Threshold=DEBUG
>
log4j.appender.C1.layout=org.apache.log4j.PatternLayout
> log4j.appender.C1.layout.ConversionPattern=%d - %p
> %c - %m%n
> log4j.rootLogger=DEBUG, C1# test
> log4j.logger.com.ibatis=DEBUG, C1
> log4j.logger.java.sql=DEBUG, C1
>
log4j.logger.org.apache.commons.digester.Digester.sax=DEBUG,
> C1
> log4j.logger.org.apache.shale=DEBUG, C1
> log4j.logger.org.apache.catalina.core=DEBUG, C1
> log4j.logger.org.apache.jasper.compiler=DEBUG, C1
> log4j.logger.com.starrcs=TRACE, C1
> 
> As a test I reduced my shale lib jars to shale-core,
> shale-tiles, and tiles-core. This configuration
> works with the 20061004 jars (i.e. deploys and
> displays my first view) but fails with the
> corresponding three 20061116 jars. I realize that I
> may need more shale jars with the later release as
> the work seems to be distributed differently within
> the jars, but I was wanting to make the test as
> simple as possible (note from above that it also
> fails with the full set of 20061116 shale jars).
> 
> Bottom line seems to be that you can get away with
> using the latest shale-tiles and tiles-core with an
> earlier release of Shale. I never like mixing
> releases, but it is working for me - and I want to
> test the latest Tiles.
> 
> If anyone has the latest Shale/Tiles working please
> post what Shale/Tiles version you are using, and I
> will try it.
> 
> Thanks,
> 
> Dick
> 
> 
> 



 

Sponsored Link

Mortgage rates near 39yr lows. 
$420k for $1,399/mo. Calculate new payment! 
www.LowerMyBills.com/lre

Re: This Shale/Tiles configuration works

[Wendy Smoak]

On 11/18/06, Alarcón Vladimir <[EMAIL PROTECTED]> wrote:


Hi, I am interested to discuss new features to a
future version of Shale and I would like to know if
there is interest on discussing them; if so, please
reply.


Sure!  The best way would be to start a new thread on the mailing list
and use a descriptive subject line.  (Here, you've replied to an
unrelated thread about Tiles.)

And your English is fine. :)

--
Wendy

RE: This Shale/Tiles configuration works

[mario.buonopane]

I'm very interested!

-Original Message-
From: Alarcón" Vladimir [mailto:[EMAIL PROTECTED] 
Sent: 18 novembre 2006 18.00
To: user@shale.apache.org
Subject: Re: This Shale/Tiles configuration works

Hi, I am interested to discuss new features to a
future version of Shale and I would like to know if
there is interest on discussing them; if so, please
reply.

Meanwhile, I am writing down the details.

Un abrazo,
Vladimir.

PS: Sorry for my english :(

--- Dick Starr <[EMAIL PROTECTED]> wrote:

> I have been trying to get my Tiles app working with
> the current Shale release (thanks Craig and Greg for
> your help), and am currently working with the
> shale-framework-20061116 jars. My running version
> used only the shale-framework-20061004 jars. I have
> discovered that I can use the 20061116 shale-tiles
> and tiles-core with the 20061004 Shale release, and
> have successfully implemented the Tiles 2 FAQ
> changes.
> 
> Once I replace my 20061004 shale-xxx jars (except
> for the two newer Tiles jars) with the 20061116 jars
> my app fails like before with this log data:
> 
> INFO: Undeploying context [/starraShale]
> log4j:WARN No appenders could be found for logger
> (org.apache.commons.digester.Digester.sax).
> log4j:WARN Please initialize the log4j system
> properly.
> Nov 17, 2006 10:14:26 AM
> org.apache.tiles.listener.TilesListener
> contextInitialized
> INFO: Initializing TilesListener
> Nov 17, 2006 10:14:26 AM
> org.apache.tiles.listener.TilesListener
> readFactoryConfig
> INFO: CONFIG FILES DEFINED IN WEB.XML
> Nov 17, 2006 10:14:26 AM
> org.apache.tiles.listener.TilesListener
> initDefinitionsFactory
> INFO: initializing definitions factory...
> SaInitializer.contextInitialized
> Nov 17, 2006 10:14:26 AM
> org.apache.catalina.core.StandardContext start
> SEVERE: Error filterStart
> Nov 17, 2006 10:14:26 AM
> org.apache.catalina.core.StandardContext start
> SEVERE: Context [/starraShale] startup failed due to
> previous errors
> 
> My log4j is as follows:
> 
> log4j.debug=true
> log4j.appender.C1=org.apache.log4j.ConsoleAppender
> log4j.appender.C1.Threshold=DEBUG
>
log4j.appender.C1.layout=org.apache.log4j.PatternLayout
> log4j.appender.C1.layout.ConversionPattern=%d - %p
> %c - %m%n
> log4j.rootLogger=DEBUG, C1# test
> log4j.logger.com.ibatis=DEBUG, C1
> log4j.logger.java.sql=DEBUG, C1
>
log4j.logger.org.apache.commons.digester.Digester.sax=DEBUG,
> C1
> log4j.logger.org.apache.shale=DEBUG, C1
> log4j.logger.org.apache.catalina.core=DEBUG, C1
> log4j.logger.org.apache.jasper.compiler=DEBUG, C1
> log4j.logger.com.starrcs=TRACE, C1
> 
> As a test I reduced my shale lib jars to shale-core,
> shale-tiles, and tiles-core. This configuration
> works with the 20061004 jars (i.e. deploys and
> displays my first view) but fails with the
> corresponding three 20061116 jars. I realize that I
> may need more shale jars with the later release as
> the work seems to be distributed differently within
> the jars, but I was wanting to make the test as
> simple as possible (note from above that it also
> fails with the full set of 20061116 shale jars).
> 
> Bottom line seems to be that you can get away with
> using the latest shale-tiles and tiles-core with an
> earlier release of Shale. I never like mixing
> releases, but it is working for me - and I want to
> test the latest Tiles.
> 
> If anyone has the latest Shale/Tiles working please
> post what Shale/Tiles version you are using, and I
> will try it.
> 
> Thanks,
> 
> Dick
> 
> 
> 



 

Sponsored Link

Mortgage rates near 39yr lows. 
$420k for $1,399/mo. Calculate new payment! 
www.LowerMyBills.com/lre


This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information.  If you have received it in 
error, please notify the sender immediately and delete the original.  Any other 
use of the email by you is prohibited.

RE: This Shale/Tiles configuration works

[Alarc]

Hi, I posted 2 new features for discussion. I am
working alone here, here, here...  

So, feel free to say if these features are found
useful or not.

Thanks,
Vladimir.

--- [EMAIL PROTECTED] wrote:

> I'm very interested!
> 
> -Original Message-
> From: Alarcón" Vladimir
> [mailto:[EMAIL PROTECTED] 
> Sent: 18 novembre 2006 18.00
> To: user@shale.apache.org
> Subject: Re: This Shale/Tiles configuration works
> 
> Hi, I am interested to discuss new features to a
> future version of Shale and I would like to know if
> there is interest on discussing them; if so, please
> reply.
> 
> Meanwhile, I am writing down the details.
> 
> Un abrazo,
> Vladimir.
> 
> PS: Sorry for my english :(
> 
> --- Dick Starr <[EMAIL PROTECTED]> wrote:
> 
> > I have been trying to get my Tiles app working
> with
> > the current Shale release (thanks Craig and Greg
> for
> > your help), and am currently working with the
> > shale-framework-20061116 jars. My running version
> > used only the shale-framework-20061004 jars. I
> have
> > discovered that I can use the 20061116 shale-tiles
> > and tiles-core with the 20061004 Shale release,
> and
> > have successfully implemented the Tiles 2 FAQ
> > changes.
> > 
> > Once I replace my 20061004 shale-xxx jars (except
> > for the two newer Tiles jars) with the 20061116
> jars
> > my app fails like before with this log data:
> > 
> > INFO: Undeploying context [/starraShale]
> > log4j:WARN No appenders could be found for logger
> > (org.apache.commons.digester.Digester.sax).
> > log4j:WARN Please initialize the log4j system
> > properly.
> > Nov 17, 2006 10:14:26 AM
> > org.apache.tiles.listener.TilesListener
> > contextInitialized
> > INFO: Initializing TilesListener
> > Nov 17, 2006 10:14:26 AM
> > org.apache.tiles.listener.TilesListener
> > readFactoryConfig
> > INFO: CONFIG FILES DEFINED IN WEB.XML
> > Nov 17, 2006 10:14:26 AM
> > org.apache.tiles.listener.TilesListener
> > initDefinitionsFactory
> > INFO: initializing definitions factory...
> > SaInitializer.contextInitialized
> > Nov 17, 2006 10:14:26 AM
> > org.apache.catalina.core.StandardContext start
> > SEVERE: Error filterStart
> > Nov 17, 2006 10:14:26 AM
> > org.apache.catalina.core.StandardContext start
> > SEVERE: Context [/starraShale] startup failed due
> to
> > previous errors
> > 
> > My log4j is as follows:
> > 
> > log4j.debug=true
> > log4j.appender.C1=org.apache.log4j.ConsoleAppender
> > log4j.appender.C1.Threshold=DEBUG
> >
>
log4j.appender.C1.layout=org.apache.log4j.PatternLayout
> > log4j.appender.C1.layout.ConversionPattern=%d - %p
> > %c - %m%n
> > log4j.rootLogger=DEBUG, C1# test
> > log4j.logger.com.ibatis=DEBUG, C1
> > log4j.logger.java.sql=DEBUG, C1
> >
>
log4j.logger.org.apache.commons.digester.Digester.sax=DEBUG,
> > C1
> > log4j.logger.org.apache.shale=DEBUG, C1
> > log4j.logger.org.apache.catalina.core=DEBUG, C1
> > log4j.logger.org.apache.jasper.compiler=DEBUG, C1
> > log4j.logger.com.starrcs=TRACE, C1
> > 
> > As a test I reduced my shale lib jars to
> shale-core,
> > shale-tiles, and tiles-core. This configuration
> > works with the 20061004 jars (i.e. deploys and
> > displays my first view) but fails with the
> > corresponding three 20061116 jars. I realize that
> I
> > may need more shale jars with the later release as
> > the work seems to be distributed differently
> within
> > the jars, but I was wanting to make the test as
> > simple as possible (note from above that it also
> > fails with the full set of 20061116 shale jars).
> > 
> > Bottom line seems to be that you can get away with
> > using the latest shale-tiles and tiles-core with
> an
> > earlier release of Shale. I never like mixing
> > releases, but it is working for me - and I want to
> > test the latest Tiles.
> > 
> > If anyone has the latest Shale/Tiles working
> please
> > post what Shale/Tiles version you are using, and I
> > will try it.
> > 
> > Thanks,
> > 
> > Dick
> > 
> > 
> > 
> 
> 
> 
>  
>

> Sponsored Link
> 
> Mortgage rates near 39yr lows. 
> $420k for $1,399/mo. Calculate new payment! 
> www.LowerMyBills.com/lre
> 
> 
> This message is for the designated recipient only
> and may contain privileged, proprietary, or
> otherwise private information.  If you have received
> it in error, please notify the sender immediately
> and delete the original.  Any other use of the email
> by you is prohibited.
> 



 

Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

Re: Dependency with MyFaces in 1.0.3

[Wendy Smoak]

On 11/24/06, Enrique Medina Montenegro <[EMAIL PROTECTED]> wrote:


I found an annoying dependency (for my project) inside the pom.xml in the
META-INF folder that makes reference to MyFaces 1.1.1. My problem is I end
up by having both those JARs and 1.1.2, which are the real ones I want in my
application.


Unfortunately, you'll need to use  in your own project's
pom to get rid of the unwanted dependencies.

(The MyFaces dependencies are now marked 'provided' so that this won't
be a problem in future Shale releases.)

--
Wendy

Re: Dependency with MyFaces in 1.0.3

[Enrique Medina Montenegro]

Ok, thanks Wendy. Also a dependency with myfaces 1.1.0 is being downloaded
from commons-chain...

On 11/24/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:


On 11/24/06, Enrique Medina Montenegro <[EMAIL PROTECTED]> wrote:

> I found an annoying dependency (for my project) inside the pom.xml in
the
> META-INF folder that makes reference to MyFaces 1.1.1. My problem is I
end
> up by having both those JARs and 1.1.2, which are the real ones I want
in my
> application.

Unfortunately, you'll need to use  in your own project's
pom to get rid of the unwanted dependencies.

(The MyFaces dependencies are now marked 'provided' so that this won't
be a problem in future Shale releases.)

--
Wendy

Re: SV: Clay, Tomahawk and jscookmenu

[Gary VanMatre]

>From: Hermod Opstvedt <[EMAIL PROTECTED]> 
>
> Hi 
> 
> Your assumptions are correct. As I stated in my first mail, I had to do some 
> tweaks. In the jscookmenu that comes with tomahawk 1.3 there are some coding 
> errors/presumptions that need to be worked around. Mainly, assumptions about 
> where pages are situated relative to the jscookmenu stuff. That is why I 
> grabbed the script from the originators of jscookmenu and used that script 
> instead (Also had to alter some hardcoded stuff in there). 
> 
> I have not had the time to look into 1.5 of Tomahawk yet to see if that 
> version works better that the 1.3 version, but I have it on my agenda to do 
> so during the upcomming holidays. If there are issues related to Clay, I 
> will try to identify and rectify them. 
> 

 
That sounds awesome.  We sure could use the help identifying Clay/Tomahawk
issues or any component library.

I recently started the Clay/Trinidad project in the sandbox and I'm pretty happy
with the compatibility.  It uses Hermod's maven plugin to build the Clay configs
from the TLD.  

I think the best course of action is to create maven archetype's to setup a 
projects with the extra Clay bits.  This way they don't add 
another dependency to their build and we (Shale Clay Enthusiasts) 
don't have the myfaces clout to make that integration native. 

   

> Hermod 
> 

Gary

> -Opprinnelig melding- 
> Fra: Steve Olson [mailto:[EMAIL PROTECTED] 
> Sendt: 17. desember 2006 17:55 
> Til: user@shale.apache.org 
> Emne: Re: Clay, Tomahawk and jscookmenu 
> 
> Thanks for the info. I looked at both the code below and your site, and 
> have a couple questions. It looks like you had to essentially render your 
> own menu, as if the jscookmenu renderer wasn't used. Also the call to 
> cmDrawFromText - the jscookmenu.js that comes with the tomahawk 1.1.3 jar 
> doesn't seem to define cmDrawFromText. I can see on the jscook site that 
> this is a valid function so are you using a newer jscook version than the 
> tomhawk jar does, or am I just missing something? 
> 
> Also, it looked like you had to extract the resources (.js, .gif, etc) for 
> jscookmenu from the tomahawk jar into your own directories and explicitly 
> include them, as if org.apache.myfaces.webapp.filter.ExtensionsFilter also 
> wasn't working. Is that what you had to do? Am I understanding things 
> correctly here? 
> 
> I was hoping to get html something like this working, but this just renders 
> a default submit Query button as an input control (!?): 
> 
> > theme="ThemeOffice"> 
> 
> > itemValue="#{messages['menu1']}" action="#{homePage.menu1}"/> 
> 
> > itemValue="#{messages['menu2']}" action="#{homePage.menu2}"/> 
> 
> 
> 
> It'd be nice if this would rely on the tomahawk infastructure to provide the 
> 
> same rendering it does without using Clay. Is there a conflict/bug here 
> between Clay and tomahawk with how it renders jscookmenu controls? 
> 
> If this is a bug or an RFE, I don't see anything listed in the Shale Jira. 
> I'm also assuming this is a Clay issue, since it works in JSP, but maybe 
> that's a bad assumption :-). Anyway, I have some time available and would 
> be interested in contributing a patch (assuming I can figure one out :-) if 
> that would be useful. 
> 
> Do you agree that this is a Clay bug? Do you know of anyone else already 
> looking into this? Should this be a new clay Jira issue? 
> 
> - Original Message - 
> From: "Hermod Opstvedt" 
> To: 
> Sent: Sunday, December 17, 2006 7:29 AM 
> Subject: SV: Clay, Tomahawk and jscookmenu 
> 
> 
> > Hi 
> > 
> > Look at http://test.os-seilforening.org. This uses the aforementioned 
> > combination. However, I had to tweak it a bit to get it working. 
> > 
> > Here is the code: 
> > 
> > 

> > 

> > 

> > > > value="#{facesContext.externalContext.requestContextPath}/index.xml" 
> > target="_self" alt="#{messages['nav_Home.alt']}"> 
> > > > value="#{messages['nav_Home']}"> 
> > 
> > 

> > 


> > 

> > > > value="#{facesContext.externalContext.requestContextPath}/open/medlem.xml"
> > > >  
> > target="_self" alt="#{messages['nav_Medlem.alt']}"> 
> > > > value="#{messages['nav_Medlem']}"> 
> > 
> > 

> > 


> > 

> > > > 
> value="#{facesContext.externalContext.requestContextPath}/open/rega

RE: SV: Clay, Tomahawk and jscookmenu

[hermod.opstvedt]

Hi

Creating a Maven Archetype for Clay is something that I am currently working 
on, because we need it here at work. So that should be wrapped up in the next 
day or two.

Hermod

-Original Message-
From: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sent: Monday, December 18, 2006 12:30 AM
To: user@shale.apache.org; [EMAIL PROTECTED]
Subject: Re: SV: Clay, Tomahawk and jscookmenu


>From: Hermod Opstvedt <[EMAIL PROTECTED]> 
>
> Hi 
> 
> Your assumptions are correct. As I stated in my first mail, I had to do some 
> tweaks. In the jscookmenu that comes with tomahawk 1.3 there are some coding 
> errors/presumptions that need to be worked around. Mainly, assumptions about 
> where pages are situated relative to the jscookmenu stuff. That is why I > 
> grabbed the script from the originators of jscookmenu and used that script 
> instead (Also had to alter some hardcoded stuff in there). 
> 
> I have not had the time to look into 1.5 of Tomahawk yet to see if that > 
> version works better that the 1.3 version, but I have it on my agenda to do 
> so during the upcomming holidays. If there are issues related to Clay, I > 
> will try to identify and rectify them. 
> 

 
That sounds awesome.  We sure could use the help identifying Clay/Tomahawk
issues or any component library.

I recently started the Clay/Trinidad project in the sandbox and I'm pretty happy
with the compatibility.  It uses Hermod's maven plugin to build the Clay configs
from the TLD.  

I think the best course of action is to create maven archetype's to setup a 
projects with the extra Clay bits.  This way they don't add 
another dependency to their build and we (Shale Clay Enthusiasts) 
don't have the myfaces clout to make that integration native. 

   

> Hermod 
> 

Gary

> -Opprinnelig melding- 
> Fra: Steve Olson [mailto:[EMAIL PROTECTED] 
> Sendt: 17. desember 2006 17:55 
> Til: user@shale.apache.org 
> Emne: Re: Clay, Tomahawk and jscookmenu 
> 
> Thanks for the info. I looked at both the code below and your site, and > 
> have a couple questions. It looks like you had to essentially render your 
> own menu, as if the jscookmenu renderer wasn't used. Also the call to 
> cmDrawFromText - the jscookmenu.js that comes with the tomahawk 1.1.3 jar > 
> doesn't seem to define cmDrawFromText. I can see on the jscook site that > 
> this is a valid function so are you using a newer jscook version than the 
> tomhawk jar does, or am I just missing something? 
> 
> Also, it looked like you had to extract the resources (.js, .gif, etc) for 
> jscookmenu from the tomahawk jar into your own directories and explicitly > 
> include them, as if org.apache.myfaces.webapp.filter.ExtensionsFilter also 
> wasn't working. Is that what you had to do? Am I understanding things 
> correctly here? 
> 
> I was hoping to get html something like this working, but this just renders 
> a default submit Query button as an input control (!?): 
> 
> > theme="ThemeOffice"> 
> 
> > itemValue="#{messages['menu1']}" action="#{homePage.menu1}"/> 
> 
> > itemValue="#{messages['menu2']}" action="#{homePage.menu2}"/> 
> 
> 
> 
> It'd be nice if this would rely on the tomahawk infastructure to provide the 
> 
> same rendering it does without using Clay. Is there a conflict/bug here > 
> between Clay and tomahawk with how it renders jscookmenu controls? 
> 
> If this is a bug or an RFE, I don't see anything listed in the Shale Jira. 
> I'm also assuming this is a Clay issue, since it works in JSP, but maybe > 
> that's a bad assumption :-). Anyway, I have some time available and would 
> be interested in contributing a patch (assuming I can figure one out :-) if 
> that would be useful. 
> 
> Do you agree that this is a Clay bug? Do you know of anyone else already > 
> looking into this? Should this be a new clay Jira issue? 
> 
> - Original Message - 
> From: "Hermod Opstvedt" 
> To: 
> Sent: Sunday, December 17, 2006 7:29 AM 
> Subject: SV: Clay, Tomahawk and jscookmenu 
> 
> 
> > Hi 
> > 
> > Look at http://test.os-seilforening.org. This uses the aforementioned > > 
> > combination. However, I had to tweak it a bit to get it working. 
> > 
> > Here is the code: 
> > 
> > 

> > 

> > 

> > > > value="#{facesContext.externalContext.requestContextPath}/index.xml" 
> > target="_self" alt="#{messages['nav_Home.alt']}"> 
> > > > value="#{messages['nav_Home']}"> 
> > 
> > 

> > 


> &

RE: SV: Clay, Tomahawk and jscookmenu

[Gary VanMatre]

>From: <[EMAIL PROTECTED]> 
>
> Hi 
> 
> Creating a Maven Archetype for Clay is something that I am currently working 
> on, 
> because we need it here at work. So that should be wrapped up in the next day 
> or 
> two. 
> 

Outstanding!  Thanks!


> Hermod 
> 

Gary


> -Original Message- 
> From: Gary VanMatre [mailto:[EMAIL PROTECTED] 
> Sent: Monday, December 18, 2006 12:30 AM 
> To: user@shale.apache.org; [EMAIL PROTECTED] 
> Subject: Re: SV: Clay, Tomahawk and jscookmenu 
> 
> 
> >From: Hermod Opstvedt 
> > 
> > Hi 
> > 
> > Your assumptions are correct. As I stated in my first mail, I had to do 
> > some 
> > tweaks. In the jscookmenu that comes with tomahawk 1.3 there are some 
> > coding 
> > errors/presumptions that need to be worked around. Mainly, assumptions 
> > about 
> > where pages are situated relative to the jscookmenu stuff. That is why I > 
> grabbed the script from the originators of jscookmenu and used that script 
> > instead (Also had to alter some hardcoded stuff in there). 
> > 
> > I have not had the time to look into 1.5 of Tomahawk yet to see if that > 
> version works better that the 1.3 version, but I have it on my agenda to do 
> > so during the upcomming holidays. If there are issues related to Clay, I > 
> will try to identify and rectify them. 
> > 
> 
> 
> That sounds awesome. We sure could use the help identifying Clay/Tomahawk 
> issues or any component library. 
> 
> I recently started the Clay/Trinidad project in the sandbox and I'm pretty 
> happy 
> with the compatibility. It uses Hermod's maven plugin to build the Clay 
> configs 
> from the TLD. 
> 
> I think the best course of action is to create maven archetype's to setup a 
> projects with the extra Clay bits. This way they don't add 
> another dependency to their build and we (Shale Clay Enthusiasts) 
> don't have the myfaces clout to make that integration native. 
> 
> 
> 
> > Hermod 
> > 
> 
> Gary 
> 
> > -Opprinnelig melding- 
> > Fra: Steve Olson [mailto:[EMAIL PROTECTED] 
> > Sendt: 17. desember 2006 17:55 
> > Til: user@shale.apache.org 
> > Emne: Re: Clay, Tomahawk and jscookmenu 
> > 
> > Thanks for the info. I looked at both the code below and your site, and > 
> > have 
> a couple questions. It looks like you had to essentially render your 
> > own menu, as if the jscookmenu renderer wasn't used. Also the call to 
> > cmDrawFromText - the jscookmenu.js that comes with the tomahawk 1.1.3 jar > 
> doesn't seem to define cmDrawFromText. I can see on the jscook site that > 
> this 
> is a valid function so are you using a newer jscook version than the 
> > tomhawk jar does, or am I just missing something? 
> > 
> > Also, it looked like you had to extract the resources (.js, .gif, etc) for 
> > jscookmenu from the tomahawk jar into your own directories and explicitly > 
> include them, as if org.apache.myfaces.webapp.filter.ExtensionsFilter also 
> > wasn't working. Is that what you had to do? Am I understanding things 
> > correctly here? 
> > 
> > I was hoping to get html something like this working, but this just renders 
> > a default submit Query button as an input control (!?): 
> > 
> > > theme="ThemeOffice"> 
> > 
> > > itemValue="#{messages['menu1']}" action="#{homePage.menu1}"/> 
> > 
> > > itemValue="#{messages['menu2']}" action="#{homePage.menu2}"/> 
> > 
> > 
> > 
> > It'd be nice if this would rely on the tomahawk infastructure to provide 
> > the 
> > 
> > same rendering it does without using Clay. Is there a conflict/bug here > 
> between Clay and tomahawk with how it renders jscookmenu controls? 
> > 
> > If this is a bug or an RFE, I don't see anything listed in the Shale Jira. 
> > I'm also assuming this is a Clay issue, since it works in JSP, but maybe > 
> that's a bad assumption :-). Anyway, I have some time available and would 
> > be interested in contributing a patch (assuming I can figure one out :-) if 
> > that would be useful. 
> > 
> > Do you agree that this is a Clay bug? Do you know of anyone else already > 
> looking into this? Should this be a new clay Jira issue? 
> > 
> > - Original Message - 
> > From: "Hermod Opstvedt" 
> > To: 
> > Sent: Sunday, December 17, 2006 7:29 AM 
> > Subject: SV: Clay, Tomahawk and jscookm

Re: Servlet 2.3 / JSP 1.2 abandoned?

[Wendy Smoak]

On 12/27/06, Adam Koch <[EMAIL PROTECTED]> wrote:


I have an old printed copy of the Shale main page and it said that Shale
will run on Servlet 2.3 and JSP 1.2 (with slight modifications). Since it's
not there any more, I wanted to know if this feature was removed? Is there
something in Servlet 2.4 or JSP 2.0 that is required for Shale to run now?


What parts of Shale are you interested in?

Shale's stated requirement is Servlet 2.4, but in this thread, Craig
mentions the following as a reason to split Shale up into multiple
jars:  "Allow apps to only include the pieces of Shale that they want
(such as folks who don't need view controller support, but need to run
on Servlet 2.3)."

http://www.nabble.com/-PROPOSAL--Refactor-Shale-Deliverables-t2354513.html

--
Wendy

Re: Servlet 2.3 / JSP 1.2 abandoned?

[Adam Koch]

I'm interested in the Remoting and the Dialog Manager.

On 12/27/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:


On 12/27/06, Adam Koch <[EMAIL PROTECTED]> wrote:

> I have an old printed copy of the Shale main page and it said that Shale
> will run on Servlet 2.3 and JSP 1.2 (with slight modifications). Since
it's
> not there any more, I wanted to know if this feature was removed? Is
there
> something in Servlet 2.4 or JSP 2.0 that is required for Shale to run
now?

What parts of Shale are you interested in?

Shale's stated requirement is Servlet 2.4, but in this thread, Craig
mentions the following as a reason to split Shale up into multiple
jars:  "Allow apps to only include the pieces of Shale that they want
(such as folks who don't need view controller support, but need to run
on Servlet 2.3)."

http://www.nabble.com/-PROPOSAL--Refactor-Shale-Deliverables-t2354513.html

--
Wendy





--
Adam A. Koch
http://www.outofthemold.com/

Re: Servlet 2.3 / JSP 1.2 abandoned?

[Adam Koch]

I'm interested in the Remoting and Dialog Manager.

On 12/27/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:


On 12/27/06, Adam Koch <[EMAIL PROTECTED]> wrote:

> I have an old printed copy of the Shale main page and it said that Shale
> will run on Servlet 2.3 and JSP 1.2 (with slight modifications). Since
it's
> not there any more, I wanted to know if this feature was removed? Is
there
> something in Servlet 2.4 or JSP 2.0 that is required for Shale to run
now?

What parts of Shale are you interested in?

Shale's stated requirement is Servlet 2.4, but in this thread, Craig
mentions the following as a reason to split Shale up into multiple
jars:  "Allow apps to only include the pieces of Shale that they want
(such as folks who don't need view controller support, but need to run
on Servlet 2.3)."

http://www.nabble.com/-PROPOSAL--Refactor-Shale-Deliverables-t2354513.html

--
Wendy





--
Adam A. Koch
http://www.outofthemold.com/

Re: Servlet 2.3 / JSP 1.2 abandoned?

[Craig McClanahan]

On 12/27/06, Adam Koch <[EMAIL PROTECTED]> wrote:


I'm interested in the Remoting and Dialog Manager.



Taking a quick skim through the code, I do not see anything in either of
these modules that requires Servlet 2.4 or later at the moment -- although I
am not really in favor of officially reducing the stated minimums to
something that is two Java EE versions behind the current one.

Two modules that absolutely require Servlet 2.4 are the View Controller and
Tiger (which also requires Java SE 5).

Craig

Re: Servlet 2.3 / JSP 1.2 abandoned?

[Adam Koch]

Thank you for your answer! The reason I ask is because my company uses
WebLogic 8.1.

RE: Servlet 2.3 / JSP 1.2 abandoned?

[mario.buonopane]

In shale taglib.tld there is the listener
"org.apache.shale.view.faces.LifecycleListener"
That implements the interface javax.servlet.ServletRequestListener that
I think does not exist in servlet 2.3 api.

Could be a problem in start up of the application?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig
McClanahan
Sent: 27 dicembre 2006 23.13
To: user@shale.apache.org
Subject: Re: Servlet 2.3 / JSP 1.2 abandoned?

On 12/27/06, Adam Koch <[EMAIL PROTECTED]> wrote:
>
> I'm interested in the Remoting and Dialog Manager.


Taking a quick skim through the code, I do not see anything in either of
these modules that requires Servlet 2.4 or later at the moment --
although I
am not really in favor of officially reducing the stated minimums to
something that is two Java EE versions behind the current one.

Two modules that absolutely require Servlet 2.4 are the View Controller
and
Tiger (which also requires Java SE 5).

Craig


This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information.  If you have received it in 
error, please notify the sender immediately and delete the original.  Any other 
use of the email by you is prohibited.

Re: Servlet 2.3 / JSP 1.2 abandoned?

[Craig McClanahan]

On 12/27/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:


In shale taglib.tld there is the listener
"org.apache.shale.view.faces.LifecycleListener"
That implements the interface javax.servlet.ServletRequestListener that
I think does not exist in servlet 2.3 api.

Could be a problem in start up of the application?



Definitely.  As I mentioned, shale-tiger and shale-view are two modules that
*absolutely* require Servlet 2.4.  The reason is that it is not possible to
reliably provide the services they provide in a Servlet 2.3 environment.

Craig


-Original Message-

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig
McClanahan
Sent: 27 dicembre 2006 23.13
To: user@shale.apache.org
Subject: Re: Servlet 2.3 / JSP 1.2 abandoned?

On 12/27/06, Adam Koch <[EMAIL PROTECTED]> wrote:
>
> I'm interested in the Remoting and Dialog Manager.


Taking a quick skim through the code, I do not see anything in either of
these modules that requires Servlet 2.4 or later at the moment --
although I
am not really in favor of officially reducing the stated minimums to
something that is two Java EE versions behind the current one.

Two modules that absolutely require Servlet 2.4 are the View Controller
and
Tiger (which also requires Java SE 5).

Craig


This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information.  If you have
received it in error, please notify the sender immediately and delete the
original.  Any other use of the email by you is prohibited.

RE: Servlet 2.3 / JSP 1.2 abandoned?

[mario.buonopane]

Do I need this module if I only use Dialog Manager?

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig
McClanahan
Sent: 28 dicembre 2006 09.19
To: user@shale.apache.org
Subject: Re: Servlet 2.3 / JSP 1.2 abandoned?

On 12/27/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]>
wrote:
>
> In shale taglib.tld there is the listener
> "org.apache.shale.view.faces.LifecycleListener"
> That implements the interface javax.servlet.ServletRequestListener
that
> I think does not exist in servlet 2.3 api.
>
> Could be a problem in start up of the application?


Definitely.  As I mentioned, shale-tiger and shale-view are two modules
that
*absolutely* require Servlet 2.4.  The reason is that it is not possible
to
reliably provide the services they provide in a Servlet 2.3 environment.

Craig


-Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Craig
> McClanahan
> Sent: 27 dicembre 2006 23.13
> To: user@shale.apache.org
> Subject: Re: Servlet 2.3 / JSP 1.2 abandoned?
>
> On 12/27/06, Adam Koch <[EMAIL PROTECTED]> wrote:
> >
> > I'm interested in the Remoting and Dialog Manager.
>
>
> Taking a quick skim through the code, I do not see anything in either
of
> these modules that requires Servlet 2.4 or later at the moment --
> although I
> am not really in favor of officially reducing the stated minimums to
> something that is two Java EE versions behind the current one.
>
> Two modules that absolutely require Servlet 2.4 are the View
Controller
> and
> Tiger (which also requires Java SE 5).
>
> Craig
>
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information.  If you
have
> received it in error, please notify the sender immediately and delete
the
> original.  Any other use of the email by you is prohibited.
>


This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information.  If you have received it in 
error, please notify the sender immediately and delete the original.  Any other 
use of the email by you is prohibited.

Re: Servlet 2.3 / JSP 1.2 abandoned?

[Craig McClanahan]

On 12/28/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
wrote:


Do I need this module if I only use Dialog Manager?



For the dialog manager, using either a recent nightly build or the upcoming
1.0.4 release, you'll need:
* shale-dialog-xxx.jar
* Either shale-dialog-basic-xxx.jar or shale-dialog-scxml-xxx.jar (your
choice
 of dialog implementations)
* commons-logging-xxx.jar, commons-digester-xxx.jar,
commons-beanutils-xxx.jar
* A JSF implementation (and its dependencies) if you are
 not running on an app server with JSF pre-installed

Craig


-Original Message-

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig
McClanahan
Sent: 28 dicembre 2006 09.19
To: user@shale.apache.org
Subject: Re: Servlet 2.3 / JSP 1.2 abandoned?

On 12/27/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]>
wrote:
>
> In shale taglib.tld there is the listener
> "org.apache.shale.view.faces.LifecycleListener"
> That implements the interface javax.servlet.ServletRequestListener
that
> I think does not exist in servlet 2.3 api.
>
> Could be a problem in start up of the application?


Definitely.  As I mentioned, shale-tiger and shale-view are two modules
that
*absolutely* require Servlet 2.4.  The reason is that it is not possible
to
reliably provide the services they provide in a Servlet 2.3 environment.

Craig


-Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Craig
> McClanahan
> Sent: 27 dicembre 2006 23.13
> To: user@shale.apache.org
> Subject: Re: Servlet 2.3 / JSP 1.2 abandoned?
>
> On 12/27/06, Adam Koch <[EMAIL PROTECTED]> wrote:
> >
> > I'm interested in the Remoting and Dialog Manager.
>
>
> Taking a quick skim through the code, I do not see anything in either
of
> these modules that requires Servlet 2.4 or later at the moment --
> although I
> am not really in favor of officially reducing the stated minimums to
> something that is two Java EE versions behind the current one.
>
> Two modules that absolutely require Servlet 2.4 are the View
Controller
> and
> Tiger (which also requires Java SE 5).
>
> Craig
>
>
> This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information.  If you
have
> received it in error, please notify the sender immediately and delete
the
> original.  Any other use of the email by you is prohibited.
>


This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information.  If you have
received it in error, please notify the sender immediately and delete the
original.  Any other use of the email by you is prohibited.

Re: Servlet 2.3 / JSP 1.2 abandoned?

[Adam Koch]

I went to http://people.apache.org/builds/shale/nightly/ but didn't find any
dialog-specific jars. Do I have to use "Maven repositories" (which I don't
know how to use) to get to the jar files?

Re: Servlet 2.3 / JSP 1.2 abandoned?

[Rahul Akolkar]

On 12/29/06, Adam Koch <[EMAIL PROTECTED]> wrote:

I went to http://people.apache.org/builds/shale/nightly/ but didn't find any
dialog-specific jars. Do I have to use "Maven repositories" (which I don't
know how to use) to get to the jar files?



Download the shale-framework-.zip file, once unzipped you will
find the jars in the lib/ directory. You will need the
shale-dialog-xx.jar and either one of the shale-dialog-basic or
shale-dialog-scxml jars (see website for details).

-Rahul

Re: Servlet 2.3 / JSP 1.2 abandoned?

[Adam A. Koch]

Thanks!

Re: JSF 1.1 vs. JSF 1.2

[Greg Reddin]

On 1/18/07, Reynolds, James <[EMAIL PROTECTED]> wrote:


2. JSF 1.1, Facelets & Shale




This is the platform we are currently developing on.  It's "very close" to
working with JSF 1.2 from what I can tell (though I have not actually used
1.2 yet).

1. EL unification.  Since I'm not using JSPs, this isn't a big deal


Well, it's not entirely gone :-)  You still do EL with Facelets.  It's true
that Facelets allows you to use the unified EL out of the box.  But I've
noticed that in some instances using Tomahawk tags I still have to use the
"#{...}" syntax.  The net result is that our code is sprinkled with mostly
"${...}" and a few "#{...}" and I have to try to explain to new devs when
and why they have to use one or the other.

Overall, I'm pretty happy with where we are.

Greg

Re: JSF 1.1 vs. JSF 1.2

[Craig McClanahan]

On 1/18/07, Reynolds, James <[EMAIL PROTECTED]> wrote:


I think I get it now (thanks to help from this list).  If I want to use
JSF 1.2 with Shale, I must use a J2EE 5 servlet container.  However, I
may not be able to convince my company to switch from Tomcat 5.5.*



If you want to run JSF 1.2 on Tomcat, you really want 6.0 not 5.5.  It might
be technically feasible to hack together a JSF 1.2 implementation that would
execute on Tomcat 5.5, but it's hard to see how you could have a completely
spec compliant implementation in the absence of JSP 2.1 (which is part of
Tomcat 6; Tomcat 5 and 5.5 provide JSP 2.0).

If that is the case, I need to decide between the following two setups:


1. JSF 1.2 & Facelets or
2. JSF 1.1, Facelets & Shale

Practically speaking, the main improvements in JSF 1.2 may not offer too
much to me since I'm using Facelets.  Specifically:



Just curious ... is this based on a belief that  JSF 1.2 + Facelets + Shale
does not work (if it doesn't that is a bug that needs to be fixed), or that
Shale does not provide you anything extra if you have JSF 1.2?  I confess
that I don't recall any details of which Shale features you are looking at
from your previous comments ... but there is quite a lot of different things
available.

1. EL unification.  Since I'm not using JSPs, this isn't a big deal

2. Improved Messages.  From what I've read, Shale's info/warn/error
methods provide much of the same improvements to 1.1 as there is "out of
the box" in 1.2.

Finally, I'll need to consider bug fixes, like the "multiple button
press" issue.

In your experience, is developing JSF 1.2 far superior to JSF 1.1?  Are
there any major tradeoffs that I'm overlooking?

Thanks for your time and any advice.




Craig

RE: JSF 1.1 vs. JSF 1.2

[Reynolds, James]

> If you want to run JSF 1.2 on Tomcat, you really want 6.0 not 5.5.  It
>might
>be technically feasible to hack together a JSF 1.2 implementation that
>would
>execute on Tomcat 5.5, but it's hard to see how you could have a
completely
>spec compliant implementation in the absence of JSP 2.1 (which is part
of
>Tomcat 6; Tomcat 5 and 5.5 provide JSP 2.0)."

You're right, *I* really want Tomcat 6, but my employers are leery of
its beta status.  They are also concerned about supporting an additional
container.

>Just curious ... is this based on a belief that  JSF 1.2 + Facelets +
Shale
>does not work (if it doesn't that is a bug that needs to be fixed), or
that
>Shale does not provide you anything extra if you have JSF 1.2?  I
confess
>that I don't recall any details of which Shale features you are looking
at
>from your previous comments ... but there is quite a lot of different
>things
>available.

I didn't explain myself clearly, I'd prefer to use Shale in either case.
My problem is that I may be stuck in Tomcat 5.5.17, which (for me) would
necessitate using JSF 1.1.  

I need to decide if yesterday's setup is good enough, or if it's worth
pushing my employers really hard to add a Tomcat 6 setup (and risk being
thrown out on my rear).  






E-Mail messages may contain viruses, worms, or other malicious code. By reading 
the message and opening any attachments, the recipient accepts full 
responsibility for taking protective action against such code. Sender is not 
liable for any loss or damage arising from this message.

The information in this e-mail is confidential and may be legally privileged. 
It is intended solely for the addressee(s). Access to this e-mail by anyone 
else is unauthorized.

RE: JSF 1.1 vs. JSF 1.2

[Kito D. Mann]

> 
> I didn't explain myself clearly, I'd prefer to use Shale in 
> either case.
> My problem is that I may be stuck in Tomcat 5.5.17, which 
> (for me) would necessitate using JSF 1.1.  
> 
> I need to decide if yesterday's setup is good enough, or if 
> it's worth pushing my employers really hard to add a Tomcat 6 
> setup (and risk being thrown out on my rear).  

Don't forget that you can use JSF 1.2 with Facelets and Tomcat 5.x. And you
can use Facelets with Shale, too.

~~~
Kito D. Mann ([EMAIL PROTECTED])
Author, JavaServer Faces in Action
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info

RE: JSF 1.1 vs. JSF 1.2

[Gary VanMatre]

>From: "Kito D. Mann" <[EMAIL PROTECTED]> 
>
> > 
> > I didn't explain myself clearly, I'd prefer to use Shale in 
> > either case. 
> > My problem is that I may be stuck in Tomcat 5.5.17, which 
> > (for me) would necessitate using JSF 1.1. 
> > 
> > I need to decide if yesterday's setup is good enough, or if 
> > it's worth pushing my employers really hard to add a Tomcat 6 
> > setup (and risk being thrown out on my rear). 
> 
> Don't forget that you can use JSF 1.2 with Facelets and Tomcat 5.x. And you 
> can use Facelets with Shale, too. 
> 


That's awesome that Facelets works with Shale too.  Looks like there's about a 
dozen articles and at least a couple Virtua courses.  All there at JSFCentral.




> ~~~ 
> Kito D. Mann ([EMAIL PROTECTED]) 
> Author, JavaServer Faces in Action 
> http://www.virtua.com - JSF/Java EE consulting, training, and mentoring 
> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info 
> 

Re: JSF 1.1 vs. JSF 1.2

[Ingo Düppe]

Hi,

1. EL unification.  Since I'm not using JSPs, this isn't a big deal


Well, it's not entirely gone :-)  You still do EL with Facelets.  It's 
true

that Facelets allows you to use the unified EL out of the box.  But I've
noticed that in some instances using Tomahawk tags I still have to use 
the
"#{...}" syntax.  The net result is that our code is sprinkled with 
mostly

"${...}" and a few "#{...}" and I have to try to explain to new devs when
and why they have to use one or the other.
Sorry, you confuse me. Is there any difference between #{...} and ${...}? 
Could you explain when and why to use one or the other.
Does it depend on fact that in some classes of tomahawk use  a hard 
coded '#{' el prefix?


Regards
Ingo

Re: Choosing a JSF/AJAX Framework

[Craig McClanahan]

On 1/23/07, James Watkin <[EMAIL PROTECTED]> wrote:


I'm looking for a new web application framework. From attending various
conferences and selected readings, it appears that a framework which
supports JSF and AJAX is probably what we're looking for.

Again, based solely on conferences and selected readings, the following
frameworks appear to have merit:

* Apache Shale or JBoss Seam for a high-end code-centric framework.
http://shale.apache.org/
http://www.jboss.com/products/seam

* ICEfaces for superior JSF/AJAX integration.
http://www.devx.com/security/Article/33533
http://www.icesoft.com/products/icefaces.html

http://theserversidecom.bitpipe.com/detail/RES/1163445089_619.html?src=wc_atssc_sitepost_11_14_06

* NetBeans Visual Web Pack (or Sun Java Studio Creator) for rapid
development.
http://www.netbeans.org/products/visualweb/
http://developers.sun.com/prodtech/javatools/jscreator/index.jsp

* Spring Web Flow combined with JSF?
http://opensource.atlassian.com/confluence/spring/display/WEBFLOW/Home



You might want to add one more category of things to look at ... JSF-based
libraries that enable the use of non-Ajax-aware JSF components in an Ajax
environment (partial page submit, partial page refresh).  Two libraries at
java.net that do this kind of thing:

* https://ajax4jsf.dev.java.net/

* https://jsf-extensions.dev.java.net/

I notice that JBoss Seam appears to have support for ICEfaces. Does

Apache Shale plan to do the same? If not, why not, and does Apache Shale
have some other plan to support AJAX, and what will be the benefit of
that other approach?



You will see two "attitudes" in Shale towards this issue:

* Shale does not contain any components itself ... it is designed to add
value
 on the server side while working with *any* component library.  Therefore,
 in principle, it should work with any of the JSF-Ajax component libraries
that
 you like.  That being said, if there are compelling advantages to be
gained by
 an explicit integration layer for particular libraries, we will certainly
look at that.
 But, in the particular case of ICEFaces, there shouldn't be anything
required
 other than just putting all the right libraries together.

* For the particular use case of a client side application that wants to do
 asynchronous callbacks *without* updating the JSF component state (perhaps
 because the server side application is not based on JSF components), the
 Shale Remoting library provides facilities for doing that sort of thing
directly.

Since my only hands-on web development experience is with Struts, I'm

looking for a discussion of these JSF/AJAX frameworks by those that have
actual experience using them.

If you're qualified, could you please share your experiences, assess
these frameworks (or others I have omitted), and while you're at it,
predict their futures?



As if you did not have enough to read :-), one other item to keep track of
is the "Web Beans" JSR (http://jcp.org/en/jsr/detail?id=299).  This is an
attempt (just getting started) to standardize the relationships between the
JSF and EJB3/JPA component models, using Seam as a model of what might be
possible (plus contributions from other frameworks, of course).

Thank you.


- Jim



Craig

Re: Integrating JSF and Shale Tiles

[Craig McClanahan]

A couple of intermixed comments ... I'm hoping Greg and others more familiar
with Tiles than I am might be able to help too.

On 1/24/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:



I've tried to use the shale-framework-1.0.4.zip file and have hit a
problem
that I was wondering if anyone could help me with?

I've developed a very simple 2 page JSF application using Workshop v3.2.1
which just allows you to move from the first to the second pages using a
commandLinks action to trigger a JSF navigation.  This has all the
"common"
JARs as per the shale-framework-1.0.4.zip and works fine.  However when I
added in the shale-*-1.0.4.jar's, spring-*1.2.8.jar's and
tiles-core-2.0-468346-SNAPSHOT.jar and make some config file changes to
introduce Tiles behaviour I start to get problems.



It might be a little easier to debug things like this if you only add one
layer of stuff at a time :-).

To my faces-config.xml I added

   org.apache.shale.tiles.TilesViewHandler



You do not need to do this ... it is already done inside the
shale-tiles-xxx.jar file.

To my web.xml file I added a context parameter pointing to my new tiles.xml

file

tiles-definitions
/WEB-INF/tiles.xml

and added an additional servlet

Tiles Servlet
org.apache.tiles.servlet.TilesServlet

1

the existing (faces) servlet had the load-on-startup value changed to 2
(from 1) at this point.

I created a tiles.xml file (within the WEB-INF folder) that just defines a
header, menu, content format for these same 2 pages (with the header being
made up of 3 sub-parts a banner, breadcrumb trail and heading).

   
   http://jakarta.apache.org/struts/dtds/tiles-config.dtd";>

   

   










   




















I also added in the necessary menu, header, content and headerMenuContent
JSPs into the tiles folder (at the same level as the pages folder) and the
example*** JSPs into the pages folder.

The application builds within Workshop OK but when I try and run it
(Tomcat
v5.5) I get the following output in the console...

INFO: Initializing TilesServlet
24-Jan-2007 16:05:29 org.apache.tiles.servlet.TilesServletreadFactoryConfig
INFO: CONFIG FILES WERE NOT DEFINED IN WEB.XML, LOOKING FOR
/WEB-INF/tiles.xml



This message implies that your context init parameter is not being
recognized.  If I am reading the Tiles code correctly, the parameter name
should now be "org.apache.tiles.DEFINITIONS_CONFIG" although
"definitions-config"  is still recognized for backwards compatibility.


24-Jan-2007 16:05:29 org.apache.tiles.servlet.TilesServlet

initDefinitionsFactory
INFO: initializing definitions factory...
org.apache.tiles.DefinitionsFactoryException: I/O Error reading
definitions.
at



The fact that this says I/O error instead of parsing error implies that the
problem is not finding the file at all (rather than some problem with the
XML syntax).

Craig

org.apache.tiles.digester.DigesterDefinitionsReader.read(

DigesterDefinitionsReader.java:161)
at
org.apache.tiles.definition.UrlDefinitionsFactory.readDefinitions(
UrlDefinitionsFactory.java:253)
at
org.apache.tiles.TilesUtilImpl.createDefinitionsFactory(TilesUtilImpl.java
:190)
at org.apache.tiles.TilesUtil.createDefinitionsFactory(
TilesUtil.java:165)
at
org.apache.tiles.servlet.TilesServlet.initDefinitionsFactory(
TilesServlet.java:234)
at org.apache.tiles.servlet.TilesServlet.init(TilesServlet.java
:174)
at
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java
:1091)
at org.apache.catalina.core.StandardWrapper.load(
StandardWrapper.java:925)
at
org.apache.catalina.core.StandardContext.loadOnStartup(
StandardContext.java:3857)
at
org.apache.catalina.core.StandardContext.start(StandardContext.java:4118)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java
:1012)
at org.apache.catalina.core.StandardHost.start(StandardHost.java
:718)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java
:1012)
at org.apache.catalina.core.StandardEngine.start(
StandardEngine.java:442)
at org.apache.catalina.core.StandardService.start(
StandardService.java:450)
at org.apache.catalina.core.StandardServer.start(
StandardServer.java:683)
at org.apache.catalina.startup.Catalina.start(Catalina.java:537)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(
DelegatingMethodAccessorImpl.java:

Re: Integrating JSF and Shale Tiles

[Greg Reddin]

On 1/24/07, Craig McClanahan <[EMAIL PROTECTED]> wrote:


> INFO: Initializing TilesServlet
> 24-Jan-2007 16:05:29
org.apache.tiles.servlet.TilesServletreadFactoryConfig
> INFO: CONFIG FILES WERE NOT DEFINED IN WEB.XML, LOOKING FOR
> /WEB-INF/tiles.xml


This message implies that your context init parameter is not being
recognized.  If I am reading the Tiles code correctly, the parameter name
should now be "org.apache.tiles.DEFINITIONS_CONFIG" although
"definitions-config"  is still recognized for backwards compatibility.



Yes try "definitions-config" and see if that works.  You can also check the
example web.xml found here:


https://svn.apache.org/repos/asf/tiles/trunk/tiles-test/src/main/webapp/WEB-INF/web.xml


24-Jan-2007 16:05:29 org.apache.tiles.servlet.TilesServlet

> initDefinitionsFactory
> INFO: initializing definitions factory...
> org.apache.tiles.DefinitionsFactoryException: I/O Error reading
> definitions.
> at


The fact that this says I/O error instead of parsing error implies that
the
problem is not finding the file at all (rather than some problem with the
XML syntax).



I've seen this error before when Tiles could not load the file for one
reason or another.  As Craig said I don't think it's a problem with the XML,
it appears to be a problem loading the file itself.

Greg

Re: How to use Dialogs and ?

[Craig McClanahan]

On 1/24/07, Paul Spencer <[EMAIL PROTECTED]> wrote:


I would like to start a dialog from a menu.  The following does not
appear to start the dialog:

   



For this to work, the logic in the "action" attribute (in the JSP tag) would
need to have the same special casing that the standard  and
 tags do ... if the expression is a literal string, return it
directly as an outcome; otherwise, treat it as a method binding to an action
method.  It might be worth asking on the MyFaces list if it actually works
that way (failure to do so is a bug IMHO), and/or have a look at the code.

The following does start the dialog:

   

Can the dialog be started from a ?  How?



Worst case, you should be able to invoke a simple action method that returns
the outcome you want.

   

   public class MyBean {
   ...
   public String startAddVendor() { return "dialog:addVendor"; }
   ...
   }

Paul Spencer





Craig

Re: Choosing a JSF/AJAX Framework

[James Watkin]

Craig,

Thank you for your time, information, and openness.

I'd also like to pass along a link to a video interview of Ed Burns that 
I watched today:


http://w.on24.com/r.htm?e=25412&s=1&k=1C3610AF899E09A2EFD26F0FD6B7875E&partnerref=atssc_sitepost_01_16_07

In this interview, Ed Burns talked about JSF frameworks like Apache 
Shale and how the next version of the JSF spec will leverage ideas from 
them.


Some specific features mentioned for the next (2.0?) JSF spec were 
conversation scope, additional core components, state management, and 
some sort of AJAX support.


In a reference to Apache Shale, Ed Burns said, "...they (Apache Shale) 
have a remoting package that provides the ability to facilitate AJAX by 
invoking method bindings in the server but it turns out there are some 
security issues with that, but I think they'll be addressed." I don't 
know how old this interview is. Can you explain what he's referring to 
and whether or not it was addressed?


- Jim

Craig McClanahan wrote:

On 1/23/07, James Watkin <[EMAIL PROTECTED]> wrote:


I'm looking for a new web application framework. From attending various
conferences and selected readings, it appears that a framework which
supports JSF and AJAX is probably what we're looking for.

Again, based solely on conferences and selected readings, the following
frameworks appear to have merit:

* Apache Shale or JBoss Seam for a high-end code-centric framework.
http://shale.apache.org/
http://www.jboss.com/products/seam

* ICEfaces for superior JSF/AJAX integration.
http://www.devx.com/security/Article/33533
http://www.icesoft.com/products/icefaces.html

http://theserversidecom.bitpipe.com/detail/RES/1163445089_619.html?src=wc_atssc_sitepost_11_14_06 



* NetBeans Visual Web Pack (or Sun Java Studio Creator) for rapid
development.
http://www.netbeans.org/products/visualweb/
http://developers.sun.com/prodtech/javatools/jscreator/index.jsp

* Spring Web Flow combined with JSF?
http://opensource.atlassian.com/confluence/spring/display/WEBFLOW/Home



You might want to add one more category of things to look at ... JSF-based
libraries that enable the use of non-Ajax-aware JSF components in an Ajax
environment (partial page submit, partial page refresh).  Two libraries at
java.net that do this kind of thing:

* https://ajax4jsf.dev.java.net/

* https://jsf-extensions.dev.java.net/

I notice that JBoss Seam appears to have support for ICEfaces. Does

Apache Shale plan to do the same? If not, why not, and does Apache Shale
have some other plan to support AJAX, and what will be the benefit of
that other approach?



You will see two "attitudes" in Shale towards this issue:

* Shale does not contain any components itself ... it is designed to add
value
 on the server side while working with *any* component library.  Therefore,
 in principle, it should work with any of the JSF-Ajax component libraries
that
 you like.  That being said, if there are compelling advantages to be
gained by
 an explicit integration layer for particular libraries, we will certainly
look at that.
 But, in the particular case of ICEFaces, there shouldn't be anything
required
 other than just putting all the right libraries together.

* For the particular use case of a client side application that wants to do
 asynchronous callbacks *without* updating the JSF component state (perhaps
 because the server side application is not based on JSF components), the
 Shale Remoting library provides facilities for doing that sort of thing
directly.

Since my only hands-on web development experience is with Struts, I'm

looking for a discussion of these JSF/AJAX frameworks by those that have
actual experience using them.

If you're qualified, could you please share your experiences, assess
these frameworks (or others I have omitted), and while you're at it,
predict their futures?



As if you did not have enough to read :-), one other item to keep track of
is the "Web Beans" JSR (http://jcp.org/en/jsr/detail?id=299).  This is an
attempt (just getting started) to standardize the relationships between the
JSF and EJB3/JPA component models, using Seam as a model of what might be
possible (plus contributions from other frameworks, of course).

Thank you.


- Jim



Craig



--
__
James Watkin
ACIS Software Development
UCLA Anderson School
[EMAIL PROTECTED]
Voice: 1-310-825-5030
  Fax: 1-310-825-4835
__

Re: Choosing a JSF/AJAX Framework

[Craig McClanahan]

On 1/24/07, James Watkin <[EMAIL PROTECTED]> wrote:


Craig,

Thank you for your time, information, and openness.

I'd also like to pass along a link to a video interview of Ed Burns that
I watched today:


http://w.on24.com/r.htm?e=25412&s=1&k=1C3610AF899E09A2EFD26F0FD6B7875E&partnerref=atssc_sitepost_01_16_07

In this interview, Ed Burns talked about JSF frameworks like Apache
Shale and how the next version of the JSF spec will leverage ideas from
them.

Some specific features mentioned for the next (2.0?) JSF spec were
conversation scope, additional core components, state management, and
some sort of AJAX support.

In a reference to Apache Shale, Ed Burns said, "...they (Apache Shale)
have a remoting package that provides the ability to facilitate AJAX by
invoking method bindings in the server but it turns out there are some
security issues with that, but I think they'll be addressed." I don't
know how old this interview is. Can you explain what he's referring to
and whether or not it was addressed?



Yes, it was an old issue (the interview was recorded a while ago), and yes
it has been addressed in the 1.0.4 release.  The issue related to the way
that the "dynamic" processor mapped a request URL to a method binding that
could call any public method on a managed bean that has zero parameters.  In
other words, a URL like:

   http://localhost:8080/myapp/dynamic/foo/bar.faces

(assumes you are using *.faces mapping for FacesServlet) would cause a
method binding expression "#{foo.bar}" to be constructed, and therefore the
"bar" method would be called.  The challenge is that you might have public
zero-args methods in your managed beans that are not designed to be executed
directly from a client call like that, and gives clients an opportunity to
disrupt your application.

Today, the fix for this is a set of context init parameters that can be used
to limit what URL patterns are allowed or disallowed for this processor (as
well as the ones that serve static resources) to serve.  It will return "not
allowed" HTTP errors if you attempt to use a prohibited URL pattern.  The
gory details of configuring this are in the package summary Javadocs[1].

In the future, when we can move to an assumption of Java SE 5 as the
baseline (or successfully demonstrate that retro-weaved JARs can run
on 1.4systems), we'll be able to use annotations to explicitly
identify the public
methods that you want to make accessible to the dynamic processor.  That's a
lot more fine grained and easily understood than having to remember to
update URL patterns in context init parameters.

- Jim


Craig


Craig McClanahan wrote:

> On 1/23/07, James Watkin <[EMAIL PROTECTED]> wrote:
>>
>> I'm looking for a new web application framework. From attending various
>> conferences and selected readings, it appears that a framework which
>> supports JSF and AJAX is probably what we're looking for.
>>
>> Again, based solely on conferences and selected readings, the following
>> frameworks appear to have merit:
>>
>> * Apache Shale or JBoss Seam for a high-end code-centric framework.
>> http://shale.apache.org/
>> http://www.jboss.com/products/seam
>>
>> * ICEfaces for superior JSF/AJAX integration.
>> http://www.devx.com/security/Article/33533
>> http://www.icesoft.com/products/icefaces.html
>>
>>
http://theserversidecom.bitpipe.com/detail/RES/1163445089_619.html?src=wc_atssc_sitepost_11_14_06
>>
>>
>> * NetBeans Visual Web Pack (or Sun Java Studio Creator) for rapid
>> development.
>> http://www.netbeans.org/products/visualweb/
>> http://developers.sun.com/prodtech/javatools/jscreator/index.jsp
>>
>> * Spring Web Flow combined with JSF?
>> http://opensource.atlassian.com/confluence/spring/display/WEBFLOW/Home
>
>
> You might want to add one more category of things to look at ...
JSF-based
> libraries that enable the use of non-Ajax-aware JSF components in an
Ajax
> environment (partial page submit, partial page refresh).  Two libraries
at
> java.net that do this kind of thing:
>
> * https://ajax4jsf.dev.java.net/
>
> * https://jsf-extensions.dev.java.net/
>
> I notice that JBoss Seam appears to have support for ICEfaces. Does
>> Apache Shale plan to do the same? If not, why not, and does Apache
Shale
>> have some other plan to support AJAX, and what will be the benefit of
>> that other approach?
>
>
> You will see two "attitudes" in Shale towards this issue:
>
> * Shale does not contain any components itself ... it is designed to add
> value
>  on the server side while working with *any* component
library.  Therefore,
>  in principle, it should work with any of the JSF-Ajax component
libraries
> that
>  you like.  That being said, if there are compelling advantages to be
> gained by
>  an explicit integration layer for particular libraries, we will
certainly
> look at that.
>  But, in the particular case of ICEFaces, there shouldn't be anything
> required
>  other than just putting all the right libraries together.
>
> * For the particular use case o

Re: ADF faces with shale tiger

[Craig McClanahan]

On 1/26/07, amjad Shahrour <[EMAIL PROTECTED]> wrote:


Hi there,

I am trying to utilize only shale-tiger with ADF faces.

I am interested only in using only the view controller services
(callbacks).
i created a simple (adf) jsf page and used the @View @Preprocess @Init
@Prerender @Destroy on the page's backing bean. but nothing seems to take
effect (no callbacks are being called).



A couple of quick questions:

* Is the backing bean also registered as a managed bean in faces-config.xml?
 If not, you will also want to use the @Bean annotation.

* Does the name you assign the matching bean match the view id so that
 the matching algorithm will find it?

* Have you tried this with just standard components to temporarily reduce
 the complexity of all the stuff being combined?

Craig


following is the web.xml file content



> http://java.sun.com/xml/ns/j2ee";
>  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>  xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
> http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd";
>  version="2.4">
> Empty web.xml file for Web Application
>
>
>
> 
> javax.faces.STATE_SAVING_METHOD
> server
> 
> 
> oracle.adf.view.faces.USE_APPLICATION_VIEW_CACHE
> 
> false
> 
> 
> CpxFileName
> systemsettings.DataBindings
> 
>
>
>   
>
> 
> adfFaces
> oracle.adf.view.faces.webapp.AdfFacesFilter
> 
> 
> 
> adfBindings
> oracle.adf.model.servlet.ADFBindingFilter
> 
> 
> 
> CustomSecurityFilter
> com.openaspects.comms.commons.CustomSecurityFilter
> 
> 
>
>
> 
> shale
> 
> org.apache.shale.application.faces.ShaleApplicationFilter
> 
>   
>
>
>
>
>
>   
>
>
>
> 
> adfFaces
> faces
> 
> 
> adfBindings
> *.jsp
> 
> 
> adfBindings
> *.jspx
> 
> 
> CustomSecurityFilter
> faces
> 
>
>   
> shale
> /*
>   
>
>
> 
> faces
> javax.faces.webapp.FacesServlet
> 1
> 
> 
> resources
> oracle.adf.view.faces.webapp.ResourceServlet
> 
> 
> 
> faces
> /faces/*
> 
> 
> resources
> /adf/*
> 
> 
> 35
> 
> 
> html
> text/html
> 
> 
> txt
> text/plain
> 
>
> 
> 
>   org.apache.commons.chain.web.ChainListener
> 
>   
>
>
> 
> /index.jsp
>
>
> 
> java.lang.Exception
> /Error.jsp
> 
>
> 
>  Oracle Datasource example
>  jdbc/myoracle
>  javax.sql.DataSource
>  Container
> 
>
> 
>



Am I missing something ?


thanks in advance

Re: ADF faces with shale tiger

[Gary VanMatre]

>From: "amjad Shahrour" <[EMAIL PROTECTED]> 
>
> Hi there, 
> 
> I am trying to utilize only shale-tiger with ADF faces. 
> 
> I am interested only in using only the view controller services (callbacks). 
> i created a simple (adf) jsf page and used the @View @Preprocess @Init 
> @Prerender @Destroy on the page's backing bean. but nothing seems to take 
> effect (no callbacks are being called). 
> 

It sounds like you are missing the binding between a JSF view and a managed 
bean.  This is handled by a naming convention.  The JSF viewId is normalized 
into a value that must have a corresponding managed.  

So if your target page was "/something.jsf", the ViewController should be 
registered as a managed bean by the name of "something".  The default mapper, 
removes the suffix of the viewId and replaces the "/" with "$".  You can 
override the default mapper if you want to create your own rules.


Since your are using the tiger annotations (you also need shale-tiger besides 
shale-view and shale-core), you could register your ViewControllers as managed 
beans with the following annotation:

@Bean(name = "something", scope = Scope.REQUEST)


> 
> following is the web.xml file content 
> 
> 
> 
> thanks in advance 


Gary

Re: ADF faces with shale tiger

[amjad Shahrour]

You are right Gary, that was the cause. Thanks.

I am interested to learn more about the mapper configuration. can you point
me to a document about it.

regards,
amjad

On 1/26/07, Gary VanMatre <[EMAIL PROTECTED]> wrote:


>From: "amjad Shahrour" <[EMAIL PROTECTED]>
>
> Hi there,
>
> I am trying to utilize only shale-tiger with ADF faces.
>
> I am interested only in using only the view controller services
(callbacks).
> i created a simple (adf) jsf page and used the @View @Preprocess @Init
> @Prerender @Destroy on the page's backing bean. but nothing seems to
take
> effect (no callbacks are being called).
>

It sounds like you are missing the binding between a JSF view and a
managed bean.  This is handled by a naming convention.  The JSF viewId is
normalized into a value that must have a corresponding managed.

So if your target page was "/something.jsf", the ViewController should be
registered as a managed bean by the name of "something".  The default
mapper, removes the suffix of the viewId and replaces the "/" with "$".  You
can override the default mapper if you want to create your own rules.


Since your are using the tiger annotations (you also need shale-tiger
besides shale-view and shale-core), you could register your ViewControllers
as managed beans with the following annotation:

@Bean(name = "something", scope = Scope.REQUEST)


>
> following is the web.xml file content
>
>
>
> thanks in advance


Gary

Re: ADF faces with shale tiger

[Gary VanMatre]

>From: "amjad Shahrour" <[EMAIL PROTECTED]> 
>
> You are right Gary, that was the cause. Thanks. 
> 
> I am interested to learn more about the mapper configuration. can you point 
> me to a document about it. 
> 

We have some site documentation [1].  This is Craig's craft-work so the javadoc 
is also very helpful [2].

[1]http://shale.apache.org/shale-view/index.html
[2]http://shale.apache.org/shale-view/apidocs/org/apache/shale/view/impl/DefaultViewControllerMapper.html

> regards, 
> amjad 
> 

Gary

> On 1/26/07, Gary VanMatre wrote: 
> > 
> > >From: "amjad Shahrour" 
> > > 
> > > Hi there, 
> > > 
> > > I am trying to utilize only shale-tiger with ADF faces. 
> > > 
> > > I am interested only in using only the view controller services 
> > (callbacks). 
> > > i created a simple (adf) jsf page and used the @View @Preprocess @Init 
> > > @Prerender @Destroy on the page's backing bean. but nothing seems to 
> > take 
> > > effect (no callbacks are being called). 
> > > 
> > 
> > It sounds like you are missing the binding between a JSF view and a 
> > managed bean. This is handled by a naming convention. The JSF viewId is 
> > normalized into a value that must have a corresponding managed. 
> > 
> > So if your target page was "/something.jsf", the ViewController should be 
> > registered as a managed bean by the name of "something". The default 
> > mapper, removes the suffix of the viewId and replaces the "/" with "$". You 
> > can override the default mapper if you want to create your own rules. 
> > 
> > 
> > Since your are using the tiger annotations (you also need shale-tiger 
> > besides shale-view and shale-core), you could register your ViewControllers 
> > as managed beans with the following annotation: 
> > 
> > @Bean(name = "something", scope = Scope.REQUEST) 
> > 
> > 
> > > 
> > > following is the web.xml file content 
> > > 
> > > 
> > > 
> > > thanks in advance 
> > 
> > 
> > Gary 
> > 

Re: specifying shale-tiger parsing classpath?

[Rahul Akolkar]

On 1/29/07, amjad Shahrour <[EMAIL PROTECTED]> wrote:

hi,

Can I instruct shale-tiger to parse only what i want, or maybe exclude paths
form being parsed.




You could use the "org.apache.shale.tiger.SCAN_PACKAGES" context
initialization parameter (in your application descriptor). Its a
comma-separated list that point to packages or jar files that should
be scanned. See this JIRA ticket [1] and this thread [2] from details.

-Rahul

[1] http://issues.apache.org/struts/browse/SHALE-301
[2] 
http://www.nabble.com/Shale-Tiger-Annotations-with-large-projects-t2809756.html



regards,
amjad

Re: My exception handling is broken

[Veit Guna]

Hi.

I encountered the same problem. I started development with
shale-1.0.4-SNAPHSOT a while ago and wrote my own ExceptionHandler, too.
 That worked so far. 3 weeks ago I upgraded to 1.0.4 and for example
acegi exceptions didn't get propagated anymore to its ExceptionFilter.
At this time I thought, it worked before because of a bug in the
SNAPSHOT release and that got fixed in the final 1.0.4. Something
changed in the way of handling exceptions I guess. I can't remember
exactly what I changed to get it running in 1.0.4 again, but it had
something todo with trowing exceptions.

In the past, I think the Shale Controller threw exceptions that were
queued up in the session under FacesConstants.EXCEPTIONS_LIST. Now this
isn't done anymore. I had to throw the exception explicitly in my shale
exception handler to get it propagated.

I would be also interested in what changed exactly and what's the right
way to handle exceptions in shale...

regards,
Veit




Ingo Düppe schrieb:
> Hi,
> 
> I guess I missed some changes in shale 1.0.4. I override the
> DefaultExceptionHandling so that my backing bean can throw to types of
> exceptions one of my ApplicationExceptions and the unchecked
> SystemExceptions. These two types were handled by the
> DefaultExceptionHandler. For instance, the application exception just
> ends up in an error message on the same view.
> 
> But now there is a responseComplete within the ShaleViewRoot (Is this
> class new?) that prevents the rendering after exception handling.
> 
> So, do I need to introduce my own ViewRoot component or what is the
> recommended way to handle my exceptions?
> 
> Regards
> Ingo
> 
> 

Re: My exception handling is broken

[Ingo Düppe]

Hi,

ok now I add my own ViewRoot:

    
     
javax.faces.ViewRoot
     
org.openuss.web.application.DefaultViewRoot
      

My DefaultViewRoot
class.

That do not set responseComplete if an exception occur. So my
ExceptionHandler can decide if it is an application exception occur 
just add an error message and if an unexpected exception occur add it
to the shale exception-list and redirect to the error page (with
responseComplete).

I'm not sure if this is the same as it is done by shale beside the
differentiation of application exceptions. 
So any comment are welcome.

Regards
Ingo



Veit Guna schrieb:

  Hi.

I encountered the same problem. I started development with
shale-1.0.4-SNAPHSOT a while ago and wrote my own ExceptionHandler, too.
 That worked so far. 3 weeks ago I upgraded to 1.0.4 and for example
acegi exceptions didn't get propagated anymore to its ExceptionFilter.
At this time I thought, it worked before because of a bug in the
SNAPSHOT release and that got fixed in the final 1.0.4. Something
changed in the way of handling exceptions I guess. I can't remember
exactly what I changed to get it running in 1.0.4 again, but it had
something todo with trowing exceptions.

In the past, I think the Shale Controller threw exceptions that were
queued up in the session under FacesConstants.EXCEPTIONS_LIST. Now this
isn't done anymore. I had to throw the exception explicitly in my shale
exception handler to get it propagated.

I would be also interested in what changed exactly and what's the right
way to handle exceptions in shale...

regards,
Veit




Ingo Düppe schrieb:
  
  
Hi,

I guess I missed some changes in shale 1.0.4. I override the
DefaultExceptionHandling so that my backing bean can throw to types of
exceptions one of my ApplicationExceptions and the unchecked
SystemExceptions. These two types were handled by the
DefaultExceptionHandler. For instance, the application exception just
ends up in an error message on the same view.

But now there is a responseComplete within the ShaleViewRoot (Is this
class new?) that prevents the rendering after exception handling.

So, do I need to introduce my own ViewRoot component or what is the
recommended way to handle my exceptions?

Regards
Ingo



  
  

  

Re: Mistake on Clay Info Page

[Rahul Akolkar]

On 2/5/07, Richard Eggert <[EMAIL PROTECTED]> wrote:

I'm not sure to whom to report this since no POC is listed on the Shale 
website, so hopefully the appropriate party will find this here.




If you're fairly confident about a bug / improvement, you can record it in JIRA:

http://issues.apache.org/struts/browse/SHALE



I just wanted to point out to whomever is responsible for the documentation on 
the Shale website that there's a mistake on the Clay main web page 
(http://shale.apache.org/shale-clay/index.html).




The Clay site was built by others (Gary et al), but I have applied
these fixes [1],[2]. Should be updated on the site shortly.

Thanks for pointing it out.

-Rahul

[1] http://svn.apache.org/viewvc?view=rev&revision=503878
[2] http://svn.apache.org/viewvc?view=rev&revision=503879



About 1/3 of the way down the page, there are two screen shots: one of an 
example page as an HTML mockup, and the other is the same page rendered using 
JSF+Clay.  According to the accompanying text, the first image should be that 
of the mockup, and the second image should be that of the rendered page.  
However, the two images are swapped (i.e., the first image is the rendered page 
and the second image is the mockup), presumably by mistake.

The section of the document to which I am referring can be located by searching for the 
text "You save that file, refresh the browser, and, as expected, you see this: 
(check the address bar - that's the HTML file)", which (ironically) precedes the 
image of the JSF-rendered page.

It's not a big issue, but it can be a bit confusing for somewhat who is trying 
to learn how Clay (and Shale in general) works!


Rich Eggert

Re: Mistake on Clay Info Page

[Torsten Krah]

Richard Eggert schrieb:

I'm not sure to whom to report this since no POC is listed on the Shale 
website, so hopefully the appropriate party will find this here.

I just wanted to point out to whomever is responsible for the documentation on the Shale website that there's a mistake on the Clay main web page (http://shale.apache.org/shale-clay/index.html).  

About 1/3 of the way down the page, there are two screen shots: one of an example page as an HTML mockup, and the other is the same page rendered using JSF+Clay.  According to the accompanying text, the first image should be that of the mockup, and the second image should be that of the rendered page.  However, the two images are swapped (i.e., the first image is the rendered page and the second image is the mockup), presumably by mistake.  


The section of the document to which I am referring can be located by searching for the 
text "You save that file, refresh the browser, and, as expected, you see this: 
(check the address bar - that's the HTML file)", which (ironically) precedes the 
image of the JSF-rendered page.

It's not a big issue, but it can be a bit confusing for somewhat who is trying 
to learn how Clay (and Shale in general) works!


Rich Eggert



Sure?
For me it seems all right.

The first is the mockup, the second image the rendered page, for me this 
seems all right.


Torsten

RE: Mistake on Clay Info Page

[Richard Eggert]

See Rahul Akolkar's reply regarding this.  He fixed it yesterday. :-)

Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com



-Original Message-
From: Torsten Krah [mailto:[EMAIL PROTECTED]
Sent: Mon 2/5/2007 11:24 PM
To: user@shale.apache.org
Subject: Re: Mistake on Clay Info Page
 
Richard Eggert schrieb:
> I'm not sure to whom to report this since no POC is listed on the Shale 
> website, so hopefully the appropriate party will find this here.
> 
> I just wanted to point out to whomever is responsible for the documentation 
> on the Shale website that there's a mistake on the Clay main web page 
> (http://shale.apache.org/shale-clay/index.html).  
> 
> About 1/3 of the way down the page, there are two screen shots: one of an 
> example page as an HTML mockup, and the other is the same page rendered using 
> JSF+Clay.  According to the accompanying text, the first image should be that 
> of the mockup, and the second image should be that of the rendered page.  
> However, the two images are swapped (i.e., the first image is the rendered 
> page and the second image is the mockup), presumably by mistake.  
> 
> The section of the document to which I am referring can be located by 
> searching for the text "You save that file, refresh the browser, and, as 
> expected, you see this: (check the address bar - that's the HTML file)", 
> which (ironically) precedes the image of the JSF-rendered page.
> 
> It's not a big issue, but it can be a bit confusing for somewhat who is 
> trying to learn how Clay (and Shale in general) works!
> 
> 
> Rich Eggert
> 

Sure?
For me it seems all right.

The first is the mockup, the second image the rendered page, for me this 
seems all right.

Torsten

Re: Running the shale integration tests

[Craig McClanahan]

On 2/8/07, Ryan Lubke <[EMAIL PROTECTED]> wrote:


Hello folks,

I've dug around on the wiki looking for information on running the
integration tests for Shale (itest), and from what I can tell, all I
really
need to set is the cargo property 'cargo.container.home'.

When I do this and run the tests, the integration tests fail.  No output
is provided that I've found useful (container.log has three lines, none
of them informative).

Anyone have some tips to get this going?



Sure ... thanks for asking here so we can get it on record :-).  Then, maybe
someone can snapshot this onto a wiki.

Background:  I have a personal bias that unit testing the individual classes
of a web application is necessary but not sufficient.  It is also important
to validate the runtime behavior of the dynamic system.  Therefore, the
Shale example and test applications support an optional "itest" (integration
test) profile that actually deploys a running instance of the app on a
Tomcat instance, and then uses an HtmlUnit based test environment to fire
off requests to the server and then examine the response.  HtmlUnit gives
you back a DOM view of the page, so you can examine the rendered output and
ensure that correct results were retrieved.

In order to run the "itest" profile, you must first have a Tomcat
5.5instance available.  Next, you must tell Maven2's "Cargo" plugin
where that
install is.  The easiest way I have found is to add the following snippet to
your user settings file (~/.m2/settings.xml):



 ...

 
   cargo-config
   
 /home/craigmcc/apache-tomcat-5.5.20

   
 

 ...



Now, from the top level directory of (say) the shale-usecases application, I
can say:

   mvn -Pitest clean install

and it will run the integration tests for this application (see sources in
src/test/java/.../systest) after the normal compile and unit test phases,
using the MyFaces 1.1 JSF implementation by default.

Separately, there are also profiles available (in the shale-apps POM) to
help you select which JSF implementation strategy you wish to use.  If your
own application uses this POM as a parent, you'll have the same features
available to you.  Choose your implementation as follows:

* Default (MyFaces 1.1):mvn clean install

* JSF 1.1 RI:  mvn -Djsf=ri clean install

* JSF 1.2 RI (included in the application):  mvn -Djsf=ri12 clean install

* JSF 1.2 (provided by the app server):  mvn -Djsf=ee5 clean install

I have tried the combination of RI 1.1 and the integration tests, but
haven't yet done so with the 1.2 variants ... I suspect we'll need a Cargo
setup for Servlet 2.5 / JSP 2.1 / JSF 1.2 type containers for this to work.

Craig




Thanks,


-rl

RE: Clay Using Taglibs (e.g validation)

[hermod.opstvedt]

Hi

You need to configure these as Clay components. Have a look at some of the Clay 
sample apps, specifically the clay-config.xml files. To integrate other libs, 
there must be a mapped clay-config file for them, or you need to run the 
Tld2ClayCfg tool on the tld files for these 3rd party libs. There is a sample 
app in the sandbox which demonstrates this.

A sample Clay component definition with validation (using commons validator) 
from the shale-clay-usecases:


















Hermod

-Original Message-
From: Bernhard Slominski [mailto:[EMAIL PROTECTED]
Sent: Friday, February 09, 2007 8:58 AM
To: user@shale.apache.org
Subject: Clay Using Taglibs (e.g validation)


Hi,

I want to use the Clay HTML views together with the Shale validation.
How do I integrate the taglib directive
<%@ taglib uri="http://shale.apache.org/core"; prefix="val" %>
into my HTML view?
How can I integrate other 3rd Party taglibs?

Bernhard



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

This email with attachments is solely for the use of the individual or
entity to whom it is addressed. Please also be aware that the DnB NOR Group
cannot accept any payment orders or other legally binding correspondence with
customers as a part of an email. 

This email message has been virus checked by the anti virus programs used
in the DnB NOR Group.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

RE: Strange Behavior with inputTextarea component

[hermod.opstvedt]

Hi

The magic is a missing attribute: allowBody


This 
is a mockup.


You can also use another Clay functionality




This is a mockup.




Hermod

-Original Message-
From: Richard Eggert [mailto:[EMAIL PROTECTED]
Sent: Monday, February 12, 2007 3:55 AM
To: user@shale.apache.org
Subject: Strange Behavior with inputTextarea component


I've been trying to teach myself how to use Clay (despite the atrocious lack of 
available documentation).  In the process of doing this, I put together a very 
simple "hello world" style application.  However, the behavior is not as 
expected, and I'm not sure whether I'm doing something wrong or there's an 
actual bug in Clay.

My welcome page, index.jsp, contains a redirect to /test.faces.

test.faces maps to test.jsp, which looks like this:

<%@ taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
<%@ taglib prefix="sh" uri="http://shale.apache.org/clay"; %>





test.html itself looks like this:

http://www.w3.org/TR/html4/strict.dtd'>


This is a test



This is a 
mockup.





When viewed in a browser or the "Preview" pane of the Amateras HTML editor, the 
HTML file is (correctly) rendered as a single TEXTAREA entity with the text 
"This is a mockup." as its contents.

My clay-config.xml looks like this:


http://shale.apache.org/dtds/clay-config_1_0.dtd";
>









When I deploy the application and load the page in my browser, the TEXTAREA is 
rendered with the text "Test was successful." as its contents (as expected), 
but the text "This is a mockup." also appears AFTER the TEXTAREA element as 
regular text, which seems like incorrect behavior.  Doing a "View Source" on 
the page yields the following:

http://www.w3.org/TR/html4/strict.dtd'>


This is a test



Test was successful.This is a mockup.





Is this a bug, or am I doing something wrong?  It doesn't seem like Clay should 
be moving the contents of a TEXTAREA such that it is rendered after the tag 
(causing it to appear as regular text).

I'm using Shale v1.04 with MyFaces 1.1.4 on Tomcat 5.5.




Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com




* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

This email with attachments is solely for the use of the individual or
entity to whom it is addressed. Please also be aware that DnB NOR cannot
accept any payment orders or other legally binding correspondence with
customers as a part of an email. 

This email message has been virus checked by the anti virus programs used
in the DnB NOR Group.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

RE: Strange Behavior with inputTextarea component

[Gary VanMatre]

>From: <[EMAIL PROTECTED]> 
>Hi
>The magic is a missing attribute: allowBody
>  
>   This 
> is a mockup.
>  
>
>
>You can also use another Clay functionality
>
 
Or, you can put this attribute in the XML config.
 


   


 
This was David Geary's idea originally.  I guess Tapestry has a similar 
concept.  
In the future, I'd like to provide a annotation replacement for this XML stuff.
 
After all, we need to keep up with Tapestry 5.
 
 
>
>
>   
>
>This is a mockup.
>
>   
>  
>
>Hermod

 

 
>From: Richard Eggert [mailto:[EMAIL PROTECTED]
>Sent: Monday, February 12, 2007 3:55 AM
>To: user@shale.apache.org
>Subject: Strange Behavior with inputTextarea component
>
>
>I've been trying to teach myself how to use Clay (despite the atrocious lack 
>of 
>available documentation).  
 

 
Well, I've been lobbying for some time for David to do some more writing on 
Clay.  The top half of the Clay site documentation was written by David.  I 
guess he's busy making money or something?
 
Anyway, *hopefully* the new Shale in Action book will have some material on 
Clay.
 
>In the process of doing this, I put together a very 
>simple "hello world" style application.  However, the behavior is not as 
>expected, and I'm not sure whether I'm doing something wrong or there's an 
>actual bug in Clay.
 

BTW, Hermod, thanks for all your help!
 
Gary

 

RE: Strange Behavior with inputTextarea component

[Richard Eggert]

Thanks.  That fixed the problem.  What I actually ended up doing was this:









This allows me to reuse the "de-bodified" textarea without any additional work. 
 

I'm not quite sure why this isn't the default behavior for inputTextarea, 
though.  What possible reason could there be for someone to want to use the 
current default behavior (i.e., to have the body contents rendered AFTER the 
, such that it becomes regular text when rendered, whereas it is the 
contents of a textarea field during mockup)?  If someone really wanted that to 
happen, they could write it that way in their original HTML.  It seems like it 
would save a lot of people some extra work if inputTextArea were defined with 
allowBody="false" set by default (still allowing allowBody="true" to be 
manually set by those weirdos that really want that behavior).

Anyway, thanks for your help! :-)


Rich Eggert
Member of Technical Staff
Proteus Technologies, LLC
http://www.proteus-technologies.com



-Original Message-
From: Gary VanMatre [mailto:[EMAIL PROTECTED]
Sent: Mon 2/12/2007 11:28 AM
To: user@shale.apache.org
Subject: RE: Strange Behavior with inputTextarea component
 
>From: <[EMAIL PROTECTED]> 
>Hi
>The magic is a missing attribute: allowBody
>  
>   This 
> is a mockup.
>  
>
>
>You can also use another Clay functionality
>
 
Or, you can put this attribute in the XML config.
 


   


 
This was David Geary's idea originally.  I guess Tapestry has a similar 
concept.  
In the future, I'd like to provide a annotation replacement for this XML stuff.
 
After all, we need to keep up with Tapestry 5.
 
 
>
>
>   
>
>This is a mockup.
>
>   
>  
>
>Hermod

 

 
>From: Richard Eggert [mailto:[EMAIL PROTECTED]
>Sent: Monday, February 12, 2007 3:55 AM
>To: user@shale.apache.org
>Subject: Strange Behavior with inputTextarea component
>
>
>I've been trying to teach myself how to use Clay (despite the atrocious lack 
>of 
>available documentation).  
 

 
Well, I've been lobbying for some time for David to do some more writing on 
Clay.  The top half of the Clay site documentation was written by David.  I 
guess he's busy making money or something?
 
Anyway, *hopefully* the new Shale in Action book will have some material on 
Clay.
 
>In the process of doing this, I put together a very 
>simple "hello world" style application.  However, the behavior is not as 
>expected, and I'm not sure whether I'm doing something wrong or there's an 
>actual bug in Clay.
 

BTW, Hermod, thanks for all your help!
 
Gary

 

Re: SV: Trouble with simple dialog

[Colin Chalmers]

Hi Hermod,

Thx for the reply.

The "Register" target is a copyPaste error, but even ommitting that 
transition doesn't affect the stack-trace.


I haven't defined the context-param you mention and was unaware that it 
was required, I thought the default setting was dialog?

Can you point me to info concerning this?

/Colin

Hermod Opstvedt wrote:


Hi

Just quickly looking at your dialog file, I notice that you have a target
"Register" that is not defined.

Looking at the code, the problem is that the web.xml context-param
Constants.DIALOG_PREFIX_PARAM is missing or ill defined. Have you defined
it?

Hermod


-Opprinnelig melding-
Fra: Colin Chalmers [mailto:[EMAIL PROTECTED] 
Sendt: 28. februar 2007 19:22

Til: user@shale.apache.org
Emne: Trouble with simple dialog

Hi,

I'm experimenting with the dialog manager and seem to have ommitted a 
setting somewhere which is throwing an exception.


Basically I'm just hitting one page and after clicking a button I should 
be brought to the next page, however this is not happening.

In the logs I see the following exception:


2007-02-28 15:53:54 StandardContext[/shale]null
java.lang.NullPointerException
   at 
org.apache.shale.dialog.faces.DialogNavigationHandler.handleNavigation(Dialo

gNavigationHandler.java:121)
   at 
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListen

erImpl.java:84)
   at 
org.apache.shale.view.faces.ViewActionListener.processAction(ViewActionListe

ner.java:74)
   at javax.faces.component.UICommand.broadcast(UICommand.java:106)
   at 
javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:94)
   at 
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:168)
   at 
org.apache.shale.view.faces.ShaleViewRoot.processApplication(ShaleViewRoot.j

ava:40)
   at 
org.apache.myfaces.lifecycle.LifecycleImpl.invokeApplication(LifecycleImpl.j

ava:316)
   at 
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:86)

   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:137)
   at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application

FilterChain.java:237)
   at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh

ain.java:157)
   at 
org.apache.shale.application.faces.ShaleApplicationFilter.doFilter(ShaleAppl

icationFilter.java:267)
   at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application

FilterChain.java:186)
   at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh

ain.java:157)
   at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja

va:214)
   at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex

t.java:104)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
   at 
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContext

Valve.java:198)
   at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja

va:152)
   at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex

t.java:104)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
   at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137

)
   at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex

t.java:104)
   at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118

)
   at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex

t.java:102)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
   at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java

:109)
   at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex

t.java:104)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)

   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
   at 
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
   at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
   at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne

ction(Http11Protocol.java:705)
   at 
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
   at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav

a:683)
   at java.lang.Thread.run(Thread.java:534)


My dialog-config files looks like the following


 
   

   
  
 

  
  
   
 




& th epage itself contains

   
   

   

Currently I've no idea why it's not working :-((

Any help or links to examples would be much appreciated!!

Thx

/Colin




 

Re: SV: Trouble with simple dialog

[Colin Chalmers]

Hermod,

Sorry I see the info on the site. As far as I see I haven't deviated 
from the default dialog:foo type of value?


Are there any other params and/or phase-listeners I should be aware of?

For the sake of clarity I'm using version 1.0.4

/Colin

Hermod Opstvedt wrote:


Hi

Just quickly looking at your dialog file, I notice that you have a target
"Register" that is not defined.

Looking at the code, the problem is that the web.xml context-param
Constants.DIALOG_PREFIX_PARAM is missing or ill defined. Have you defined
it?

Hermod


-Opprinnelig melding-
Fra: Colin Chalmers [mailto:[EMAIL PROTECTED] 
Sendt: 28. februar 2007 19:22

Til: user@shale.apache.org
Emne: Trouble with simple dialog

Hi,

I'm experimenting with the dialog manager and seem to have ommitted a 
setting somewhere which is throwing an exception.


Basically I'm just hitting one page and after clicking a button I should 
be brought to the next page, however this is not happening.

In the logs I see the following exception:


2007-02-28 15:53:54 StandardContext[/shale]null
java.lang.NullPointerException
   at 
org.apache.shale.dialog.faces.DialogNavigationHandler.handleNavigation(Dialo

gNavigationHandler.java:121)
   at 
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListen

erImpl.java:84)
   at 
org.apache.shale.view.faces.ViewActionListener.processAction(ViewActionListe

ner.java:74)
   at javax.faces.component.UICommand.broadcast(UICommand.java:106)
   at 
javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:94)
   at 
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:168)
   at 
org.apache.shale.view.faces.ShaleViewRoot.processApplication(ShaleViewRoot.j

ava:40)
   at 
org.apache.myfaces.lifecycle.LifecycleImpl.invokeApplication(LifecycleImpl.j

ava:316)
   at 
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:86)

   at javax.faces.webapp.FacesServlet.service(FacesServlet.java:137)
   at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application

FilterChain.java:237)
   at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh

ain.java:157)
   at 
org.apache.shale.application.faces.ShaleApplicationFilter.doFilter(ShaleAppl

icationFilter.java:267)
   at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Application

FilterChain.java:186)
   at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterCh

ain.java:157)
   at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.ja

va:214)
   at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex

t.java:104)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
   at 
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContext

Valve.java:198)
   at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.ja

va:152)
   at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex

t.java:104)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
   at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137

)
   at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex

t.java:104)
   at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118

)
   at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex

t.java:102)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)
   at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java

:109)
   at 
org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContex

t.java:104)
   at 
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520)

   at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929)
   at 
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160)
   at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799)
   at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConne

ction(Http11Protocol.java:705)
   at 
org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577)
   at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.jav

a:683)
   at java.lang.Thread.run(Thread.java:534)


My dialog-config files looks like the following


 
   

   
  
 

  
  
   
 




& th epage itself contains

   
   

   

Currently I've no idea why it's not working :-((

Any help or links to examples would be much appreciated!!

Thx

/Colin




 

RE: view controller – site navig ation

[hermod.opstvedt]

Hi

I think the best way to achieve what you want is to raise a flag in the 
viewcontrollers init method. Then when the method that is supposed to be 
executed is called, you check for the flag at the beginning and return the 
outcome that corresponds to the error situatiuon.


-Original Message-
From: gerrit [mailto:[EMAIL PROTECTED]
Sent: Friday, March 02, 2007 9:51 AM
To: user@shale.apache.org
Subject: view controller – site navigation



I use the shale view controller init() method to make standard site
validations and load data. 
The init-Method has no return value and so no navigation rule is executed.
If one of my validation methods or the load data method returns an error I’d
like execute navigation rules. The reason is to go to a special error page.
Is there a possibility to navigate to another page from the init-method? 

-- 
View this message in context: 
http://www.nabble.com/view-controller-%E2%80%93-site-navigation-tf3332431.html#a9266099
Sent from the Shale - User mailing list archive at Nabble.com.



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

This email with attachments is solely for the use of the individual or
entity to whom it is addressed. Please also be aware that DnB NOR cannot
accept any payment orders or other legally binding correspondence with
customers as a part of an email. 

This email message has been virus checked by the anti virus programs used
in the DnB NOR Group.

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

Re: [shale-validator] Shale sub dialog

[Pich]

Hi!

You understood my purpose of the common dialog correct, using it as a
subdialog from any other calling dialog. I now changed the "common.confirm"
dialog to this (I hope I understood your suggestion correctly):


















However, this hade no impact and I still ended up on dummy.jsp when clicking
the button resulting in transition "confirm" on view
"/transfer_register_confirmtransfer.jsp", and not (as I wanted) in the
"executeTransferAction" action in the calling dialog. Do you think this is a
bug?

Regards

Pich





craigmcc wrote:
> 
> On 3/9/07, Pich <[EMAIL PROTECTED]> wrote:
>>
>> Hi, I have a question regarding Shale sub dialog.
>>
>> I have these to dialogs:
>>
>> ..
>> ..
>> > method="#{performTransferUseCaseBean.prepareConfirmTransfer}">
>> > target="confirmTransferSub"/>
>> > target="performTransferView"/>
>> 
>>
>> > dialogName="common.confirm">
>> > target="executeTransferAction"/>
>> > target="performTransferView"/>
>> > target="cancelTransferEnd"/>
>> > outcome="dialog:transfer.performTransfer"
>> target="prepareNewTransferAction"/>
>> 
>>
>> > method="#{performTransferUseCaseBean.executeTransfer}">
>> > target="receiptTransferView"/>
>> > target="confirmTransferView"/>
>> 
>> ..
>> ..
>>
>>
>> 
>>
>> > viewId="/transfer_register_confirmtransfer.jsp">
>> 
>> 
>> 
>> > outcome="dialog:transfer.performTransfer" target="dummyEnd"/>
>> 
>>
>> 
>>
>> 
>>
>>
>> The problem is that when the subdialog reaches the dialog "confirm" the
>> transition outcome does go back up to the calling dialog. For example, if
>> view name "confirm" get transition outcome "confirm" page dummy.jsp is
>> shown, and not executeTransferAction which I want.
>>
> 
> It looks like there's an issue with the end state of the subdialog.
> What appears to be happening is that the dialog manager:
> * Sees the "confirm" response from state "confirm" in the subdialog
> * Transitions to "dummyEnd"
> * Sees that this is an end state, so it exits
>   instead of displaying the associated view,
>   returning the same outcome that it was
>   entered with "confirm"
> * This outcome is then used to drive the
>   transition from the "confirmTransferSub"
>   state.
> 
>> I had this working with Shale 1.0, but since i upgraded to Shale 1.1.0 I
>> have not been able to get this to work. Has anybody else this problem?
> 
> The dialog functionality was substantially changed between 1.0.3 and
> 1.0.4, so it looks like we introduced a behavior change.  I presume
> what you're really after is showing the confirmation dialog page
> before returning to whatever main dialog called it (this is precisely
> the kind of use case subdialogs were designed to support)?  If so, try
> making  what is now the "dummyEnd" state a  state instead of an
> "" state, and have it transition to an end state next.
> 
> If that works, we'll probably need to review how end states are being
> processed to see what happened to the view id at that point.  If it
> doesn't work, then we'll definitely need a bug report so we can get
> this addressed.
> 
> Craig
> 
> 
>>
>> Regards
>>
>> Pich
>> --
>> View this message in context:
>> http://www.nabble.com/Shale-sub-dialog-tf3376354.html#a9396652
>> Sent from the Shale - User mailing list archive at Nabble.com.
>>
>>
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Shale-sub-dialog-tf3376354.html#a9429909
Sent from the Shale - User mailing list archive at Nabble.com.

Re: [shale-validator] Shale sub dialog

[Craig McClanahan]

On 3/12/07, Pich <[EMAIL PROTECTED]> wrote:


Hi!

You understood my purpose of the common dialog correct, using it as a
subdialog from any other calling dialog. I now changed the "common.confirm"
dialog to this (I hope I understood your suggestion correctly):

   

   
   
   
   
   
   

   
   
   

   

   

However, this hade no impact and I still ended up on dummy.jsp when clicking
the button resulting in transition "confirm" on view
"/transfer_register_confirmtransfer.jsp", and not (as I wanted) in the
"executeTransferAction" action in the calling dialog. Do you think this is a
bug?


Yes, this definitely sounds like a bug.  Could you file an issue in
our tracking system[1], please?  Your example use case will be helpful
in tracking it down.

Craig

[1] https://issues.apache.org/struts/browse/SHALE



Regards

Pich





craigmcc wrote:
>
> On 3/9/07, Pich <[EMAIL PROTECTED]> wrote:
>>
>> Hi, I have a question regarding Shale sub dialog.
>>
>> I have these to dialogs:
>>
>> ..
>> ..
>> > method="#{performTransferUseCaseBean.prepareConfirmTransfer}">
>> > target="confirmTransferSub"/>
>> > target="performTransferView"/>
>> 
>>
>> > dialogName="common.confirm">
>> > target="executeTransferAction"/>
>> > target="performTransferView"/>
>> > target="cancelTransferEnd"/>
>> > outcome="dialog:transfer.performTransfer"
>> target="prepareNewTransferAction"/>
>> 
>>
>> > method="#{performTransferUseCaseBean.executeTransfer}">
>> > target="receiptTransferView"/>
>> > target="confirmTransferView"/>
>> 
>> ..
>> ..
>>
>>
>> 
>>
>> > viewId="/transfer_register_confirmtransfer.jsp">
>> 
>> 
>> 
>> > outcome="dialog:transfer.performTransfer" target="dummyEnd"/>
>> 
>>
>> 
>>
>> 
>>
>>
>> The problem is that when the subdialog reaches the dialog "confirm" the
>> transition outcome does go back up to the calling dialog. For example, if
>> view name "confirm" get transition outcome "confirm" page dummy.jsp is
>> shown, and not executeTransferAction which I want.
>>
>
> It looks like there's an issue with the end state of the subdialog.
> What appears to be happening is that the dialog manager:
> * Sees the "confirm" response from state "confirm" in the subdialog
> * Transitions to "dummyEnd"
> * Sees that this is an end state, so it exits
>   instead of displaying the associated view,
>   returning the same outcome that it was
>   entered with "confirm"
> * This outcome is then used to drive the
>   transition from the "confirmTransferSub"
>   state.
>
>> I had this working with Shale 1.0, but since i upgraded to Shale 1.1.0 I
>> have not been able to get this to work. Has anybody else this problem?
>
> The dialog functionality was substantially changed between 1.0.3 and
> 1.0.4, so it looks like we introduced a behavior change.  I presume
> what you're really after is showing the confirmation dialog page
> before returning to whatever main dialog called it (this is precisely
> the kind of use case subdialogs were designed to support)?  If so, try
> making  what is now the "dummyEnd" state a  state instead of an
> "" state, and have it transition to an end state next.
>
> If that works, we'll probably need to review how end states are being
> processed to see what happened to the view id at that point.  If it
> doesn't work, then we'll definitely need a bug report so we can get
> this addressed.
>
> Craig
>
>
>>
>> Regards
>>
>> Pich
>> --
>> View this message in context:
>> http://www.nabble.com/Shale-sub-dialog-tf3376354.html#a9396652
>> Sent from the Shale - User mailing list archive at Nabble.com.
>>
>>
>
>

--
View this message in context: 
http://www.nabble.com/Shale-sub-dialog-tf3376354.html#a9429909
Sent from the Shale - User mailing list archive at Nabble.com.

SV: SV: Re: basic dialog nullpointerexception

[Hermod Opstvedt]

Hi

Try it with jdk 1.4 on 5.5.23 and see what happens then.

Hermod


-Opprinnelig melding-
Fra: Veit Guna [mailto:[EMAIL PROTECTED] 
Sendt: 14. mars 2007 23:06
Til: user@shale.apache.org
Emne: Re: SV: Re: basic dialog nullpointerexception

Hi.

After I switched my local project to another version (different
workspace), it indeeded stopped working with 5.5.23. But it worked
before with 5.5.23. I don't know what it blew up.

So that means, listeners in tlds only work up to tomcat 5.5.17? But it
didn't work out with my 5.5.17 version. Strange thing. Meanwhile I think
perhaps it's a problem with eclipse wtp and tomcat. Never tried it with
tomcat standalone. Did you?

BTW: I'm using Java5.

regards,
Veit


Hermod Opstvedt schrieb:
> Hi
> 
> The last working version of Tomcat is actually 5.5.17 with Java5. If you
> switch to Java 1.4 things are different.
> 
> There is a post by me on this, where I went through and tested on all
5.5.x
> versions, and things stopped working after 5.5.17
> 
> Hermod
> 
> 
> -Opprinnelig melding-
> Fra: Veit Guna [mailto:[EMAIL PROTECTED] 
> Sendt: 12. mars 2007 20:34
> Til: user@shale.apache.org
> Emne: SV: Re: basic dialog nullpointerexception
> 
> Hi again.
> 
> I upgraded my Tomcat 5.5.17 installation (it wasn't 5.5.16) to tomcat
5.5.23
> and now the BasicLifecycleListener gets invoked.
> 
> Seemed to be a problem with tomcat?!
> 
> Regards,
> Veit
> 
> 
>  Original-Nachricht 
> Datum: Mon, 12 Mar 2007 13:41:26 +0100
> Von: "Veit Guna" <[EMAIL PROTECTED]>
> An: user@shale.apache.org
> CC: 
> Betreff: Re: basic dialog nullpointerexception
> 
>> I'm using tomcat 5.5.16.
>>
>>
>> ---- Original-Nachricht 
>> Datum: Mon, 12 Mar 2007 05:31:50 -0700
>> Von: "Craig McClanahan" <[EMAIL PROTECTED]>
>> An: user@shale.apache.org
>> CC: 
>> Betreff: Re: basic dialog nullpointerexception
>>
>>> On 3/12/07, Veit Guna <[EMAIL PROTECTED]> wrote:
>>>> Hi.
>>>>
>>>> I'm trying to get the basic dialog feature of shale 1.0.4 working.
>> I've
>>> added the jars view, dialog, basic-dialog, core to my classpath and
>> created
>>> a dialog xml file in WEB-INF. Now when I try in a h:commandLink an
>> action
>>> like "dialog:myDialog" a NullPointerException occurs:
>>>> java.lang.NullPointerException
>>>>at
>>>>
>
org.apache.shale.dialog.basic.BasicDialogManager.create(BasicDialogManager.j
> ava:97)
>>>>at
>>>>
>
org.apache.shale.dialog.basic.BasicDialogManager.create(BasicDialogManager.j
> ava:87)
>>>>at
>>>>
>
org.apache.shale.dialog.faces.DialogNavigationHandler.handleNavigation(Dialo
> gNavigationHandler.java:121)
>>>>at
>>>>
>
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListen
> erImpl.java:84)
>>>>at
>>>>
>
org.apache.shale.view.faces.ViewActionListener.processAction(ViewActionListe
> ner.java:74)
>>>>at
>>>> ...
>>>>
>>>> I've taken a look at the BasicDialogManager. It tries to use an
>>> uninitialized Map. I guess it should be initialized by the
>> BasicLifecycleListener
>>> but it isn't. Any hints, what I've forgotten?
>>>> Do I have to put the BasicLifecycleListener somewhere manually?
>>> In general, you should *not* have to configure this listener manually.
>>>  It is registered in a listener defined in the
>>> shale-dialog-basic-xxx.jar file that you're including.  However, not
>>> all containers properly implement registering listeners in a TLD
>>> inside a JAR file.  What container and version are you running on?
>>>
>>> Craig
>>>
>>>> Regards,
>>>> Veit
>>>>
>>>> --
>>>> "Feel free" - 5 GB Mailbox, 50 FreeSMS/Monat ...
>>>> Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out
>>>>
>> -- 
>> Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
>> Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
> 

Re: SV: URLs and backing beans

[Brad Smith]

Thank you for the reply Hermod.

I should have added that in response to a url such as those in the
original post, the application would return a web page with a list of
projects that are active at each office.  The goal is to have a
bookmarkable URL without creating separate view controllers for each
office (on the order of 1000).

Brad


On Sat, 2007-03-24 at 16:43 +0100, Hermod Opstvedt wrote:
> Hi
> 
> I'm not shure what you are looking for her but his is my understanding of
> it.
> 
> Why would you want a backing bean for this? This is more the responsibility
> of an ApplicationController. What I would do is to subclass the Shale
> Aplication controller and add the logic you want there. You can use the
> filter mappings to control what gets routed to you
> 
> Backing beans (I take it you mean ViewControllers) are mapped against views
> i.e page2.jsf, page2.jsf and so on.
> 
> Hermod
> 
> -Opprinnelig melding-
> Fra: Brad Smith [mailto:[EMAIL PROTECTED] 
> Sendt: 24. mars 2007 15:36
> Til: user@shale.apache.org
> Emne: URLs and backing beans
> 
> I have an application which needs to handle urls that have the following
> patterns:
> 
> http://localhost:8080/myapp/projects/office1
> 
> http://localhost:8080/myapp/projects/office2
> 
> http://localhost:8080/myapp/projects/office2/subofficeA
> 
> Conceptually I would like the request to be routed to a single backing
> bean called Projects that would use the URL content after ../projects/..
> to determine what the response should be.
> 
> Are there features in Shale which would make this possible? Is this
> where the Application Manager would come into play?
> 
> 
> 
> Thank you,
> 
> Brad
> 
>