HTML5 + REST sounds pretty cool.  I like it.  It's certainly the most modern approach.

Since a lot of people who will be testing clusters may not be professional developers, is it possible to have the WAR somewhere for them pre-built?  I am picturing our sysadmins and QA folks, neither of which have Maven installed on their system.  Also, some ANT users may want to test a cluster, but not download Maven. 

So are the goals:
  1. Show developer how to make their application cluster/failover-safe.
  2. Provide a sample app users can deploy to EAP6 and test failover.

Regarding Servlets, I was really just envisioning 1 table...something very basic and ugly like:

<html>
<head><title>Session Replication Demo</title><head>
<body>
<table>
    <tr><th>user<th><td>?</td></tr>   
    <tr><th>counter<th><td>?</td></tr>   
</table>
</body>
</html>


Is that too "bush-league" for JDF? :)  I like servlets because it will make sense to folks who haven't updated their skillset since the early 2000s.  I run into far more of those than I should.  :) 

Then again, maybe it's just time for folks to learn some JavaScript :)

I guess HTTP Auth is not mandatory, just thinking it's good proof things are replicating correctly.

Thanks,
Steven


On 7/12/2012 6:00 PM, Pete Muir wrote:
On 12 Jul 2012, at 22:55, StevenBoscarine wrote:


Hello Pete,
Happy to take the lead and get this started.  Any idea for an initial name?  <artifactId>jboss-as-session-replication</artifactId>?

Sounds good.


I was thinking @Stateful because it requires @Clustered, right?  
https://docs.jboss.org/author/display/AS71/Clustered+EJBs

@Stateless requires it as well, right?  
http://docs.jboss.org/jbossclustering/cluster_guide/5.1/html/clustering-session.html

Are there any other Java EE features that need developer action to make them clustering/failover-ready?  Does CDI need anything for replicating conversation or session scoped beans in a cluster?

To get the CDI session scope clustered, just add <distributable /> to web.xml


Regarding JSF, I'm fine with whatever folks think.  JSF is good since everything they need is built into the container.  

However, my first thought is that the simpler we can make things, the better.  A lot of folks hate JSF.  I find pushing it at organizations an uphill battle.  When I say that acronym, a lot of folks still roll their eyes.  IMHO, the best solution for a quickstart is the one that does the job with the least number of moving parts.  

Ok. I was just worried it could be a lot of boilerplate in the Servlet.

Or we could do HTML5 + REST.


If there's 1 page and HTTP Basic Authentication, would we gain anything by having JSF?  Obviously am happy to accommodate what others want.

No, I'm just thinking that writing lots of HTML in servlets is pretty nasty.


I was thinking:
	• HTTP Basic Authentication
	• A servlet displaying a counter and the current login name.
	• @Stateful EJBs injected to maintain state.
	• @Stateless EJB injected just to show how.

Well, to me the priority is to show CDI session scope working in a cluster. I think more people will use this than EJBs.

We could do a second quickstart to show EJBs.

I'm not sure why we need to pull HTTP auth into it?


WDYT?

Thanks,
Steven


On 7/12/2012 4:55 PM, Pete Muir wrote:

Hi Steven

Yes, we want a session replication quickstart :-)

We should, as you say, update it to use CDI (why an SLSB?) and Servlet 3. Possibly JSF?

Pete

On 12 Jul 2012, at 19:56, StevenBoscarine wrote:



Hello All,
I wanted to do an exercise to test failover on our new EAP6 cluster.  
Any recommendations?

The one I'm familiar with is using 

https://community.jboss.org/wiki/ReplicatedCounter
 and confirming the 
counter doesn't go down when you kill a container.

If there isn't a great QS for session replication, does this dovetail 
with any of the JDF Quickstarts?  If so, I'd love to see it use a 
@Stateful session bean, Maven, and Servlet 3.0.  I could update this war 
rather quickly if you saw value in having a QS specifically for testing 
Session replication.

Thanks,
Steven
_______________________________________________
jdf-users mailing list

jdf-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jdf-users