Re: Hibernate call returns wrong day
I also checked the default PostgreSQL timezone (in the postgresql.conf
file), which is set to "Poland".
2016-03-30 8:47 GMT+02:00 g kuczera :
> I observed that behavior on the production server and then confirmed it on
> the test server, which is not accessed by any client, etc. I forgot to
> mention that the calendar.getTimeZone().getDisplayName() call returns
> "Central European Time".
>
> 2016-03-30 3:56 GMT+02:00 Kalle Korhonen :
>
>> The same thread really reads the same value from the database every few
>> seconds and it may come out different? I don't buy it, there must be
>> something else going on at the same time. Are you sure it's the same
>> value?
>> Is there something else writing to it at the same time? Can the system
>> default timezone change (perhaps also print out TimeZone.getDefault(),
>> Date
>> initialized to the default timezone). I'd still suspect some type of
>> timezone issue.
>>
>> Kalle
>>
>> On Tue, Mar 29, 2016 at 3:39 PM, g kuczera wrote:
>>
>> > Hi guys,
>> > First of all, thanks for the answer and the effort you put into writing
>> > them.
>> >
>> > I checked few things and read couple of articles about similar problems
>> and
>> > here is my little summary:
>> >
>> >- my PostgreSQL birthDate column's type is 'birthDate TIMESTAMP
>> WITHOUT
>> >TIME ZONE'
>> >- the values contained by the column do not have the time part, the
>> >year-month-day is used, eg. 1982-03-28
>> >- then the user Entity has the birth date field with annotations
>> >
>> > @Column(name = "birthDate ")
>> >
>> > @Temporal(TemporalType.DATE)
>> >
>> > private java.util.Date birthDate;
>> >
>> >
>> >- the call calendar.getTimeZone().getDisplayName() returns
>> >
>> > The Calendar instance is created in this way:
>> >
>> > Calendar calendar = Calendar.getInstance();
>> > calendar.setTime(user.getBirthDate());
>> >
>> >
>> > So the TIMESTAMP value from the database is interpreted as the
>> > java.util.Date, what is achieved by putting the Temporal annotation.
>> Then,
>> > when I call the getter (getBirthDate method) the "truncated" TIMESTAMP
>> is
>> > returned.
>> >
>> > But still, after fetching the birthDate for 4 times, the fifth one
>> becomes
>> > corrupted:
>> >
>> > 30-03-16 00:25:36:746 - {INFO} profil.ProfilEdition Thread
>> > [qtp1357767732-54]; birth date equals (setupRender - getting from raw
>> > query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
>> > 30-03-16 00:25:44:497 - {INFO} profil.ProfilEdition Thread
>> > [qtp1357767732-65]; birth date equals (setupRender - getting from raw
>> > query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
>> > 30-03-16 00:25:46:037 - {INFO} profil.ProfilEdition Thread
>> > [qtp1357767732-60]; birth date equals (setupRender - getting from raw
>> > query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
>> > 30-03-16 00:25:46:884 - {INFO} profil.ProfilEdition Thread
>> > [qtp1357767732-62]; birth date equals (setupRender - getting from raw
>> > query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
>> > 30-03-16 00:25:48:843 - {INFO} profil.ProfilEdition Thread
>> > [qtp1357767732-63]; birth date equals (setupRender - getting from raw
>> > query): 1982-03-27 23:00:00.0, 1982-03-27 23:00:00.0
>> >
>> > The log comes from casting the raw query result to java.sql.Timestamp.
>> The
>> > value after comma is the same one, but casted to java.util.Date (these
>> are
>> > results of toString method)..
>> >
>> > I will continue to investigate the thing tomorrow.
>> >
>> > 2016-03-24 15:47 GMT+01:00 Cezary Biernacki :
>> >
>> > > Hi,
>> > > I doubt it is a Tapestry related problem. I have seen similar issues,
>> and
>> > > they are generally caused by time zone translations. My guess is that
>> > your
>> > > database stores date birth as a timestamp (i.e. including specific
>> hours
>> > > and minutes) in some specific time zone, and your Java code retrieving
>> > > timestamps translates it to a different time zone. To diagnose, you
>> > should
>> > > check what is actually stored in the database, what kind of data type
>> is
>> > > used to store date of birth (database engines often have many options
>> to
>> > > store dates and timestamps including or not time zones), what Java
>> type
>> > is
>> > > returned by user.getBirthDate() and what is the actual returned value
>> > > (exact content, not result of toString()), and what assumptions about
>> > using
>> > > time zones your JDBC driver is making. Typically problems arise when
>> some
>> > > parts of the systems treat time stamps as set in UTC and others apply
>> > user
>> > > (client) default time zone. To fix this, one should have methodically
>> > > ensure that all parts are using consistent time zone policy, and any
>> time
>> > > zone translations occur only when necessary.
>> > >
>> > > Best regards,
>> > > Cezary
>> > >
>> > >
>> > > On Tue, Mar 22, 2016 at 8:55 PM, g kuczera
>> wrote:
>> > >
>> > > > Hi guys,
>> > > > I do not really know if it is connected with
Re: Hibernate call returns wrong day
I observed that behavior on the production server and then confirmed it on
the test server, which is not accessed by any client, etc. I forgot to
mention that the calendar.getTimeZone().getDisplayName() call returns
"Central European Time".
2016-03-30 3:56 GMT+02:00 Kalle Korhonen :
> The same thread really reads the same value from the database every few
> seconds and it may come out different? I don't buy it, there must be
> something else going on at the same time. Are you sure it's the same value?
> Is there something else writing to it at the same time? Can the system
> default timezone change (perhaps also print out TimeZone.getDefault(), Date
> initialized to the default timezone). I'd still suspect some type of
> timezone issue.
>
> Kalle
>
> On Tue, Mar 29, 2016 at 3:39 PM, g kuczera wrote:
>
> > Hi guys,
> > First of all, thanks for the answer and the effort you put into writing
> > them.
> >
> > I checked few things and read couple of articles about similar problems
> and
> > here is my little summary:
> >
> >- my PostgreSQL birthDate column's type is 'birthDate TIMESTAMP
> WITHOUT
> >TIME ZONE'
> >- the values contained by the column do not have the time part, the
> >year-month-day is used, eg. 1982-03-28
> >- then the user Entity has the birth date field with annotations
> >
> > @Column(name = "birthDate ")
> >
> > @Temporal(TemporalType.DATE)
> >
> > private java.util.Date birthDate;
> >
> >
> >- the call calendar.getTimeZone().getDisplayName() returns
> >
> > The Calendar instance is created in this way:
> >
> > Calendar calendar = Calendar.getInstance();
> > calendar.setTime(user.getBirthDate());
> >
> >
> > So the TIMESTAMP value from the database is interpreted as the
> > java.util.Date, what is achieved by putting the Temporal annotation.
> Then,
> > when I call the getter (getBirthDate method) the "truncated" TIMESTAMP is
> > returned.
> >
> > But still, after fetching the birthDate for 4 times, the fifth one
> becomes
> > corrupted:
> >
> > 30-03-16 00:25:36:746 - {INFO} profil.ProfilEdition Thread
> > [qtp1357767732-54]; birth date equals (setupRender - getting from raw
> > query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
> > 30-03-16 00:25:44:497 - {INFO} profil.ProfilEdition Thread
> > [qtp1357767732-65]; birth date equals (setupRender - getting from raw
> > query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
> > 30-03-16 00:25:46:037 - {INFO} profil.ProfilEdition Thread
> > [qtp1357767732-60]; birth date equals (setupRender - getting from raw
> > query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
> > 30-03-16 00:25:46:884 - {INFO} profil.ProfilEdition Thread
> > [qtp1357767732-62]; birth date equals (setupRender - getting from raw
> > query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
> > 30-03-16 00:25:48:843 - {INFO} profil.ProfilEdition Thread
> > [qtp1357767732-63]; birth date equals (setupRender - getting from raw
> > query): 1982-03-27 23:00:00.0, 1982-03-27 23:00:00.0
> >
> > The log comes from casting the raw query result to java.sql.Timestamp.
> The
> > value after comma is the same one, but casted to java.util.Date (these
> are
> > results of toString method)..
> >
> > I will continue to investigate the thing tomorrow.
> >
> > 2016-03-24 15:47 GMT+01:00 Cezary Biernacki :
> >
> > > Hi,
> > > I doubt it is a Tapestry related problem. I have seen similar issues,
> and
> > > they are generally caused by time zone translations. My guess is that
> > your
> > > database stores date birth as a timestamp (i.e. including specific
> hours
> > > and minutes) in some specific time zone, and your Java code retrieving
> > > timestamps translates it to a different time zone. To diagnose, you
> > should
> > > check what is actually stored in the database, what kind of data type
> is
> > > used to store date of birth (database engines often have many options
> to
> > > store dates and timestamps including or not time zones), what Java type
> > is
> > > returned by user.getBirthDate() and what is the actual returned value
> > > (exact content, not result of toString()), and what assumptions about
> > using
> > > time zones your JDBC driver is making. Typically problems arise when
> some
> > > parts of the systems treat time stamps as set in UTC and others apply
> > user
> > > (client) default time zone. To fix this, one should have methodically
> > > ensure that all parts are using consistent time zone policy, and any
> time
> > > zone translations occur only when necessary.
> > >
> > > Best regards,
> > > Cezary
> > >
> > >
> > > On Tue, Mar 22, 2016 at 8:55 PM, g kuczera wrote:
> > >
> > > > Hi guys,
> > > > I do not really know if it is connected with tapestry or only the
> > > > Hibernate, but maybe that is the case. So there is a embedded
> calendar
> > on
> > > > the site, the one from tapestry-jquery library:
> > > > http://tapestry5-jquery.com/mixins/docscustomdatepicker
> > > >
> > > > If the user chose - during registration
Re: Hibernate call returns wrong day
The same thread really reads the same value from the database every few
seconds and it may come out different? I don't buy it, there must be
something else going on at the same time. Are you sure it's the same value?
Is there something else writing to it at the same time? Can the system
default timezone change (perhaps also print out TimeZone.getDefault(), Date
initialized to the default timezone). I'd still suspect some type of
timezone issue.
Kalle
On Tue, Mar 29, 2016 at 3:39 PM, g kuczera wrote:
> Hi guys,
> First of all, thanks for the answer and the effort you put into writing
> them.
>
> I checked few things and read couple of articles about similar problems and
> here is my little summary:
>
>- my PostgreSQL birthDate column's type is 'birthDate TIMESTAMP WITHOUT
>TIME ZONE'
>- the values contained by the column do not have the time part, the
>year-month-day is used, eg. 1982-03-28
>- then the user Entity has the birth date field with annotations
>
> @Column(name = "birthDate ")
>
> @Temporal(TemporalType.DATE)
>
> private java.util.Date birthDate;
>
>
>- the call calendar.getTimeZone().getDisplayName() returns
>
> The Calendar instance is created in this way:
>
> Calendar calendar = Calendar.getInstance();
> calendar.setTime(user.getBirthDate());
>
>
> So the TIMESTAMP value from the database is interpreted as the
> java.util.Date, what is achieved by putting the Temporal annotation. Then,
> when I call the getter (getBirthDate method) the "truncated" TIMESTAMP is
> returned.
>
> But still, after fetching the birthDate for 4 times, the fifth one becomes
> corrupted:
>
> 30-03-16 00:25:36:746 - {INFO} profil.ProfilEdition Thread
> [qtp1357767732-54]; birth date equals (setupRender - getting from raw
> query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
> 30-03-16 00:25:44:497 - {INFO} profil.ProfilEdition Thread
> [qtp1357767732-65]; birth date equals (setupRender - getting from raw
> query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
> 30-03-16 00:25:46:037 - {INFO} profil.ProfilEdition Thread
> [qtp1357767732-60]; birth date equals (setupRender - getting from raw
> query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
> 30-03-16 00:25:46:884 - {INFO} profil.ProfilEdition Thread
> [qtp1357767732-62]; birth date equals (setupRender - getting from raw
> query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
> 30-03-16 00:25:48:843 - {INFO} profil.ProfilEdition Thread
> [qtp1357767732-63]; birth date equals (setupRender - getting from raw
> query): 1982-03-27 23:00:00.0, 1982-03-27 23:00:00.0
>
> The log comes from casting the raw query result to java.sql.Timestamp. The
> value after comma is the same one, but casted to java.util.Date (these are
> results of toString method)..
>
> I will continue to investigate the thing tomorrow.
>
> 2016-03-24 15:47 GMT+01:00 Cezary Biernacki :
>
> > Hi,
> > I doubt it is a Tapestry related problem. I have seen similar issues, and
> > they are generally caused by time zone translations. My guess is that
> your
> > database stores date birth as a timestamp (i.e. including specific hours
> > and minutes) in some specific time zone, and your Java code retrieving
> > timestamps translates it to a different time zone. To diagnose, you
> should
> > check what is actually stored in the database, what kind of data type is
> > used to store date of birth (database engines often have many options to
> > store dates and timestamps including or not time zones), what Java type
> is
> > returned by user.getBirthDate() and what is the actual returned value
> > (exact content, not result of toString()), and what assumptions about
> using
> > time zones your JDBC driver is making. Typically problems arise when some
> > parts of the systems treat time stamps as set in UTC and others apply
> user
> > (client) default time zone. To fix this, one should have methodically
> > ensure that all parts are using consistent time zone policy, and any time
> > zone translations occur only when necessary.
> >
> > Best regards,
> > Cezary
> >
> >
> > On Tue, Mar 22, 2016 at 8:55 PM, g kuczera wrote:
> >
> > > Hi guys,
> > > I do not really know if it is connected with tapestry or only the
> > > Hibernate, but maybe that is the case. So there is a embedded calendar
> on
> > > the site, the one from tapestry-jquery library:
> > > http://tapestry5-jquery.com/mixins/docscustomdatepicker
> > >
> > > If the user chose - during registration - the 28/03/1982 date, the
> value
> > > will be correctly save to the database. But if you want to change this
> > date
> > > and the calendar is going to be prepared, the date retrieved by the
> > UserDao
> > > (the birthDate field) equals to 27/03/1982.
> > >
> > > I use the DAOs layer, which uses the Hibernate session. It is
> > automatically
> > > passed as an argument during the binding process (in the AppModule
> > class):
> > >
> > > binder.bind(UserDao.class,
> > > UserDaoImpl.class).scope(ScopeConstants.PERTH
Re: Hibernate call returns wrong day
Hi guys,
First of all, thanks for the answer and the effort you put into writing
them.
I checked few things and read couple of articles about similar problems and
here is my little summary:
- my PostgreSQL birthDate column's type is 'birthDate TIMESTAMP WITHOUT
TIME ZONE'
- the values contained by the column do not have the time part, the
year-month-day is used, eg. 1982-03-28
- then the user Entity has the birth date field with annotations
@Column(name = "birthDate ")
@Temporal(TemporalType.DATE)
private java.util.Date birthDate;
- the call calendar.getTimeZone().getDisplayName() returns
The Calendar instance is created in this way:
Calendar calendar = Calendar.getInstance();
calendar.setTime(user.getBirthDate());
So the TIMESTAMP value from the database is interpreted as the
java.util.Date, what is achieved by putting the Temporal annotation. Then,
when I call the getter (getBirthDate method) the "truncated" TIMESTAMP is
returned.
But still, after fetching the birthDate for 4 times, the fifth one becomes
corrupted:
30-03-16 00:25:36:746 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-54]; birth date equals (setupRender - getting from raw
query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
30-03-16 00:25:44:497 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-65]; birth date equals (setupRender - getting from raw
query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
30-03-16 00:25:46:037 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-60]; birth date equals (setupRender - getting from raw
query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
30-03-16 00:25:46:884 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-62]; birth date equals (setupRender - getting from raw
query): 1982-03-28 00:00:00.0, 1982-03-28 00:00:00.0
30-03-16 00:25:48:843 - {INFO} profil.ProfilEdition Thread
[qtp1357767732-63]; birth date equals (setupRender - getting from raw
query): 1982-03-27 23:00:00.0, 1982-03-27 23:00:00.0
The log comes from casting the raw query result to java.sql.Timestamp. The
value after comma is the same one, but casted to java.util.Date (these are
results of toString method)..
I will continue to investigate the thing tomorrow.
2016-03-24 15:47 GMT+01:00 Cezary Biernacki :
> Hi,
> I doubt it is a Tapestry related problem. I have seen similar issues, and
> they are generally caused by time zone translations. My guess is that your
> database stores date birth as a timestamp (i.e. including specific hours
> and minutes) in some specific time zone, and your Java code retrieving
> timestamps translates it to a different time zone. To diagnose, you should
> check what is actually stored in the database, what kind of data type is
> used to store date of birth (database engines often have many options to
> store dates and timestamps including or not time zones), what Java type is
> returned by user.getBirthDate() and what is the actual returned value
> (exact content, not result of toString()), and what assumptions about using
> time zones your JDBC driver is making. Typically problems arise when some
> parts of the systems treat time stamps as set in UTC and others apply user
> (client) default time zone. To fix this, one should have methodically
> ensure that all parts are using consistent time zone policy, and any time
> zone translations occur only when necessary.
>
> Best regards,
> Cezary
>
>
> On Tue, Mar 22, 2016 at 8:55 PM, g kuczera wrote:
>
> > Hi guys,
> > I do not really know if it is connected with tapestry or only the
> > Hibernate, but maybe that is the case. So there is a embedded calendar on
> > the site, the one from tapestry-jquery library:
> > http://tapestry5-jquery.com/mixins/docscustomdatepicker
> >
> > If the user chose - during registration - the 28/03/1982 date, the value
> > will be correctly save to the database. But if you want to change this
> date
> > and the calendar is going to be prepared, the date retrieved by the
> UserDao
> > (the birthDate field) equals to 27/03/1982.
> >
> > I use the DAOs layer, which uses the Hibernate session. It is
> automatically
> > passed as an argument during the binding process (in the AppModule
> class):
> >
> > binder.bind(UserDao.class,
> > UserDaoImpl.class).scope(ScopeConstants.PERTHREAD);
> >
> > The UserDao is used in setupRender and onActivate methods of my page
> (user
> > is an javax Entity):
> >
> > user = userDao.load(userId);
> > user.getBirthDate().toString()
> >
> > What's funny, if I use the Hibernate in the different way
> >
> > List birthDatesList = userDao.getSession().createSQLQuery("select
> > birthdate from user where id = " + userId).list();
> > java.sql.Timestamp birthDate =
> (java.sql.Timestamp)(birthDatesList.get(0));
> > log.info("setupRender (birth date): " + birthDate.toString());
> >
> > the returned date is correct.
> >
> > I also logged the birth dates of the other users, and the problem occurs
> > only in the 28/03/1982 case. Have you ever noticed anyth
Re: Strange error when trying to deploy update from 5.3 to 5.4
Thank you. Looks like i can't delpoy on same appserver different tapestry wars. Problem solved. On 29 March 2016 at 13:58, Barry Books wrote: > Make sure you don't have the 5.3 and 5.4 jars in your war file. For some > reason this always seems to happen after an upgrade and it produces strange > errors. > > On Tuesday, March 29, 2016, Pavel Chernyak wrote: > > > Greetings. > > I have strange error after trying to migrate from 5.3.8 to 5.4. > > I using: > > > > tapestry-core 5.4.0 > > > > tapestry-upload 5.4.0 > > > > tapestry-hibernate 5.4.0 > > > > tynamo tapestry-security 0.6.2 > > > > tynamo tapestry-conversations 0.2.0 > > > > tynamo tapestry-routing 0.1.1 > > > > > > On my local machine with jetty:run everything works fine, but when i > deploy > > app to jetty on server i recieve this stack trace. > > It's look like error TAP5-2516 > > https://issues.apache.org/jira/browse/TAP5-2516 ,but with other output. > > > > HTTP ERROR 500 > > > > Problem accessing /login/unauthenticated. Reason: > > > > Server Error > > > > Caused by: > > > > org.apache.shiro.subject.ExecutionException: > > org.apache.tapestry5.ioc.internal.OperationException > > at > > > org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:385) > > at > > > org.tynamo.security.services.impl.SecurityConfiguration.service(SecurityConfiguration.java:54) > > at $HttpServletRequestFilter_ce2c127043029.service(Unknown > Source) > > at $HttpServletRequestHandler_ce2c12704302c.service(Unknown > Source) > > at > > > org.apache.tapestry5.upload.internal.services.MultipartServletRequestFilter.service(MultipartServletRequestFilter.java:45) > > at $HttpServletRequestHandler_ce2c12704302c.service(Unknown > Source) > > at > > org.apache.tapestry5.internal.gzip.GZipFilter.service(GZipFilter.java:59) > > at $HttpServletRequestHandler_ce2c12704302c.service(Unknown > Source) > > at > > > org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62) > > at $HttpServletRequestFilter_ce2c127043025.service(Unknown > Source) > > at $HttpServletRequestHandler_ce2c12704302c.service(Unknown > Source) > > at > > > org.apache.tapestry5.modules.TapestryModule$1.service(TapestryModule.java:796) > > at $HttpServletRequestHandler_ce2c12704302c.service(Unknown > Source) > > at $HttpServletRequestHandler_ce2c127043024.service(Unknown > Source) > > at > > org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:166) > > at > > > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) > > at > > > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) > > at > > > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > > at > > > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > > at > > > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) > > at > > > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) > > at > > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) > > at > > > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) > > at > > > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) > > at > > > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > > at > > > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) > > at > > > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) > > at > > > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) > > at org.eclipse.jetty.server.Server.handle(Server.java:499) > > at > > org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) > > at > > > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) > > at > > > org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) > > at > > > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) > > at > > > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) > > at java.lang.Thread.run(Thread.java:745) > > Caused by: org.apache.tapestry5.ioc.internal.OperationException > > at > > > org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:186) > > at > > > org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:90) > > at > > > org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:72) > > at > > > org.apache.tapestry5.ioc.interna
Strange error after deploy to jetty with tapestry 5.4.
Greetings. I have strange error after trying to migrate t5.3.8 to 5.4. I using: tapestry-core 5.4.0 tapestry-upload 5.4.0 tapestry-hibernate 5.4.0 tynamo tapestry-security 0.6.2 tynamo tapestry-conversations 0.2.0 tynamo tapestry-routing 0.1.1 On my local machine with jetty:run everything works fine, but when i deploy app to jetty on server i recieve this stack trace. It's look like error TAP5-2516 https://issues.apache.org/jira/browse/TAP5-2516 ,but with other output. HTTP ERROR 500 Problem accessing /login/unauthenticated. Reason: Server Error Caused by: org.apache.shiro.subject.ExecutionException: org.apache.tapestry5.ioc.internal.OperationException at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:385) at org.tynamo.security.services.impl.SecurityConfiguration.service(SecurityConfiguration.java:54) at $HttpServletRequestFilter_ce2c127043029.service(Unknown Source) at $HttpServletRequestHandler_ce2c12704302c.service(Unknown Source) at org.apache.tapestry5.upload.internal.services.MultipartServletRequestFilter.service(MultipartServletRequestFilter.java:45) at $HttpServletRequestHandler_ce2c12704302c.service(Unknown Source) at org.apache.tapestry5.internal.gzip.GZipFilter.service(GZipFilter.java:59) at $HttpServletRequestHandler_ce2c12704302c.service(Unknown Source) at org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62) at $HttpServletRequestFilter_ce2c127043025.service(Unknown Source) at $HttpServletRequestHandler_ce2c12704302c.service(Unknown Source) at org.apache.tapestry5.modules.TapestryModule$1.service(TapestryModule.java:796) at $HttpServletRequestHandler_ce2c12704302c.service(Unknown Source) at $HttpServletRequestHandler_ce2c127043024.service(Unknown Source) at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:166) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at org.eclipse.jetty.server.Server.handle(Server.java:499) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) at java.lang.Thread.run(Thread.java:745) Caused by: org.apache.tapestry5.ioc.internal.OperationException at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:186) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:90) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:72) at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1260) at org.apache.tapestry5.internal.services.TemplateParserImpl.parseTemplate(TemplateParserImpl.java:57) at $TemplateParser_ce2c12704306a.parseTemplate(Unknown Source) at org.apache.tapestry5.internal.services.ComponentTemplateSourceImpl.parseTemplate(ComponentTemplateSourceImpl.java:190) at org.apache.tapestry5.internal.services.ComponentTemplateSourceImpl.getTemplate(ComponentTemplateSourceImpl.java:162) at $ComponentTemplateSource_ce2c127043069.getTemplate(Unknown Source) at org.apache.tapestry5.internal.pageload.PageLoaderImpl$4.invoke(PageLoaderImpl.java:258) at org.apache.tapestry5.internal.pageload.PageLoaderImpl$4.invoke(PageLoaderImpl.java:251) at org.apache.tapestry5.i
Re: Strange error when trying to deploy update from 5.3 to 5.4
Make sure you don't have the 5.3 and 5.4 jars in your war file. For some reason this always seems to happen after an upgrade and it produces strange errors. On Tuesday, March 29, 2016, Pavel Chernyak wrote: > Greetings. > I have strange error after trying to migrate from 5.3.8 to 5.4. > I using: > > tapestry-core 5.4.0 > > tapestry-upload 5.4.0 > > tapestry-hibernate 5.4.0 > > tynamo tapestry-security 0.6.2 > > tynamo tapestry-conversations 0.2.0 > > tynamo tapestry-routing 0.1.1 > > > On my local machine with jetty:run everything works fine, but when i deploy > app to jetty on server i recieve this stack trace. > It's look like error TAP5-2516 > https://issues.apache.org/jira/browse/TAP5-2516 ,but with other output. > > HTTP ERROR 500 > > Problem accessing /login/unauthenticated. Reason: > > Server Error > > Caused by: > > org.apache.shiro.subject.ExecutionException: > org.apache.tapestry5.ioc.internal.OperationException > at > org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:385) > at > org.tynamo.security.services.impl.SecurityConfiguration.service(SecurityConfiguration.java:54) > at $HttpServletRequestFilter_ce2c127043029.service(Unknown Source) > at $HttpServletRequestHandler_ce2c12704302c.service(Unknown Source) > at > org.apache.tapestry5.upload.internal.services.MultipartServletRequestFilter.service(MultipartServletRequestFilter.java:45) > at $HttpServletRequestHandler_ce2c12704302c.service(Unknown Source) > at > org.apache.tapestry5.internal.gzip.GZipFilter.service(GZipFilter.java:59) > at $HttpServletRequestHandler_ce2c12704302c.service(Unknown Source) > at > org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62) > at $HttpServletRequestFilter_ce2c127043025.service(Unknown Source) > at $HttpServletRequestHandler_ce2c12704302c.service(Unknown Source) > at > org.apache.tapestry5.modules.TapestryModule$1.service(TapestryModule.java:796) > at $HttpServletRequestHandler_ce2c12704302c.service(Unknown Source) > at $HttpServletRequestHandler_ce2c127043024.service(Unknown Source) > at > org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:166) > at > org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) > at > org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) > at > org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) > at > org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) > at > org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) > at > org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) > at > org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) > at org.eclipse.jetty.server.Server.handle(Server.java:499) > at > org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) > at > org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) > at > org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) > at java.lang.Thread.run(Thread.java:745) > Caused by: org.apache.tapestry5.ioc.internal.OperationException > at > org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:186) > at > org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:90) > at > org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:72) > at > org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1260) > at > org.apache.tapestry5.internal.services.TemplateParserImpl.parseTemplate(TemplateParserImpl.java:57) > at $TemplateParser_ce2c12704306a.parseTemplate(Unknown Source) > at > org.apache.tapestry5.internal.services.ComponentTemplateSourceImpl.parseTemplate(ComponentTemplateSourceImpl.java:190) > at > org.apache.tapestry5.internal.services.Com
Strange error when trying to deploy update from 5.3 to 5.4
Greetings. I have strange error after trying to migrate from 5.3.8 to 5.4. I using: tapestry-core 5.4.0 tapestry-upload 5.4.0 tapestry-hibernate 5.4.0 tynamo tapestry-security 0.6.2 tynamo tapestry-conversations 0.2.0 tynamo tapestry-routing 0.1.1 On my local machine with jetty:run everything works fine, but when i deploy app to jetty on server i recieve this stack trace. It's look like error TAP5-2516 https://issues.apache.org/jira/browse/TAP5-2516 ,but with other output. HTTP ERROR 500 Problem accessing /login/unauthenticated. Reason: Server Error Caused by: org.apache.shiro.subject.ExecutionException: org.apache.tapestry5.ioc.internal.OperationException at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:385) at org.tynamo.security.services.impl.SecurityConfiguration.service(SecurityConfiguration.java:54) at $HttpServletRequestFilter_ce2c127043029.service(Unknown Source) at $HttpServletRequestHandler_ce2c12704302c.service(Unknown Source) at org.apache.tapestry5.upload.internal.services.MultipartServletRequestFilter.service(MultipartServletRequestFilter.java:45) at $HttpServletRequestHandler_ce2c12704302c.service(Unknown Source) at org.apache.tapestry5.internal.gzip.GZipFilter.service(GZipFilter.java:59) at $HttpServletRequestHandler_ce2c12704302c.service(Unknown Source) at org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62) at $HttpServletRequestFilter_ce2c127043025.service(Unknown Source) at $HttpServletRequestHandler_ce2c12704302c.service(Unknown Source) at org.apache.tapestry5.modules.TapestryModule$1.service(TapestryModule.java:796) at $HttpServletRequestHandler_ce2c12704302c.service(Unknown Source) at $HttpServletRequestHandler_ce2c127043024.service(Unknown Source) at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:166) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97) at org.eclipse.jetty.server.Server.handle(Server.java:499) at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310) at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257) at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555) at java.lang.Thread.run(Thread.java:745) Caused by: org.apache.tapestry5.ioc.internal.OperationException at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:186) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:90) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:72) at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1260) at org.apache.tapestry5.internal.services.TemplateParserImpl.parseTemplate(TemplateParserImpl.java:57) at $TemplateParser_ce2c12704306a.parseTemplate(Unknown Source) at org.apache.tapestry5.internal.services.ComponentTemplateSourceImpl.parseTemplate(ComponentTemplateSourceImpl.java:190) at org.apache.tapestry5.internal.services.ComponentTemplateSourceImpl.getTemplate(ComponentTemplateSourceImpl.java:162) at $ComponentTemplateSource_ce2c127043069.getTemplate(Unknown Source) at org.apache.tapestry5.internal.pageload.PageLoaderImpl$4.invoke(PageLoaderImpl.java:258) at org.apache.tapestry5.internal.pageload.PageLoaderImpl$4.invoke(PageLoaderImpl.java:251) at org.apache.tapestr
Re: Hiding FormFragment via javascript
I can’t remember all the problems I had when combining FormFragment with Loop
with modals, but I do know that I solved them all by moving the FormFragment to
above the loop, adding an If, putting the modal inside it and, on submit of the
modal, the server-side updated the relevant loop item’s values. This allowed it
to handle create, update, and delete of loop items.
Admittedly this is with T5.4, but I don’t expect that to make much difference.
For example, here’s a snippet. It’s from a component that I’ll call
ThingsEditor.
...
...
...
${message:add-label}
Does that help?
Geoff
> On 24 Mar 2016, at 7:25 PM, Hendrik Grewe wrote:
>
> Hi Dimitris!
>
> we are currently running Tapestry 5.3.8.
> An Upgrade to T5.4 is currently not feasible.
>
> Hendrik
>
> Am 24.03.2016 um 00:17 schrieb Dimitris Zenios:
>> hendrk what version of tapestry are you using?
>> On 23 Mar 2016 16:00, "Hendrik Grewe" wrote:
>>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
Re: Hiding FormFragment via javascript
Hi Dimitris! we are currently running Tapestry 5.3.8. An Upgrade to T5.4 is currently not feasible. Hendrik Am 24.03.2016 um 00:17 schrieb Dimitris Zenios: > hendrk what version of tapestry are you using? > On 23 Mar 2016 16:00, "Hendrik Grewe" wrote: > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Tapestry 5.3.7 with Tanuki service wrapper
Hi, Has anyone had success running ioc via the Tanuki Service Wrapper product? I'm having problems with Tapestry instantiating a DAO service that is injected with EntityManager references. Suspect a class loader problem, I'm getting inconsistent results. All works fine from the command line launch? Probably means this isn't a Tapestry issue, but just interested to know anyone who's had a good result with Tanuki starting Tapestry? John
