Re: [OT] Kaolin proposal at [EMAIL PROTECTED]

[Antonio Petrelli]

Never mind, we are going to use the normal IP clearance.

Thanks anyway
Antonio

2008/1/27, Antonio Petrelli <[EMAIL PROTECTED]>:
>
> Hi all,
> I wish to let you know an ongoing discussion at [EMAIL PROTECTED]
> about Kaolin, the new name for Dimensions, a Tiles extension to help
> building multi-user and multi-device web applications.
>
> Proposal:
> http://wiki.apache.org/incubator/KaolinProposal
>
> Discussion thread:
>
> http://www.nabble.com/-PROPOSAL--Kaolin-%28renamed-from-Dimensions%29-to15073525.html#a15073525
>
> Original site:
> http://mutidimensions.sourceforge.net/
>
> I know that I already asked this thing before, but I am in search for
> a Champion. If any member of the ASF reading here is willing to help,
> please let me know.
>
> Thank you.
> Antonio
>

Struts tags and Filter Dispatcher Url Pattern-struts 2.1.1

[Sanjeev Vijapurapu]

Hi,

I have recently upgraded to struts 2.1.1 and if my struts filter
dispatcher url pattern is not "/*" instead it is "/actions/*,
/struts/*".

And now if I am trying to access a jsp page that is not under that url
pattern ( something like /test.jsp), struts tags in that jsp page fail.

I get the following stack trace

 

java.lang.NullPointerException
at
org.apache.struts2.views.jsp.TagUtils.getStack(TagUtils.java:55)
at
org.apache.struts2.views.jsp.StrutsBodyTagSupport.getStack(StrutsBodyTag
Support.java:46)
at
org.apache.struts2.views.jsp.ComponentTagSupport.doStartTag(ComponentTag
Support.java:47)
at
org.apache.jsp.test_jsp._jspx_meth_sx_head_0(org.apache.jsp.test_jsp:95)
at
org.apache.jsp.test_jsp._jspService(org.apache.jsp.test_jsp:65)
at
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:93)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.ja
va:373)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:470)
at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:364)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
 
So does this mean that if my jsp is using struts tags, it has to go
through filter dispatcher?
 
Thanks

 

DO NOT REPLY [Bug 18799] - using with a global-forward to a tile

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=18799





--- Additional Comments From [EMAIL PROTECTED]  2008-01-31 10:30 ---
This problem still occurs with Struts 1.3.8.

I cannot find the "note in the docs". Can you please reply with a pointer to it?

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: cwiki access?

[Philip Luppens]

Yup:

http://monitoring.apache.org/status/

- Phil

On 1/31/08, Dave Newton <[EMAIL PROTECTED]> wrote:
> Is anybody else having issues editing wiki pages right now?
>
> Dave
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-- 
Software Architect - Hydrodesk
"Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live." - John F. Woods

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

cwiki access?

[Dave Newton]

Is anybody else having issues editing wiki pages right now? 

Dave



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[S2.1] Proposal for additional attribute on s:tree for dynamic trees.

[Al Sutton]

I'm throwing this idea out there for comments, so please let me know what 
you think.


Problem : As things currently stand you can specify a child icon for a 
static tree node using childIconSrc. If you're creating a dynamic tree there 
is no method of specifying the icon for each node.


Proposal : Add a nodeIconSrcParameter attribute to s:tree which would 
specify a method to call in a node object which would return icon source. 
Each node in the dynamic tree can then control the icon it wants to display.


What do people think?

Al. 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2.1] Dojo plugin tree problem

[Al Sutton]

Ouch. I can now see why your patch seems the only sensible solution.

Al.

- Original Message - 
From: "Jeromy Evans" <[EMAIL PROTECTED]>

To: "Struts Developers List" 
Sent: Thursday, January 31, 2008 10:03 AM
Subject: Re: [S2.1] Dojo plugin tree problem



Hi Al,

Yes, I agree.  For instance, the patch only applies to AbstractRemoteBean 
whereas the issue encroaches on Tree.java and probably others.


The issue is slightly bigger than just forgetting the head tag.  It is 
specifically that:

- the dojo tags now depends on a head tag writing to the page context; but
- in certain cases the head tag cannot be included within the context 
available to the current tag


eg. If the tag is in a JSP loaded via XHR, the JSP fragment can't 
contain -another- head tag so an NPE will occur when that fragment is 
rendered


Al Sutton wrote:

Jeromy,

I like your solution, but I think a call needs to be made by the 
developers who have been here longer (and therefore have a better view of 
the big picture).


Either your patch should be applied, or a more friendly way of 
automatically saying "You've forgotten the <:head> tag" needs to be 
developed, because I believe the current situation creates an error which 
is too obscure for the average developer to easily discover what the 
problem is.


Anyone have any other thoughts?

Al.

- Original Message - From: "Jeromy Evans" 
<[EMAIL PROTECTED]>

To: "Struts Developers List" 
Sent: Thursday, January 31, 2008 12:08 AM
Subject: Re: [S2.1] Dojo plugin tree problem



Al,

There is indeed a related bug, but the issue is only realized when the 
head tag CANNOT be processed within the current page context.

(eg. within a fragment loaded via XHR)

https://issues.apache.org/struts/browse/WW-2398

regards,
Jeromy Evans


Musachy Barroso wrote:

you are missing sd:head on the page.

musachy

On Jan 30, 2008 12:50 PM, Al Sutton <[EMAIL PROTECTED]> wrote:

I think I've found a problem in the dojo plugin but I'd like someone 
to
double check I'm not doing anything whacky before raising a JIRA 
ticket.


I've got a webapp with the latest snapshots of core and dojo plugin. I 
also

have a jsp with;

<[EMAIL PROTECTED] prefix="sd" uri="/struts-dojo-tags"%>


  

When I try to load the page I get an NPE on line 257 of Tree.java 
which is;


boolean generateId =
!(Boolean)stack.getContext().get(Head.PARSE_CONTENT);


from what I can tell stack.getContext().get(Head.PARSE_CONTENT) 
returns a
null instead of a default value, and thus the !. with autoboxing 
of the

boolean causes the NPE.

Is there suppose to be a default set or have I missed a step which 
would set

this up?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]











-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2.1] Dojo plugin tree problem

[Jeromy Evans]

Hi Al,

Yes, I agree.  For instance, the patch only applies to 
AbstractRemoteBean whereas the issue encroaches on Tree.java and 
probably others.


The issue is slightly bigger than just forgetting the head tag.  It is 
specifically that:

- the dojo tags now depends on a head tag writing to the page context; but
- in certain cases the head tag cannot be included within the context 
available to the current tag


eg. If the tag is in a JSP loaded via XHR, the JSP fragment can't 
contain -another- head tag so an NPE will occur when that fragment is 
rendered


Al Sutton wrote:

Jeromy,

I like your solution, but I think a call needs to be made by the 
developers who have been here longer (and therefore have a better view 
of the big picture).


Either your patch should be applied, or a more friendly way of 
automatically saying "You've forgotten the <:head> tag" needs to be 
developed, because I believe the current situation creates an error 
which is too obscure for the average developer to easily discover what 
the problem is.


Anyone have any other thoughts?

Al.

- Original Message - From: "Jeromy Evans" 
<[EMAIL PROTECTED]>

To: "Struts Developers List" 
Sent: Thursday, January 31, 2008 12:08 AM
Subject: Re: [S2.1] Dojo plugin tree problem



Al,

There is indeed a related bug, but the issue is only realized when 
the head tag CANNOT be processed within the current page context.

(eg. within a fragment loaded via XHR)

https://issues.apache.org/struts/browse/WW-2398

regards,
Jeromy Evans


Musachy Barroso wrote:

you are missing sd:head on the page.

musachy

On Jan 30, 2008 12:50 PM, Al Sutton <[EMAIL PROTECTED]> wrote:

I think I've found a problem in the dojo plugin but I'd like 
someone to
double check I'm not doing anything whacky before raising a JIRA 
ticket.


I've got a webapp with the latest snapshots of core and dojo 
plugin. I also

have a jsp with;

<[EMAIL PROTECTED] prefix="sd" uri="/struts-dojo-tags"%>


  

When I try to load the page I get an NPE on line 257 of Tree.java 
which is;


boolean generateId =
!(Boolean)stack.getContext().get(Head.PARSE_CONTENT);


from what I can tell stack.getContext().get(Head.PARSE_CONTENT) 
returns a
null instead of a default value, and thus the !. with 
autoboxing of the

boolean causes the NPE.

Is there suppose to be a default set or have I missed a step which 
would set

this up?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]











-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [struts-dev] [S2.1] One Step On.... the Dojo plugin tree problem

[Al Sutton]

Dale,

Thanks for the tips. I've updated the ftl file with a default that works 
with a null returned by the child property, so I'll be putting a patch into 
JIRA.


Al.

- Original Message - 
From: "Dale Newfield" <[EMAIL PROTECTED]>

To: "Struts Developers List" 
Sent: Wednesday, January 30, 2008 8:07 PM
Subject: Re: [struts-dev] [S2.1] One Step On the Dojo plugin tree 
problem




Dale Newfield wrote:
A previous example has a three character solution: 
https://issues.apache.org/struts/browse/WW-2383 , for this one it appears 
that a single "!" may be sufficient.


Excerpted from 
: 
If the default value is omitted, then it will be empty string and empty 
sequence and empty hash at the same time.


Now that I read it again, the single character addition would probably 
have been sufficient for the previous bug, too.  If we want to be 
explicit, I think "![]" will use an empty sequence as the default value 
here, but it seems unnecessary (and from the docs I'm still unclear 
whether that syntax is valid).


-Dale

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [S2.1] Dojo plugin tree problem

[Al Sutton]

Jeromy,

I like your solution, but I think a call needs to be made by the developers 
who have been here longer (and therefore have a better view of the big 
picture).


Either your patch should be applied, or a more friendly way of automatically 
saying "You've forgotten the <:head> tag" needs to be developed, because I 
believe the current situation creates an error which is too obscure for the 
average developer to easily discover what the problem is.


Anyone have any other thoughts?

Al.

- Original Message - 
From: "Jeromy Evans" <[EMAIL PROTECTED]>

To: "Struts Developers List" 
Sent: Thursday, January 31, 2008 12:08 AM
Subject: Re: [S2.1] Dojo plugin tree problem



Al,

There is indeed a related bug, but the issue is only realized when the 
head tag CANNOT be processed within the current page context.

(eg. within a fragment loaded via XHR)

https://issues.apache.org/struts/browse/WW-2398

regards,
Jeromy Evans


Musachy Barroso wrote:

you are missing sd:head on the page.

musachy

On Jan 30, 2008 12:50 PM, Al Sutton <[EMAIL PROTECTED]> wrote:


I think I've found a problem in the dojo plugin but I'd like someone to
double check I'm not doing anything whacky before raising a JIRA ticket.

I've got a webapp with the latest snapshots of core and dojo plugin. I 
also

have a jsp with;

<[EMAIL PROTECTED] prefix="sd" uri="/struts-dojo-tags"%>


  

When I try to load the page I get an NPE on line 257 of Tree.java which 
is;


boolean generateId =
!(Boolean)stack.getContext().get(Head.PARSE_CONTENT);


from what I can tell stack.getContext().get(Head.PARSE_CONTENT) returns 
a
null instead of a default value, and thus the !. with autoboxing of 
the

boolean causes the NPE.

Is there suppose to be a default set or have I missed a step which would 
set

this up?


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]











-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]