The security aspect is true. I don't see a problem in the worker
threads yet, however you might be right.

We might try a Wicket example to see how we can integrate all our
existing code into it.


2012/8/26 Martin Grigorov <>:
> Hi Sebastian,
> I see a little problem in your architecture - the jQuery client will
> make a request to the Velocity servlet, then if you use
> the REST API you'll need to make another http request. If both the
> servlet app and the REST app are deployed on the same
> web container instance/node then you will face thread starvation
> problem for http worker threads, possible deadlock too. So you may
> need to deploy the different parts on different nodes.
> Also think early how you will implement the security part of the application.
> Sometimes classics are much easier ;-)
> On Sun, Aug 26, 2012 at 5:36 PM,
> <> wrote:
>> Thanks for the detailed answer Martin!
>> You are right in my description I missed one part, for generating the
>> HTML my plan was to use Apache Velocity. The REST interface will only
>> generate data to fill that HTML.
>> I've created a MockUp of the architecture proposal that should cover it all:
>> Wicket seems to be more likely to be a classic
>> web-application-framework. From my point of view we are more looking
>> for a UI framework.
>> Thanks!
>> Sebastian
>> 2012/8/26 Martin Grigorov <>:
>>> Hi,
>>> You didn't say what your web service response's type is.
>>> By referring to jQuery's #load() method it seems like your WS returns
>>> ready to render HTML, but later you say that you will create the
>>> content with pure JavaScript (JQuery) which makes me think that the
>>> returned response is plain data (JSON, XML, ...) which you will use to
>>> generate the HTML.
>>> Wicket is (mostly) server side framework, i.e. it generates the HTML
>>> at the server and sends it to the browser for rendering. For single
>>> page applications (SPA) you start with rendering a whole Page and then
>>> by using Wicket Ajax components just need to update your components'
>>> models (pure Java code executed at the server) and Wicket will
>>> generate the HTML and send it to the browser to update the part(s) of
>>> the page. Wicket 6.0 also provides integrations with Atmosphere
>>> framework and Native WebSocket so you can use newer (HTML5)
>>> technologies for updating the view at the client side. Again you'll
>>> have to write mostly Java code to implement this.
>>> The benefit is that you can test all this very easily with
>>> unit/functional tests written in Java.
>>> If you want to use JavaScript to render the returned plain data from
>>> your web service then there is no need to include Wicket in the
>>> technology stack. But in this case you will need to use some
>>> JavaScript testing library. The JS testing libs became better last
>>> year but still not that good as Java ones.
>>> In both cases using Selenium for more complicated test scenaria will be 
>>> needed.
>>> HTH
>>> martin-g
>>> On Sun, Aug 26, 2012 at 2:24 PM,
>>> <> wrote:
>>>> Hi,
>>>> we are developers from the Apache project "Apache OpenMeetings", we
>>>> provide a Web-Conferencing application that is currently Flash-based
>>>> on the client side.
>>>> We already have a server side stack with Spring + openJPA + Axis2 that
>>>> provides us with a SOAP/REST API and ORM.
>>>> We are currently discussing an HTML5 alternative for our Flash based
>>>> client and have to decide some basic framework questions.
>>>> Apache Wicket is one option.
>>>> Our HTML client is likely to be a single HTML page that loads content
>>>> / components dynamically into the website.
>>>> My idea was first to use to load
>>>> components dynamically, however maybe Wicket has a similar mechanism?
>>>> It seems like the combination of jQuery + Wicket is the most widespreaded.
>>>> But if we create our content with pure jQuery, why adding Wicket to it?
>>>> I was told that Wicket's strength is to provide a Non-JavaScript
>>>> version of the website if JavaScript is not available. However as our
>>>> basic features will be collaboration tools that really make no sense
>>>> without JavaScript, we don't need a Non-JavaScript version.
>>>> And we have already a REST interface, we don't need to duplicate one
>>>> with Wicket that provides yet another API.
>>>> Maybe there are other arguments positive for using Wicket that I have 
>>>> overseen?
>>>> Thanks for sharing!
>>>> Sebastian
>>>> --
>>>> Sebastian Wagner
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail:
>>>> For additional commands, e-mail:
>>> --
>>> Martin Grigorov
>>> jWeekend
>>> Training, Consulting, Development
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> --
>> Sebastian Wagner
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --
> Martin Grigorov
> jWeekend
> Training, Consulting, Development
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Sebastian Wagner!/dead_lock

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to