68 |
thread-event model in all other components also (i.e. native Java threads |
thread-event model in all other components also (i.e. native Java threads |
69 |
are not allowed)? |
are not allowed)? |
70 |
|
|
71 |
.. I realized this "Don't allocate or manage threads in your application" |
SOLVED: According to Matt Welsh, the author of SEDA/Sandstorm framework, we are |
72 |
(possible) issue while I was reading Sandstorm Tutorial and |
able to use native (Java) threads while using SEDA in a software: |
73 |
User's Guide. This "feature" of SEDA has not been mentioned anywhere in Tapestry |
|
74 |
website, nor Tapestry installation guide, nor Tapestry Programmer's guide, |
It is true that SEDA intends to manage all of the threads in the system |
75 |
nor Javadocs! |
itself. However, it should be fine to use your own threads as long as |
76 |
|
you yield or sleep often enough for SEDA's threads to get a chance to |
77 |
If a software cannot use native Java threads as one software |
run. Let me know how it goes! |
78 |
component uses SEDA's thread-event model, it's a *major* issue for us. Thus, |
|
|
the choices are: |
|
|
|
|
|
1) Dumb Tapestry (the best choice?) |
|
|
2) Re-engineer Fenfire framework to SEDA compliant (a very bad choice) |
|
|
3) Implement a Seda-free Tapestry (possible, but may required lot of work) |
|
|
|
|
|
I will investigate this more carefully... |
|
|
|
|
|
|
|
|
|
|
79 |
|
|
80 |
Introduction to Tapestry |
Introduction to Tapestry |
81 |
======================== |
======================== |