Re: 5.4 Upload / Long Response Issue?

[Michael Gentry]

More information:

When running from Terminal with "mvn jetty:run" or from within Eclipse
using the M2E plugin (Run or Debug mode), it will create extra threads.
 When running from within Eclipse using RunJettyRun (Run or Debug mode), no
extra threads are created and it works perfectly.

Could be the Maven plugin, perhaps.



On Thu, Aug 28, 2014 at 4:17 PM, Michael Gentry 
wrote:

> I can try Tomcat, but i'll be a day or two or so before I can get to that.
>
> mrg
>
>
>
> On Thu, Aug 28, 2014 at 3:35 PM, Lance Java 
> wrote:
>
>> Totally weird, can you try deploying to tomcat? It's worth a try to see if
>> an issue with jetty.
>>  On 28 Aug 2014 19:36, "Michael Gentry"  wrote:
>>
>> > Hi again Lance,
>> >
>> > 1) No proxy.  Directly connecting to Jetty @ http://localhost:6789/
>> >
>> > 2) No other filters.  I'm using Tapestry's IOC for services and trying
>> to
>> > keep things lean.
>> >
>> > FWIW, when I dropped the file in as a unit test, it would import just
>> fine
>> > using the T5 service without spawning extra threads, so I don't think
>> it is
>> > related to the T5 service itself (which make's sense, since the
>> > onValidate/onSuccess events are being triggered more than once).
>> >
>> > Thanks,
>> >
>> > mrg
>> >
>> >
>> >
>> > On Thu, Aug 28, 2014 at 2:05 PM, Lance Java 
>> > wrote:
>> >
>> > > 1.Is your app sitting behind a proxy? (eg apache?).
>> > >
>> > > 2. Are there any other servlet filters we should know about? (eg
>> spring?)
>> > >
>> >
>>
>
>

Re: 5.4 Upload / Long Response Issue?

[Michael Gentry]

I can try Tomcat, but i'll be a day or two or so before I can get to that.

mrg



On Thu, Aug 28, 2014 at 3:35 PM, Lance Java 
wrote:

> Totally weird, can you try deploying to tomcat? It's worth a try to see if
> an issue with jetty.
>  On 28 Aug 2014 19:36, "Michael Gentry"  wrote:
>
> > Hi again Lance,
> >
> > 1) No proxy.  Directly connecting to Jetty @ http://localhost:6789/
> >
> > 2) No other filters.  I'm using Tapestry's IOC for services and trying to
> > keep things lean.
> >
> > FWIW, when I dropped the file in as a unit test, it would import just
> fine
> > using the T5 service without spawning extra threads, so I don't think it
> is
> > related to the T5 service itself (which make's sense, since the
> > onValidate/onSuccess events are being triggered more than once).
> >
> > Thanks,
> >
> > mrg
> >
> >
> >
> > On Thu, Aug 28, 2014 at 2:05 PM, Lance Java 
> > wrote:
> >
> > > 1.Is your app sitting behind a proxy? (eg apache?).
> > >
> > > 2. Are there any other servlet filters we should know about? (eg
> spring?)
> > >
> >
>

Re: Unit test component with request parameter

[Lance Java]

Looks like you've put a lot of thought into your urls.

> It would end up looking something like this.
domain.com

/category/make/$N/$N/$N/$N/$N/$N/$N/$N/$N/$N/brown


Haha... yeah... It's not suited to this use case. It works better when
there can only be trailing nulls (which don't appear in the url).

Re: Unit test component with request parameter

[Thiago H de Paula Figueiredo]

On Thu, 28 Aug 2014 16:27:20 -0300, George Christman  
 wrote:


Your absolutely correct, context URLs are much better for SEO than  
request

parameters. I tend to use both at the same time, example
domain/category?make=ford, category being the context. I think what  
you've
done is a cool idea, however with the amount of filters that we will end  
up
having, it would get real messy when they are mostly all null. It would  
end

up looking something like this.
domain.com/category/make/$N/$N/$N/$N/$N/$N/$N/$N/$N/$N/brown


You can avoid the $N by providing your own  
org.apache.tapestry5.services.URLEncoder.



Some of the newer stuff I have planned will look something like this.
http://www.cardaddy.com/used-cars/2011-toyota-corolla-le-albany-ny-12205-4978?_rd=50&color=brown


You could also map the other parameters into a single string and pass it  
as an activation context value. In this case, you'd need to do the string  
<-> parameters map yourself.


--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: 5.4 Upload / Long Response Issue?

[Lance Java]

Totally weird, can you try deploying to tomcat? It's worth a try to see if
an issue with jetty.
 On 28 Aug 2014 19:36, "Michael Gentry"  wrote:

> Hi again Lance,
>
> 1) No proxy.  Directly connecting to Jetty @ http://localhost:6789/
>
> 2) No other filters.  I'm using Tapestry's IOC for services and trying to
> keep things lean.
>
> FWIW, when I dropped the file in as a unit test, it would import just fine
> using the T5 service without spawning extra threads, so I don't think it is
> related to the T5 service itself (which make's sense, since the
> onValidate/onSuccess events are being triggered more than once).
>
> Thanks,
>
> mrg
>
>
>
> On Thu, Aug 28, 2014 at 2:05 PM, Lance Java 
> wrote:
>
> > 1.Is your app sitting behind a proxy? (eg apache?).
> >
> > 2. Are there any other servlet filters we should know about? (eg spring?)
> >
>

Re: Unit test component with request parameter

[George Christman]

Your absolutely correct, context URLs are much better for SEO than request
parameters. I tend to use both at the same time, example
domain/category?make=ford, category being the context. I think what you've
done is a cool idea, however with the amount of filters that we will end up
having, it would get real messy when they are mostly all null. It would end
up looking something like this.
domain.com/category/make/$N/$N/$N/$N/$N/$N/$N/$N/$N/$N/brown

Some of the newer stuff I have planned will look something like this.
http://www.cardaddy.com/used-cars/2011-toyota-corolla-le-albany-ny-12205-4978?_rd=50&color=brown

used-cars = context param
2011-toyota-corolla-le-albany-ny-12205-4978 = context param
12095 = zipcode
4978 = db pk for the year make model trim combo.

We are already doing something similar on a smaller scale here.
http://www.cardaddy.com/forsale/vehicle/2011-toyota-corolla-le-duluth-ga-4978


On Thu, Aug 28, 2014 at 2:14 PM, Lance Java 
wrote:

> > I believe you were the one who use push me away from @Persist
> Lol... sounds like me :)
>
> I'm no SEO guru but I think keywords in the URL score better than request
> parameters. You might be interested in this recent feature I added to
> @PageActivationContext
>
> https://issues.apache.org/jira/browse/TAP5-2138
>



-- 
George Christman
www.CarDaddy.com
P.O. Box 735
Johnstown, New York

Re: 5.4 Upload / Long Response Issue?

[Michael Gentry]

Hi again Lance,

1) No proxy.  Directly connecting to Jetty @ http://localhost:6789/

2) No other filters.  I'm using Tapestry's IOC for services and trying to
keep things lean.

FWIW, when I dropped the file in as a unit test, it would import just fine
using the T5 service without spawning extra threads, so I don't think it is
related to the T5 service itself (which make's sense, since the
onValidate/onSuccess events are being triggered more than once).

Thanks,

mrg



On Thu, Aug 28, 2014 at 2:05 PM, Lance Java 
wrote:

> 1.Is your app sitting behind a proxy? (eg apache?).
>
> 2. Are there any other servlet filters we should know about? (eg spring?)
>

Re: 5.4 Upload / Long Response Issue?

[Norman Franke]

While not the same problem, I’ve had issues uploading even small files to 
Tapestry on Tomcat when behind a load balancer. Eliminating the load balancer 
solved the problem. Not really a Tapestry problem, I’d suspect, but possibly 
related.

Norman Franke
Answering Service for Directors, Inc.
www.myasd.com



On Aug 28, 2014, at 2:05 PM, Lance Java  wrote:

> 1.Is your app sitting behind a proxy? (eg apache?).
> 
> 2. Are there any other servlet filters we should know about? (eg spring?)

Re: Unit test component with request parameter

[Lance Java]

> I believe you were the one who use push me away from @Persist
Lol... sounds like me :)

I'm no SEO guru but I think keywords in the URL score better than request
parameters. You might be interested in this recent feature I added to
@PageActivationContext

https://issues.apache.org/jira/browse/TAP5-2138

Re: 5.4 Upload / Long Response Issue?

[Lance Java]

1.Is your app sitting behind a proxy? (eg apache?).

2. Are there any other servlet filters we should know about? (eg spring?)

Re: 5.4 Upload / Long Response Issue?

[Michael Gentry]

Hi Lance,

All 3 browsers issue a single request.  The second thread and
onValidate/onSuccess occur 30 seconds after the original upload using all 3
browsers (and repost/redeliver the original payload it seems, since the
complete XML file is available to the new thread(s)).

Thanks,

mrg



On Thu, Aug 28, 2014 at 11:20 AM, Lance Java 
wrote:

> Strange? Can you open up the network traffic in your browser's dev tools
> and see the httptraffic?
>
> If there's 2 requests, can you copy / paste the request headers?
>

Re: Unit test component with request parameter

[George Christman]

Yup you got it :) I believe you were the one who use push me away from
@Persist and build stateless apps lol.


On Thu, Aug 28, 2014 at 12:24 PM, Lance Java 
wrote:

> I've been making assumptions without viewing code :) Up until now I've been
> thinking it was an AJAX update.
>
> I'm now thinking you're doing a redirect after post and you're using
> request parameters to pass the values (avoiding @Persist and having
> bookmarkable urls).
>
> Sounds fine to me. The other option is to use activation context.
>



-- 
George Christman
www.CarDaddy.com
P.O. Box 735
Johnstown, New York

Re: Unit test component with request parameter

[Lance Java]

I've been making assumptions without viewing code :) Up until now I've been
thinking it was an AJAX update.

I'm now thinking you're doing a redirect after post and you're using
request parameters to pass the values (avoiding @Persist and having
bookmarkable urls).

Sounds fine to me. The other option is to use activation context.

Re: Unit test component with request parameter

[George Christman]

Wouldn't you still need to set the parameters to build the URL though? We
just need to be sure the filters remain in the URL so that the searches can
be book marked and indexed by search engines.


On Thu, Aug 28, 2014 at 10:46 AM, Lance Java 
wrote:

> > Im not sure I understand the differences between field values and event
> parameters
> field values - What I meant here was using a  and binding
> properties to TextField and Select etc.
> event parameters - eg: onMyEvent(String param1, String param2, ...)
>
> Have you seen the filter demo of the observe plugin in tapestry-stitch?
> http://tapestry-stitch.uklance.cloudbees.net/observedemo
> It hides request parameters from you and converts to event parameters so
> your code can be cleaner.
>



-- 
George Christman
www.CarDaddy.com
P.O. Box 735
Johnstown, New York

Re: 5.4 Upload / Long Response Issue?

[Lance Java]

Strange? Can you open up the network traffic in your browser's dev tools
and see the httptraffic?

If there's 2 requests, can you copy / paste the request headers?

Re: Unit test component with request parameter

[Lance Java]

> Im not sure I understand the differences between field values and event
parameters
field values - What I meant here was using a  and binding
properties to TextField and Select etc.
event parameters - eg: onMyEvent(String param1, String param2, ...)

Have you seen the filter demo of the observe plugin in tapestry-stitch?
http://tapestry-stitch.uklance.cloudbees.net/observedemo
It hides request parameters from you and converts to event parameters so
your code can be cleaner.

5.4 Upload / Long Response Issue?

[Michael Gentry]

Hi everyone,

I'm currently using 5.4B6 and we are doing uploads of XML data (using the
standard Tapestry Upload/UploadFile mechanism -- no multi-file AJAX/etc
extensions).

When we upload a small file, it processes just fine, but on a larger file
(which takes several minutes to process), multiple threads are created
along with multiple onValidate/onSuccess calls (and no, we weren't
double-clicking the submit button).  The second thread
and onValidate/onSuccess get created/called 30 seconds after the original
invocation.  This can cause duplicate inserts into the database or other
shenanigans.

Another oddity:

Chrome: Always 2 threads.
Firefox: Always 2 threads.
Safari: Always 2+ threads (we'd just kill the app instead of letting it run
for hours)

Has anyone else experienced this before?  Is it an issue with 5.4 (we don't
seem to have the issue in 5.3)?  Another possibility is Jetty is kicking
off the additional threads when a response isn't generated in time, but it
seems odd that many more threads get kicked off when connecting via Safari
instead of Chrome/Firefox.

Thanks,

mrg

PS. We worked around the issue by creating an upload status page and doing
the processing in the background with an AJAX update, so no hurry for a
resolution, just wanted to ask about a possible 5.4 issue.

Re: Lots of issues being closed

[Thiago H de Paula Figueiredo]

On Wed, 27 Aug 2014 22:10:42 -0300, Howard Lewis Ship   
wrote:



I'm very interested in getting 5.4 out the door;


So am I.

there's still a number of serious issues barring the way, and the  
backlog of bugs is proving to be a real impediment.


We could tag in JIRA this bugs so committers and non-commiters could focus  
on them. What do you think?


--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br

-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Re: Unit test component with request parameter

[George Christman]

Ah okay, so I guess what you are suggesting is similar to what I originally
had. I'm not sure I understand the differences between field values and
event parameters. I just need to be able to read parameters from the URL.


On Thu, Aug 28, 2014 at 9:08 AM, Lance Java 
wrote:

> I'd do something like this to separate web from service and keep it
> testable.
>
> @Inject
> private MyService myService;
>
> public void doSearch(@RequestParam String filter1, @RequestParam Integer
> filter2) {
>SearchFilter filter = new SearchFilter();
>filter.setFilter1(filter1);
>filter.setFilter2(filter2);
>
>List results = myService.doSearch(filter);
>doStuff(results);
> }
>



-- 
George Christman
www.CarDaddy.com
P.O. Box 735
Johnstown, New York

Re: Unit test component with request parameter

[Lance Java]

I'd do something like this to separate web from service and keep it
testable.

@Inject
private MyService myService;

public void doSearch(@RequestParam String filter1, @RequestParam Integer
filter2) {
   SearchFilter filter = new SearchFilter();
   filter.setFilter1(filter1);
   filter.setFilter2(filter2);

   List results = myService.doSearch(filter);
   doStuff(results);
}

Re: Unit test component with request parameter

[Lance Java]

@RequestParameter will only work for page and component events.

A robust service layer should never reference the Request or any other web
objects so you should really pass them through to the service. Perhaps you
want to encapsulate multiple values in a bean which can grow over time
without changing the service's method signature.

Is there a reason why you are using request parameters and not field values
or event parameters?

Re: Unit test component with request parameter

[George Christman]

Hi lance, I've been working on simplifying the design, so with that said
the service and page design is a little different from what I have checked
in. My goal is to remove all the request parameters from the page and put
them directly into the service so that I'm not having to pass them all over
the place.

So can I just add @Request Parameter to my service method signature and
both automatically read the request parameter from the url or just manually
pass it in through the the unit test? I'm not sure if thats what you were
suggesting.

I'm still very new to the mockito stuff, so I don't understand what it is
actually doing or how to use it.

I'm hoping to simplify the page class so that no testing is required.
Hopefully we can just test the services.
On Aug 28, 2014 3:18 AM, "Lance Java"  wrote:

> An even simpler approach is to grab the request parameter in the page /
> component and pass through to a service. Then forget about testing the page
> / component and focus on the service.
>
> This is what I usually do. A couple of lines of code go untested but my api
> is better and tests are much easier to maintain.
>

Re: Unit test component with request parameter

[Lance Java]

An even simpler approach is to grab the request parameter in the page /
component and pass through to a service. Then forget about testing the page
/ component and focus on the service.

This is what I usually do. A couple of lines of code go untested but my api
is better and tests are much easier to maintain.

Re: Unit test component with request parameter

[Lance Java]

Hi George, you're lucky I know your architecture :) You should include a
snippet of the test module for completeness.

You'll notice the request is actually a mockito proxy setup in the @Before
of the test (in the test module).

Can you use @RequestParameter in the event (instead of
request.getParameter()?) then you can call the method and pass a value from
the test.

Otherwise you'll need to use mockito to mock request.getParameter(...)
(similar to how request.isXhr() is currently mocked). You'll need to be
careful here, there are 2 request proxies (mockito proxy wrapped by
tapestry ioc proxy). And I'm not sure mockito methods can act on the
tapestry proxy.
On 28 Aug 2014 02:47, "George Christman"  wrote:

> Hi everyone, I'm trying to create some unit test against a new component
> I'm working on. The new component uses request.getParameter(). I'm
> wondering how I would go about setting the request parameter in my test
> case.
>
> Component I'm testing
>
> public void keywordFacetSearch() {
> // Get the user's search keyword(s). Get optional parameters, or
> apply default values if those parameters weren't passed.
> String searchString = request.getParameter(SearchParam.KEY) != null
> ? request.getParameter(CarDaddyEnum.KEY).trim() : "";
> }
>
> Test case
>
> @Test
>   public void testKeywordFacetSearch() {
> request.setAttribute(SearchParam.KEY, "foo");
>   }
>
> request.setAttribute doesn't seem to work. Any ideas?
>
> Thanks
>
> --
> George Christman
> www.CarDaddy.com
> P.O. Box 735
> Johnstown, New York
>