Re: @SetupRender and class hierarchy
Hi !
You should use @Override on overriden methods in sub-classes
2010/9/1 Paul Stanton p...@mapshed.com.au
I've found a strange issue with the @SetupRender annotation when used in a
class hierarchy.
Typically, in java 2 classes within a hierarchy can have the same signature
for a private method and not effect each other, so I would expect this to be
the case when both of these private methods are annotated with @SetupRender.
Therefore the output for case 1 and case 2 (below) should be the same and
print both messages setupRender2, setupRender1.
However case 1 only prints setupRender2 meaning it somehow overwrites the
method in it's implementing class.
This is concerning because
1. there should never be a requirement that a sub-class knows of it's
super-classes implementation
2. if hierarchy does come into play, the subclass should override the super
class.
CASE 1:
--
public abstract class StartBase {
@SetupRender
private void init() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init() {
log.debug(setupRender1);
}
}
CASE 2:
--
public abstract class StartBase {
@SetupRender
private void init2() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init1() {
log.debug(setupRender1);
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
tapestry 4 table methods call multiple times
0 down vote favorite
i do debug on IBasicTableModel , on method
public IBasicTableModel getModel() {
return new IBasicTableModel() {
public int getRowCount() {
//this is called multiple times
}
public Iterator getCurrentPageRows(
int nFirst,
int nPageSize,
ITableColumn objSortColumn,
boolean bSortOrder) {
//this is called multiple times
}
}
is it normal for tapestr4, do call getRowCount(), getCurrentPageRows().. many
times just to render the page?
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: @SetupRender and class hierarchy
Christophe,
I think Paul's point is that there shouldn't be any overriding happening
: in his first case, these are private methods; hence, the @Override
annotation would be incorrect.
Sounds like a bug to me.
Regards,
Alex K
On Wed, Sep 1, 2010 at 2:27 AM, Christophe Cordenier
christophe.corden...@gmail.com wrote:
Hi !
You should use @Override on overriden methods in sub-classes
2010/9/1 Paul Stanton p...@mapshed.com.au
I've found a strange issue with the @SetupRender annotation when used in
a
class hierarchy.
Typically, in java 2 classes within a hierarchy can have the same
signature
for a private method and not effect each other, so I would expect this to
be
the case when both of these private methods are annotated with
@SetupRender.
Therefore the output for case 1 and case 2 (below) should be the same and
print both messages setupRender2, setupRender1.
However case 1 only prints setupRender2 meaning it somehow overwrites
the
method in it's implementing class.
This is concerning because
1. there should never be a requirement that a sub-class knows of it's
super-classes implementation
2. if hierarchy does come into play, the subclass should override the
super
class.
CASE 1:
--
public abstract class StartBase {
@SetupRender
private void init() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init() {
log.debug(setupRender1);
}
}
CASE 2:
--
public abstract class StartBase {
@SetupRender
private void init2() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init1() {
log.debug(setupRender1);
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
Re: @SetupRender and class hierarchy
Hi !
Actually as far as i remember when method have the same name, the generated
code would simply call 'init' method without method selection in this case.
Anyway, Paul should use a protected or package visibility in his case and
call super.init() on the parent class.
2010/9/1 Alex Kotchnev akoch...@gmail.com
Christophe,
I think Paul's point is that there shouldn't be any overriding happening
: in his first case, these are private methods; hence, the @Override
annotation would be incorrect.
Sounds like a bug to me.
Regards,
Alex K
On Wed, Sep 1, 2010 at 2:27 AM, Christophe Cordenier
christophe.corden...@gmail.com wrote:
Hi !
You should use @Override on overriden methods in sub-classes
2010/9/1 Paul Stanton p...@mapshed.com.au
I've found a strange issue with the @SetupRender annotation when used
in
a
class hierarchy.
Typically, in java 2 classes within a hierarchy can have the same
signature
for a private method and not effect each other, so I would expect this
to
be
the case when both of these private methods are annotated with
@SetupRender.
Therefore the output for case 1 and case 2 (below) should be the same
and
print both messages setupRender2, setupRender1.
However case 1 only prints setupRender2 meaning it somehow overwrites
the
method in it's implementing class.
This is concerning because
1. there should never be a requirement that a sub-class knows of it's
super-classes implementation
2. if hierarchy does come into play, the subclass should override the
super
class.
CASE 1:
--
public abstract class StartBase {
@SetupRender
private void init() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init() {
log.debug(setupRender1);
}
}
CASE 2:
--
public abstract class StartBase {
@SetupRender
private void init2() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init1() {
log.debug(setupRender1);
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
Re: @SetupRender and class hierarchy
Also, i don't know how this would be possible in pure Java... without
modifying method prototypes.
2010/9/1 Christophe Cordenier christophe.corden...@gmail.com
Hi !
Actually as far as i remember when method have the same name, the generated
code would simply call 'init' method without method selection in this case.
Anyway, Paul should use a protected or package visibility in his case and
call super.init() on the parent class.
2010/9/1 Alex Kotchnev akoch...@gmail.com
Christophe,
I think Paul's point is that there shouldn't be any overriding happening
: in his first case, these are private methods; hence, the @Override
annotation would be incorrect.
Sounds like a bug to me.
Regards,
Alex K
On Wed, Sep 1, 2010 at 2:27 AM, Christophe Cordenier
christophe.corden...@gmail.com wrote:
Hi !
You should use @Override on overriden methods in sub-classes
2010/9/1 Paul Stanton p...@mapshed.com.au
I've found a strange issue with the @SetupRender annotation when used
in
a
class hierarchy.
Typically, in java 2 classes within a hierarchy can have the same
signature
for a private method and not effect each other, so I would expect this
to
be
the case when both of these private methods are annotated with
@SetupRender.
Therefore the output for case 1 and case 2 (below) should be the same
and
print both messages setupRender2, setupRender1.
However case 1 only prints setupRender2 meaning it somehow
overwrites
the
method in it's implementing class.
This is concerning because
1. there should never be a requirement that a sub-class knows of it's
super-classes implementation
2. if hierarchy does come into play, the subclass should override the
super
class.
CASE 1:
--
public abstract class StartBase {
@SetupRender
private void init() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init() {
log.debug(setupRender1);
}
}
CASE 2:
--
public abstract class StartBase {
@SetupRender
private void init2() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init1() {
log.debug(setupRender1);
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
Submitting XML via a T5 form
Can anyone advise on the best approach to submitting XML via a T5 form? I have a requirement to allow the user to submit XML via a form field - this XML is then persisted in the database. What approach to CDATA etc. can I use to ensure the form is posted / redisplayed correctly? Is there any built-in support in T5 (5.2.0) for this scenario? Thanks. Regards, Jim.
Re: @SetupRender and class hierarchy
Christophe,
I'm not sure that you understand the problem. Please review my initial post.
Regards, Paul.
Christophe Cordenier wrote:
Also, i don't know how this would be possible in pure Java... without
modifying method prototypes.
2010/9/1 Christophe Cordenier christophe.corden...@gmail.com
Hi !
Actually as far as i remember when method have the same name, the generated
code would simply call 'init' method without method selection in this case.
Anyway, Paul should use a protected or package visibility in his case and
call super.init() on the parent class.
2010/9/1 Alex Kotchnev akoch...@gmail.com
Christophe,
I think Paul's point is that there shouldn't be any overriding happening
: in his first case, these are private methods; hence, the @Override
annotation would be incorrect.
Sounds like a bug to me.
Regards,
Alex K
On Wed, Sep 1, 2010 at 2:27 AM, Christophe Cordenier
christophe.corden...@gmail.com wrote:
Hi !
You should use @Override on overriden methods in sub-classes
2010/9/1 Paul Stanton p...@mapshed.com.au
I've found a strange issue with the @SetupRender annotation when used
in
a
class hierarchy.
Typically, in java 2 classes within a hierarchy can have the same
signature
for a private method and not effect each other, so I would expect this
to
be
the case when both of these private methods are annotated with
@SetupRender.
Therefore the output for case 1 and case 2 (below) should be the same
and
print both messages setupRender2, setupRender1.
However case 1 only prints setupRender2 meaning it somehow
overwrites
the
method in it's implementing class.
This is concerning because
1. there should never be a requirement that a sub-class knows of it's
super-classes implementation
2. if hierarchy does come into play, the subclass should override the
super
class.
CASE 1:
--
public abstract class StartBase {
@SetupRender
private void init() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init() {
log.debug(setupRender1);
}
}
CASE 2:
--
public abstract class StartBase {
@SetupRender
private void init2() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init1() {
log.debug(setupRender1);
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
Re: @SetupRender and class hierarchy
Christophe,
I guess a part of the problem is that if I subclass from a parent class,
I might not know what private methods it has. Thus, if the superclass ends
up having a private method annotated w/ @SetupRender, and I accidentally end
up having a private method in my class w/ the same name and annotated
@SetupRender, my method isn't getting called. Sounds like a massive
violation of encapsulation principles.
Regards,
Alex K
On Wed, Sep 1, 2010 at 8:25 AM, Christophe Cordenier
christophe.corden...@gmail.com wrote:
Hi !
Actually as far as i remember when method have the same name, the generated
code would simply call 'init' method without method selection in this case.
Anyway, Paul should use a protected or package visibility in his case and
call super.init() on the parent class.
2010/9/1 Alex Kotchnev akoch...@gmail.com
Christophe,
I think Paul's point is that there shouldn't be any overriding
happening
: in his first case, these are private methods; hence, the @Override
annotation would be incorrect.
Sounds like a bug to me.
Regards,
Alex K
On Wed, Sep 1, 2010 at 2:27 AM, Christophe Cordenier
christophe.corden...@gmail.com wrote:
Hi !
You should use @Override on overriden methods in sub-classes
2010/9/1 Paul Stanton p...@mapshed.com.au
I've found a strange issue with the @SetupRender annotation when used
in
a
class hierarchy.
Typically, in java 2 classes within a hierarchy can have the same
signature
for a private method and not effect each other, so I would expect
this
to
be
the case when both of these private methods are annotated with
@SetupRender.
Therefore the output for case 1 and case 2 (below) should be the same
and
print both messages setupRender2, setupRender1.
However case 1 only prints setupRender2 meaning it somehow
overwrites
the
method in it's implementing class.
This is concerning because
1. there should never be a requirement that a sub-class knows of it's
super-classes implementation
2. if hierarchy does come into play, the subclass should override the
super
class.
CASE 1:
--
public abstract class StartBase {
@SetupRender
private void init() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init() {
log.debug(setupRender1);
}
}
CASE 2:
--
public abstract class StartBase {
@SetupRender
private void init2() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init1() {
log.debug(setupRender1);
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
Re: Submitting XML via a T5 form
The redisplay correctly part should be handled by the default output encoding in T5 - thus, if the XML that is submitted in a form field and it's bound to a String property in your page or model, if you display/redisplay the form, it should render properly. I don't think you need anything special w/ CDATA in your case. Regards, Alex K On Wed, Sep 1, 2010 at 8:28 AM, Jim O'Callaghan jc1000...@yahoo.co.ukwrote: Can anyone advise on the best approach to submitting XML via a T5 form? I have a requirement to allow the user to submit XML via a form field - this XML is then persisted in the database. What approach to CDATA etc. can I use to ensure the form is posted / redisplayed correctly? Is there any built-in support in T5 (5.2.0) for this scenario? Thanks. Regards, Jim.
Re: @SetupRender and class hierarchy
Right,
But actually, I don't think that setupRender method are meant to be private.
Strategy is parent before children. see
http://markmail.org/thread/u3t6xfa2mzopwgpz
2010/9/1 Alex Kotchnev akoch...@gmail.com
Christophe,
I guess a part of the problem is that if I subclass from a parent class,
I might not know what private methods it has. Thus, if the superclass ends
up having a private method annotated w/ @SetupRender, and I accidentally
end
up having a private method in my class w/ the same name and annotated
@SetupRender, my method isn't getting called. Sounds like a massive
violation of encapsulation principles.
Regards,
Alex K
On Wed, Sep 1, 2010 at 8:25 AM, Christophe Cordenier
christophe.corden...@gmail.com wrote:
Hi !
Actually as far as i remember when method have the same name, the
generated
code would simply call 'init' method without method selection in this
case.
Anyway, Paul should use a protected or package visibility in his case and
call super.init() on the parent class.
2010/9/1 Alex Kotchnev akoch...@gmail.com
Christophe,
I think Paul's point is that there shouldn't be any overriding
happening
: in his first case, these are private methods; hence, the @Override
annotation would be incorrect.
Sounds like a bug to me.
Regards,
Alex K
On Wed, Sep 1, 2010 at 2:27 AM, Christophe Cordenier
christophe.corden...@gmail.com wrote:
Hi !
You should use @Override on overriden methods in sub-classes
2010/9/1 Paul Stanton p...@mapshed.com.au
I've found a strange issue with the @SetupRender annotation when
used
in
a
class hierarchy.
Typically, in java 2 classes within a hierarchy can have the same
signature
for a private method and not effect each other, so I would expect
this
to
be
the case when both of these private methods are annotated with
@SetupRender.
Therefore the output for case 1 and case 2 (below) should be the
same
and
print both messages setupRender2, setupRender1.
However case 1 only prints setupRender2 meaning it somehow
overwrites
the
method in it's implementing class.
This is concerning because
1. there should never be a requirement that a sub-class knows of
it's
super-classes implementation
2. if hierarchy does come into play, the subclass should override
the
super
class.
CASE 1:
--
public abstract class StartBase {
@SetupRender
private void init() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init() {
log.debug(setupRender1);
}
}
CASE 2:
--
public abstract class StartBase {
@SetupRender
private void init2() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init1() {
log.debug(setupRender1);
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
--
Regards,
Christophe Cordenier.
Committer on Apache Tapestry 5
Co-creator of wooki @wookicentral.com
Re: File Handling and Buffer Handling
Hi Thiago! You don't really need file handling nor buffer handling classes in Tapestry: just use the Java ones. Anyway, you don't need to worry with files nor buffering in your component: handle files in memory only. Make your component receive the PDF file to be rendered as an InputStream. Most probably the PDF renderer already buffers input. Thank your comment. http://download.oracle.com/javase/1.5.0/docs/api/java/io/InputStream.html using this class is ok? charith
Re: File Handling and Buffer Handling
On Wed, 01 Sep 2010 10:04:42 -0300, Charith Madusanka charithc...@gmail.com wrote: Hi Thiago! Hi! Thank your comment. http://download.oracle.com/javase/1.5.0/docs/api/java/io/InputStream.html using this class is ok? Yes. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: @SetupRender and class hierarchy
On Tue, Aug 31, 2010 at 7:57 PM, Paul Stanton p...@mapshed.com.au wrote:
I've found a strange issue with the @SetupRender annotation when used in a
class hierarchy.
Typically, in java 2 classes within a hierarchy can have the same signature
for a private method and not effect each other, so I would expect this to be
the case when both of these private methods are annotated with @SetupRender.
Therefore the output for case 1 and case 2 (below) should be the same and
print both messages setupRender2, setupRender1.
However case 1 only prints setupRender2 meaning it somehow overwrites the
method in it's implementing class.
This is concerning because
1. there should never be a requirement that a sub-class knows of it's
super-classes implementation
2. if hierarchy does come into play, the subclass should override the super
class.
CASE 1:
--
public abstract class StartBase {
@SetupRender
private void init() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init() {
log.debug(setupRender1);
}
}
I think you are correct; it should invoke StartBase.init(), then
Start.init(), following the rule that parent class render event
methods are invoked before subclass render event methods.
Which release of Tapestry are you using?
I believe what's happening is that Tapestry is interpreting
Start.init() as an override of StartBase.init() the methods have
the same signature. Tapestry will effectively ignore the subclass
method because it will be invoked by the base class (again, the rule
about base class methods coming before subclass methods).
However, in this case, it is not correct. Because the method is
private, it is never an override of a base class method and should not
be ignored.
Please add a JIRA issue.
CASE 2:
--
public abstract class StartBase {
@SetupRender
private void init2() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init1() {
log.debug(setupRender1);
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
T5.1 and Threaded Background Tasks
I need a page that will start a long-running process involving heavy use of a database. I'm trying to come up with an elegant way to integrate this into my T5.1 app. I'd like to use Tapestry's IoC to inject my Hibernate DAOs. Then I'd like to write status updates to a stack and have an AJAX process poll and update the web page with what's happening. I see there is a ParallelExecutor in Tapestry, but I don't think it does injection. Any good solutions out there? Norman Franke Answering Service for Directors, Inc. www.myasd.com
Blog post about T5 data access layer implementation in GAE
FYI http://dmitrygusev.blogspot.com/2010/09/gae-and-tapestry5-data-access-layer.html -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: T5.1 and Threaded Background Tasks
ParallelExecutor is a service that allows work to occur in parallel using a thread pool. I doubt it's usefulness in your case. Simply create a new service, spawn threads in it as needed to do work and implement a few get status operations that your page(s) can call. That way, keeping the page up-to-date via AJAX is a separate concern. Kalle On Wed, Sep 1, 2010 at 12:06 PM, Norman Franke nor...@myasd.com wrote: I need a page that will start a long-running process involving heavy use of a database. I'm trying to come up with an elegant way to integrate this into my T5.1 app. I'd like to use Tapestry's IoC to inject my Hibernate DAOs. Then I'd like to write status updates to a stack and have an AJAX process poll and update the web page with what's happening. I see there is a ParallelExecutor in Tapestry, but I don't think it does injection. Any good solutions out there? Norman Franke Answering Service for Directors, Inc. www.myasd.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5.1 and Threaded Background Tasks
You can use ParallelExecutor service just fine, and to use injection do not instantiate a task yourself but make it a service with scope perthread. Davor Hrg On Wed, Sep 1, 2010 at 10:03 PM, Kalle Korhonen kalle.o.korho...@gmail.comwrote: ParallelExecutor is a service that allows work to occur in parallel using a thread pool. I doubt it's usefulness in your case. Simply create a new service, spawn threads in it as needed to do work and implement a few get status operations that your page(s) can call. That way, keeping the page up-to-date via AJAX is a separate concern. Kalle On Wed, Sep 1, 2010 at 12:06 PM, Norman Franke nor...@myasd.com wrote: I need a page that will start a long-running process involving heavy use of a database. I'm trying to come up with an elegant way to integrate this into my T5.1 app. I'd like to use Tapestry's IoC to inject my Hibernate DAOs. Then I'd like to write status updates to a stack and have an AJAX process poll and update the web page with what's happening. I see there is a ParallelExecutor in Tapestry, but I don't think it does injection. Any good solutions out there? Norman Franke Answering Service for Directors, Inc. www.myasd.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: @SetupRender and class hierarchy
t 5.1.0.5
re jira, will do.
p.
Howard Lewis Ship wrote:
On Tue, Aug 31, 2010 at 7:57 PM, Paul Stanton p...@mapshed.com.au wrote:
I've found a strange issue with the @SetupRender annotation when used in a
class hierarchy.
Typically, in java 2 classes within a hierarchy can have the same signature
for a private method and not effect each other, so I would expect this to be
the case when both of these private methods are annotated with @SetupRender.
Therefore the output for case 1 and case 2 (below) should be the same and
print both messages setupRender2, setupRender1.
However case 1 only prints setupRender2 meaning it somehow overwrites the
method in it's implementing class.
This is concerning because
1. there should never be a requirement that a sub-class knows of it's
super-classes implementation
2. if hierarchy does come into play, the subclass should override the super
class.
CASE 1:
--
public abstract class StartBase {
@SetupRender
private void init() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init() {
log.debug(setupRender1);
}
}
I think you are correct; it should invoke StartBase.init(), then
Start.init(), following the rule that parent class render event
methods are invoked before subclass render event methods.
Which release of Tapestry are you using?
I believe what's happening is that Tapestry is interpreting
Start.init() as an override of StartBase.init() the methods have
the same signature. Tapestry will effectively ignore the subclass
method because it will be invoked by the base class (again, the rule
about base class methods coming before subclass methods).
However, in this case, it is not correct. Because the method is
private, it is never an override of a base class method and should not
be ignored.
Please add a JIRA issue.
CASE 2:
--
public abstract class StartBase {
@SetupRender
private void init2() {
log.debug(setupRender2);
}
}
public class Start extends StartBase {
@SetupRender
private void init1() {
log.debug(setupRender1);
}
}
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5.1 and Threaded Background Tasks
Will there be some issue with the injected services? This async service when created will have it's injected services created in the thread of the current web request. When the new thread is created to process the data, the services will then be accessed from a different thread. Norman Franke Answering Service for Directors, Inc. www.myasd.com On Sep 1, 2010, at 4:03 PM, Kalle Korhonen wrote: ParallelExecutor is a service that allows work to occur in parallel using a thread pool. I doubt it's usefulness in your case. Simply create a new service, spawn threads in it as needed to do work and implement a few get status operations that your page(s) can call. That way, keeping the page up-to-date via AJAX is a separate concern. Kalle On Wed, Sep 1, 2010 at 12:06 PM, Norman Franke nor...@myasd.com wrote: I need a page that will start a long-running process involving heavy use of a database. I'm trying to come up with an elegant way to integrate this into my T5.1 app. I'd like to use Tapestry's IoC to inject my Hibernate DAOs. Then I'd like to write status updates to a stack and have an AJAX process poll and update the web page with what's happening. I see there is a ParallelExecutor in Tapestry, but I don't think it does injection. Any good solutions out there? Norman Franke Answering Service for Directors, Inc. www.myasd.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5.1 and Threaded Background Tasks
Thread safety is your responsibility, but services are singleton by default and it shouldn't matter to your DAOs which threads they are accessed from. What you need to worry about is the consistency of your data. When you say the new thread is created to process the data, what do you mean by it? If you are just writing to the database, then the database will handle the integrity of the data. If you do some in-memory processing of the data, then the integrity of it is yours to handle. Kalle On Wed, Sep 1, 2010 at 2:12 PM, Norman Franke nor...@myasd.com wrote: Will there be some issue with the injected services? This async service when created will have it's injected services created in the thread of the current web request. When the new thread is created to process the data, the services will then be accessed from a different thread. Norman Franke Answering Service for Directors, Inc. www.myasd.com On Sep 1, 2010, at 4:03 PM, Kalle Korhonen wrote: ParallelExecutor is a service that allows work to occur in parallel using a thread pool. I doubt it's usefulness in your case. Simply create a new service, spawn threads in it as needed to do work and implement a few get status operations that your page(s) can call. That way, keeping the page up-to-date via AJAX is a separate concern. Kalle On Wed, Sep 1, 2010 at 12:06 PM, Norman Franke nor...@myasd.com wrote: I need a page that will start a long-running process involving heavy use of a database. I'm trying to come up with an elegant way to integrate this into my T5.1 app. I'd like to use Tapestry's IoC to inject my Hibernate DAOs. Then I'd like to write status updates to a stack and have an AJAX process poll and update the web page with what's happening. I see there is a ParallelExecutor in Tapestry, but I don't think it does injection. Any good solutions out there? Norman Franke Answering Service for Directors, Inc. www.myasd.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5.1 and Threaded Background Tasks
The new thread is the one that will run in the background. My concern, and it may not be a concern, is that the request processing will have created my DAO objects associated with a Hibernate session in that thread, and I'll access it from another thread (the one running in the background.) I was worried that when the request finishes, Tapestry will release the DAO and Hibernate session. Norman Franke Answering Service for Directors, Inc. www.myasd.com On Sep 1, 2010, at 5:27 PM, Kalle Korhonen wrote: Thread safety is your responsibility, but services are singleton by default and it shouldn't matter to your DAOs which threads they are accessed from. What you need to worry about is the consistency of your data. When you say the new thread is created to process the data, what do you mean by it? If you are just writing to the database, then the database will handle the integrity of the data. If you do some in-memory processing of the data, then the integrity of it is yours to handle. Kalle On Wed, Sep 1, 2010 at 2:12 PM, Norman Franke nor...@myasd.com wrote: Will there be some issue with the injected services? This async service when created will have it's injected services created in the thread of the current web request. When the new thread is created to process the data, the services will then be accessed from a different thread. Norman Franke Answering Service for Directors, Inc. www.myasd.com On Sep 1, 2010, at 4:03 PM, Kalle Korhonen wrote: ParallelExecutor is a service that allows work to occur in parallel using a thread pool. I doubt it's usefulness in your case. Simply create a new service, spawn threads in it as needed to do work and implement a few get status operations that your page(s) can call. That way, keeping the page up-to-date via AJAX is a separate concern. Kalle On Wed, Sep 1, 2010 at 12:06 PM, Norman Franke nor...@myasd.com wrote: I need a page that will start a long-running process involving heavy use of a database. I'm trying to come up with an elegant way to integrate this into my T5.1 app. I'd like to use Tapestry's IoC to inject my Hibernate DAOs. Then I'd like to write status updates to a stack and have an AJAX process poll and update the web page with what's happening. I see there is a ParallelExecutor in Tapestry, but I don't think it does injection. Any good solutions out there? Norman Franke Answering Service for Directors, Inc. www.myasd.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5.1 and Threaded Background Tasks
On Wed, Sep 1, 2010 at 2:46 PM, Norman Franke nor...@myasd.com wrote: The new thread is the one that will run in the background. My concern, and it may not be a concern, is that the request processing will have created my DAO objects associated with a Hibernate session in that thread, and I'll access it from another thread (the one running in the background.) I was worried that when the request finishes, Tapestry will release the DAO and Hibernate session. Right. The DAOs don't matter (or if they do, you've designed them wrong), the entities do. The entity objects will become detached from the session after its closed. Don't hold onto the session longer than you have to, and remember that if you didn't create the session yourself, don't close it yourself and vice versa. If you are just (periodically) reading from the database, you'll only run into session issues in case you are using lazily-loaded objects. If you write periodically, make sure your entities are attached to a separate session. Kalle On Sep 1, 2010, at 5:27 PM, Kalle Korhonen wrote: Thread safety is your responsibility, but services are singleton by default and it shouldn't matter to your DAOs which threads they are accessed from. What you need to worry about is the consistency of your data. When you say the new thread is created to process the data, what do you mean by it? If you are just writing to the database, then the database will handle the integrity of the data. If you do some in-memory processing of the data, then the integrity of it is yours to handle. Kalle On Wed, Sep 1, 2010 at 2:12 PM, Norman Franke nor...@myasd.com wrote: Will there be some issue with the injected services? This async service when created will have it's injected services created in the thread of the current web request. When the new thread is created to process the data, the services will then be accessed from a different thread. Norman Franke Answering Service for Directors, Inc. www.myasd.com On Sep 1, 2010, at 4:03 PM, Kalle Korhonen wrote: ParallelExecutor is a service that allows work to occur in parallel using a thread pool. I doubt it's usefulness in your case. Simply create a new service, spawn threads in it as needed to do work and implement a few get status operations that your page(s) can call. That way, keeping the page up-to-date via AJAX is a separate concern. Kalle On Wed, Sep 1, 2010 at 12:06 PM, Norman Franke nor...@myasd.com wrote: I need a page that will start a long-running process involving heavy use of a database. I'm trying to come up with an elegant way to integrate this into my T5.1 app. I'd like to use Tapestry's IoC to inject my Hibernate DAOs. Then I'd like to write status updates to a stack and have an AJAX process poll and update the web page with what's happening. I see there is a ParallelExecutor in Tapestry, but I don't think it does injection. Any good solutions out there? Norman Franke Answering Service for Directors, Inc. www.myasd.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5.1 and Threaded Background Tasks
Right, so my question was, can I get Tapestry IoC to create me a new session for this new thread that won't be affected by anything else. I could duplicate the (lots) of code in the request filter, but that seems wrong. Norman Franke Answering Service for Directors, Inc. www.myasd.com On Sep 1, 2010, at 6:11 PM, Kalle Korhonen wrote: On Wed, Sep 1, 2010 at 2:46 PM, Norman Franke nor...@myasd.com wrote: The new thread is the one that will run in the background. My concern, and it may not be a concern, is that the request processing will have created my DAO objects associated with a Hibernate session in that thread, and I'll access it from another thread (the one running in the background.) I was worried that when the request finishes, Tapestry will release the DAO and Hibernate session. Right. The DAOs don't matter (or if they do, you've designed them wrong), the entities do. The entity objects will become detached from the session after its closed. Don't hold onto the session longer than you have to, and remember that if you didn't create the session yourself, don't close it yourself and vice versa. If you are just (periodically) reading from the database, you'll only run into session issues in case you are using lazily-loaded objects. If you write periodically, make sure your entities are attached to a separate session. Kalle On Sep 1, 2010, at 5:27 PM, Kalle Korhonen wrote: Thread safety is your responsibility, but services are singleton by default and it shouldn't matter to your DAOs which threads they are accessed from. What you need to worry about is the consistency of your data. When you say the new thread is created to process the data, what do you mean by it? If you are just writing to the database, then the database will handle the integrity of the data. If you do some in-memory processing of the data, then the integrity of it is yours to handle. Kalle On Wed, Sep 1, 2010 at 2:12 PM, Norman Franke nor...@myasd.com wrote: Will there be some issue with the injected services? This async service when created will have it's injected services created in the thread of the current web request. When the new thread is created to process the data, the services will then be accessed from a different thread. Norman Franke Answering Service for Directors, Inc. www.myasd.com On Sep 1, 2010, at 4:03 PM, Kalle Korhonen wrote: ParallelExecutor is a service that allows work to occur in parallel using a thread pool. I doubt it's usefulness in your case. Simply create a new service, spawn threads in it as needed to do work and implement a few get status operations that your page(s) can call. That way, keeping the page up-to-date via AJAX is a separate concern. Kalle On Wed, Sep 1, 2010 at 12:06 PM, Norman Franke nor...@myasd.com wrote: I need a page that will start a long-running process involving heavy use of a database. I'm trying to come up with an elegant way to integrate this into my T5.1 app. I'd like to use Tapestry's IoC to inject my Hibernate DAOs. Then I'd like to write status updates to a stack and have an AJAX process poll and update the web page with what's happening. I see there is a ParallelExecutor in Tapestry, but I don't think it does injection. Any good solutions out there? Norman Franke Answering Service for Directors, Inc. www.myasd.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5.1 and Threaded Background Tasks
HibernateSessionSource.create(); On Wed, Sep 1, 2010 at 3:19 PM, Norman Franke nor...@myasd.com wrote: Right, so my question was, can I get Tapestry IoC to create me a new session for this new thread that won't be affected by anything else. I could duplicate the (lots) of code in the request filter, but that seems wrong. Norman Franke Answering Service for Directors, Inc. www.myasd.com On Sep 1, 2010, at 6:11 PM, Kalle Korhonen wrote: On Wed, Sep 1, 2010 at 2:46 PM, Norman Franke nor...@myasd.com wrote: The new thread is the one that will run in the background. My concern, and it may not be a concern, is that the request processing will have created my DAO objects associated with a Hibernate session in that thread, and I'll access it from another thread (the one running in the background.) I was worried that when the request finishes, Tapestry will release the DAO and Hibernate session. Right. The DAOs don't matter (or if they do, you've designed them wrong), the entities do. The entity objects will become detached from the session after its closed. Don't hold onto the session longer than you have to, and remember that if you didn't create the session yourself, don't close it yourself and vice versa. If you are just (periodically) reading from the database, you'll only run into session issues in case you are using lazily-loaded objects. If you write periodically, make sure your entities are attached to a separate session. Kalle On Sep 1, 2010, at 5:27 PM, Kalle Korhonen wrote: Thread safety is your responsibility, but services are singleton by default and it shouldn't matter to your DAOs which threads they are accessed from. What you need to worry about is the consistency of your data. When you say the new thread is created to process the data, what do you mean by it? If you are just writing to the database, then the database will handle the integrity of the data. If you do some in-memory processing of the data, then the integrity of it is yours to handle. Kalle On Wed, Sep 1, 2010 at 2:12 PM, Norman Franke nor...@myasd.com wrote: Will there be some issue with the injected services? This async service when created will have it's injected services created in the thread of the current web request. When the new thread is created to process the data, the services will then be accessed from a different thread. Norman Franke Answering Service for Directors, Inc. www.myasd.com On Sep 1, 2010, at 4:03 PM, Kalle Korhonen wrote: ParallelExecutor is a service that allows work to occur in parallel using a thread pool. I doubt it's usefulness in your case. Simply create a new service, spawn threads in it as needed to do work and implement a few get status operations that your page(s) can call. That way, keeping the page up-to-date via AJAX is a separate concern. Kalle On Wed, Sep 1, 2010 at 12:06 PM, Norman Franke nor...@myasd.com wrote: I need a page that will start a long-running process involving heavy use of a database. I'm trying to come up with an elegant way to integrate this into my T5.1 app. I'd like to use Tapestry's IoC to inject my Hibernate DAOs. Then I'd like to write status updates to a stack and have an AJAX process poll and update the web page with what's happening. I see there is a ParallelExecutor in Tapestry, but I don't think it does injection. Any good solutions out there? Norman Franke Answering Service for Directors, Inc. www.myasd.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: T5.1 and Threaded Background Tasks
Services in Tapestry IoC are always proxies(*); the proxies encapsulate thread-safe instantiation of the service, as well as the lifecycle of the service (singleton or perthread). Please see the documentation of the PerthreadManager service for some additional notes. So, yes, it is valid for a service to start a thread and for that thread to do work with injected services even while other threads are invoking methods on the same services. No problems at all. (*) The exception is services with no service interface, just an implementation class, which can't be proxied. They will, however, still be instantiated in a thread safe manner, just a bit earlier than necessary. On Wed, Sep 1, 2010 at 2:12 PM, Norman Franke nor...@myasd.com wrote: Will there be some issue with the injected services? This async service when created will have it's injected services created in the thread of the current web request. When the new thread is created to process the data, the services will then be accessed from a different thread. Norman Franke Answering Service for Directors, Inc. www.myasd.com On Sep 1, 2010, at 4:03 PM, Kalle Korhonen wrote: ParallelExecutor is a service that allows work to occur in parallel using a thread pool. I doubt it's usefulness in your case. Simply create a new service, spawn threads in it as needed to do work and implement a few get status operations that your page(s) can call. That way, keeping the page up-to-date via AJAX is a separate concern. Kalle On Wed, Sep 1, 2010 at 12:06 PM, Norman Franke nor...@myasd.com wrote: I need a page that will start a long-running process involving heavy use of a database. I'm trying to come up with an elegant way to integrate this into my T5.1 app. I'd like to use Tapestry's IoC to inject my Hibernate DAOs. Then I'd like to write status updates to a stack and have an AJAX process poll and update the web page with what's happening. I see there is a ParallelExecutor in Tapestry, but I don't think it does injection. Any good solutions out there? Norman Franke Answering Service for Directors, Inc. www.myasd.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: File Handling and Buffer Handling
Hi Thiago!, I also use java.awt.Rectangle, java.awt.image.BufferedImage packages for my code ... is it ok? charith On Wed, Sep 1, 2010 at 6:36 PM, Thiago H. de Paula Figueiredo thiag...@gmail.com wrote: On Wed, 01 Sep 2010 10:04:42 -0300, Charith Madusanka charithc...@gmail.com wrote: Hi Thiago! Hi! Thank your comment. http://download.oracle.com/javase/1.5.0/docs/api/java/io/InputStream.htmlusing this class is ok? Yes. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: File Handling and Buffer Handling
On Thu, 02 Sep 2010 00:35:18 -0300, Charith Madusanka charithc...@gmail.com wrote: Hi Thiago!, Hi! I also use java.awt.Rectangle, java.awt.image.BufferedImage packages for my code ... is it ok? As long as you're dealing with images, it is ok. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
URL to file
Hi! Is there any simple way to get URL to file in T5 API? Like smiler to URLConnection con = url.openConnection(); charith
