Hi Albert,
it's not a bug of ULC 6.1, as explained in the two attachements I sent earlier
to you and that are included here once more
for the community. But probably Canoo might change the behaviour concerning
java.sql.Date, java.sql.Time and
java.sql.Timestamp so that code like
if (value != null) {
if (value instanceof java.sql.Date | value instanceof java.sql.Time |
value instanceof java.sql.Timestamp) {
value = new java.util.Date( ( (java.util.Date)value
).getTime() );
}
}
fDate.setValue(value );
is not required any more as was the case before ULC 6.1.
Kind Regards
Christoph
>>> "Albert Smulders" <[EMAIL PROTECTED]> 19.06.2006 16:53 >>>
Hi Christoph,
Thank u very much, the following code resolved the problem:
Date now = new java.util.Date(DataSistema.getDate().getTime());
fDate.setValue(now);
But I really start feeling uncomfortable about Canoo... a bit like VB 3 where u
had to spend many months finding out workarounds for rather a lot of dirty bugs
in the product (typically MS, their whole product line is buggy, but we have
nothing better for the moment as they have the whole public sector in their
hands so we have no choice but program on their buggy platform if we want to
earn a living), my productivity is very very much down..., not only learning
how to use the product but also working my way through the known-bugs-list and
finding out how to resolve many other problems... Like the datetype bug on
textfields in VE, I asked for an interim version of VE but more than a week
later nothing in sight, I think it must be small effort from Canoo to bring out
a patch version without this kind of bugs that break completely existing
code... hmm same same here in hospital if I tell the doctors wait 6 months
until next release of my software before you can see x-ray images again on your
browser, i think I would be watching the street before ending June :)))
So it's my opinion (I would like to trade for a better one), Canoo should
launch more interim bug-solving versions, the product is expensive enough to
expect something better. I'm not an experienced Java programmer still, but with
over 25 years programming experience (starting with Algol 60 at Eindhoven
Technical University ending 80's), I think I can express this concerns....
Kind regards,
Alberto A.Smulders
HostDat Lda. - Portugal
-------- Original-Nachricht --------
Datum: Mon, 19 Jun 2006 14:28:59 +0200
Von: Christoph Bucher <[EMAIL PROTECTED]>
An: [EMAIL PROTECTED]
Betreff: Re: [ULC-developer] Exception calling static method returning date
> Hi Albert,
>
> I posed the same question a few weeks ago, cf. the attached answers from
> Canoo. In my code I had to do
> the following modification:
>
> if (value != null) {
> if (value instanceof java.sql.Date) value = new
> java.util.Date(
> ( (java.sql.Date)value ) .getTime() );
> else if (value instanceof java.sql.Time) value = new
> java.util.Date(
> ( (java.sql.Time)value ) .getTime() );
> else if (value instanceof java.sql.Timestamp) value = new
> java.util.Date(
> ( (java.sql.Timestamp)value ).getTime() );
> }
> ((ULCTextField)getGuiComponent() ).setValue(value);
>
> Kind regards
> Christoph
>
> >>> "Albert Smulders" <[EMAIL PROTECTED]> 19.06.2006 14:02 >>>
> Hi,
>
> I have the following static method in a class to read out the actual date
> (= database sysdate, not the date configured in the client machine or on
> the server):
>
> package pt.hostdat.hcc.uci.database.sonho;
>
> import static pt.hostdat.hcc.uci.database.sonho.IConstants.JNDI;
> import static pt.hostdat.hcc.uci.database.sonho.IConstants.PROP;
>
> import java.io.Serializable;
> import java.sql.Connection;
> import java.sql.ResultSet;
> import java.sql.SQLException;
> import java.sql.Statement;
> import java.util.Date;
>
> import pt.hostdat.hcc.common.database.DAOException;
> import pt.hostdat.hcc.common.database.DatabaseConnectionProvider;
> import pt.hostdat.hcc.common.util.Util;
>
> /**
> * Utility class to read out SYSDATE.
> *
> * @author Alberto Smulders
> */
> public class DataSistema implements Serializable {
> public static Date getDate() {
> Date sysdate = null;
> Connection conn = null;
>
> try {
> String sql = " select trunc(SYSDATE) TODAY from DUAL";
> DatabaseConnectionProvider connProvider =
> new DatabaseConnectionProvider(JNDI, PROP);
> conn = connProvider.getConnection();
> conn.setAutoCommit(false);
> Statement statement = conn.createStatement();
> ResultSet resultSet = statement.executeQuery(sql);
> if (resultSet.next()) {
> sysdate = resultSet.getDate("TODAY");
> System.out.println(sysdate);
> }
> resultSet.close();
> statement.close();
> conn.close();
> }
> catch (DAOException e) {
> Util.showFatalErrorMsg("Erro fatal: " + e.getMessage());
> }
> catch (SQLException e) {
> Util.showFatalErrorMsg("Erro fatal: " + e.getMessage());
> }
> finally {
> if (conn != null) {
> try {
> conn.close();
> }
> catch (SQLException ex) {
> }
> }
> }
>
> return sysdate;
> }
> }
>
>
>
> I use the class in a form:
>
> public void initialize() {
> // ... other code ...
> fDate.setValue(DataSistema.getDate());
> }
>
>
> And I get the following result:
>
> 2006-06-19
> 1 19.06.2006 12:50:23.843 1.000 SEVERE Thread[ULC Communication
> Controller Thread,6,main] com.ulcjava.base.client.UISession$k_ run
> exception
> occured [com.ulcjava.base.client.ConnectorException: error while
> sending requests
> at
> com.ulcjava.base.development.DevelopmentConnector.sendRequests(DevelopmentConnector.java:33)
> at com.ulcjava.base.client.UISession$k_.run(UISession$k_.java:19)
> at java.lang.Thread.run(Unknown Source)
> Caused by: com.ulcjava.base.shared.internal.IllegalArgumentException: No
> coder registered for class java.sql.Date
> at
> com.ulcjava.base.shared.internal.UlcObjectOutputStream.a(UlcObjectOutputStream.java:131)
> at
> com.ulcjava.base.shared.internal.UlcObjectOutputStream.writeObject(UlcObjectOutputStream.java:104)
> at
> com.ulcjava.base.shared.internal.UlcObjectOutputStream.writeObject(UlcObjectOutputStream.java:39)
> at
> com.ulcjava.base.shared.internal.UlcObjectOutputStream.writeObject(UlcObjectOutputStream.java:39)
> at
> com.ulcjava.base.shared.streamcoder.CollectionCoder.writeObject(CollectionCoder.java:5)
> at
> com.ulcjava.base.shared.internal.UlcObjectOutputStream.writeObject(UlcObjectOutputStream.java:31)
> at
> com.ulcjava.base.shared.streamcoder.MapCoder.writeObject(MapCoder.java:18)
> at
> com.ulcjava.base.shared.internal.UlcObjectOutputStream.writeObject(UlcObjectOutputStream.java:31)
> at
> com.ulcjava.base.shared.streamcoder.AnythingCoder.writeObject(AnythingCoder.java:5)
> at
> com.ulcjava.base.shared.internal.UlcObjectOutputStream.writeObject(UlcObjectOutputStream.java:31)
> at
> com.ulcjava.base.shared.streamcoder.MapCoder.writeObject(MapCoder.java:18)
> at
> com.ulcjava.base.shared.internal.UlcObjectOutputStream.writeObject(UlcObjectOutputStream.java:31)
> at
> com.ulcjava.base.shared.internal.Request.writeRequests(Request.java:2)
> at
> com.ulcjava.base.development.DevelopmentConnector.a(DevelopmentConnector.java:36)
> at
> com.ulcjava.base.development.DevelopmentConnector.sendRequests(DevelopmentConnector.java:32)
> at com.ulcjava.base.client.UISession$k_.run(UISession$k_.java:19)
> at java.lang.Thread.run(Unknown Source)
> ]
>
>
> As you can see, the sysdate value is correctly retrieved from the (Oracle)
> database...
>
> Some hints what might be wrong?
>
> Kind regards,
>
> Alberto A.Smulders
> HostDat Lda. - Portugal
> --
>
>
> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
> _______________________________________________
> ULC-developer mailing list
> [email protected]
> http://lists.canoo.com/mailman/listinfo/ulc-developer
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
_______________________________________________
ULC-developer mailing list
[email protected]
http://lists.canoo.com/mailman/listinfo/ulc-developer--- Begin Message ---
Hi Christoph,
In pre-6.1 versions of ULC, java.sql.Date was accepted as possible
value for ULCDateDataType , but the receiver side changed anyway from
java.sql.Date to java.util.Date.
With the introduction of the coders, a more performant ULC
marshalling mechanism, java.sql.Date and java.util.Date cannot be
mixed anymore. Only java.util.Date is supported as default. So, what
you need is to transform yourself java.sql.Date into java.util.Date.
If, instead, you really need all java.sql.Date information on client
and server , you can specify a coder for it (chapter 4.4. of ULC
Extension Guide). As I said, because in the previous version
java.sql.Date was received as java.util.Date, and so you did not use
further information, you probably just need to treat it as
java.util.Date.
Best regards
Sandro
On Jun 1, 2006, at 9:29 AM, Christoph Bucher wrote:
Hi,
after migrating from ulc 6.0.4 to 6.1 my application crashes when
trying to display
an ULCDateDataType. Before I analyze the problem further Canoo
might give me
a hint based upon the following stack trace:
13 01.06.2006 09:15:53.369 1'000 SEVERE Thread[ULC Communication
Controller Thread,6,main] com.ulcjava.base.client.UISession$k_ run
exception occured [com.ulcjava.base.client.ConnectorException:
error while sending requests
at com.ulcjava.base.development.DevelopmentConnector.sendRequests
(DevelopmentConnector.java:5)
at com.ulcjava.base.client.UISession$k_.run(UISession$k_.java:79)
at java.lang.Thread.run(Thread.java:595)
Caused by:
com.ulcjava.base.shared.internal.IllegalArgumentException: No coder
registered for class java.sql.Date
at com.ulcjava.base.shared.internal.UlcObjectOutputStream.a
(UlcObjectOutputStream.java:102)
at
com.ulcjava.base.shared.internal.UlcObjectOutputStream.writeObject
(UlcObjectOutputStream.java:19)
at
com.ulcjava.base.shared.internal.UlcObjectOutputStream.writeObject
(UlcObjectOutputStream.java:72)
at com.ulcjava.base.shared.internal.Request.writeRequests
(Request.java:0)
at com.ulcjava.base.development.DevelopmentConnector.a
(DevelopmentConnector.java:9)
at com.ulcjava.base.development.DevelopmentConnector.sendRequests
(DevelopmentConnector.java:16)
at com.ulcjava.base.client.UISession$k_.run(UISession$k_.java:79)
at java.lang.Thread.run(Thread.java:595)
]
14 01.06.2006 09:15:53.384 800 INFO Thread[AWT-
EventQueue-1,6,main] com.ulcjava.base.client.UISession d ENTRY
[com.ulcjava.base.client.ConnectorException: error while sending
requests
at com.ulcjava.base.development.DevelopmentConnector.sendRequests
(DevelopmentConnector.java:5)
at com.ulcjava.base.client.UISession$k_.run(UISession$k_.java:79)
at java.lang.Thread.run(Thread.java:595)
Caused by:
com.ulcjava.base.shared.internal.IllegalArgumentException: No coder
registered for class java.sql.Date
at com.ulcjava.base.shared.internal.UlcObjectOutputStream.a
(UlcObjectOutputStream.java:102)
at
com.ulcjava.base.shared.internal.UlcObjectOutputStream.writeObject
(UlcObjectOutputStream.java:19)
at
com.ulcjava.base.shared.internal.UlcObjectOutputStream.writeObject
(UlcObjectOutputStream.java:72)
at com.ulcjava.base.shared.internal.Request.writeRequests
(Request.java:0)
at com.ulcjava.base.development.DevelopmentConnector.a
(DevelopmentConnector.java:9)
at com.ulcjava.base.development.DevelopmentConnector.sendRequests
(DevelopmentConnector.java:16)
at com.ulcjava.base.client.UISession$k_.run(UISession$k_.java:79)
at java.lang.Thread.run(Thread.java:595)
Thanks a lot
-- Christoph
_______________________________________________
ULC-developer mailing list
[email protected]
http://lists.canoo.com/mailman/listinfo/ulc-developer
_______________________________________________
ULC-developer mailing list
[email protected]
http://lists.canoo.com/mailman/listinfo/ulc-developer
--- End Message ---
--- Begin Message ---
Hi Robert,
I have created a feature request: https://www.canoo.com/jira/browse/UBA-6938
For now, CoderRegistry being final, you will have to make do with a wrapper
class like the one you have created.
Thanks and regards,
Janak
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of ulc rbeeger
Sent: Wednesday, June 07, 2006 2:39 PM
To: [EMAIL PROTECTED]
Subject: [ULC-developer] CoderRegistry is too restrictive
Hi!
We have developed an extension that starts ULC's ErrorDialog to show a
message and the stacktrace of a Throwable.
For ULC 6.0.x we serialized the Throwable into an Anything on the server
(actually only the message and stacktrace) and wrapped that inside a
subclass of Throwable that could return the message and print the stacktrace
from the contents of that Anything on the client.
Now with 6.1 we have a coder on the server that writes the message and
stacktrace into two Strings and a coder on the client that creates the
client-side wrapper from those strings.
The problem is that registering the server side coder like so
registry.registerCoder(NullPointerException.class, new
ThrowableCoder());
doesn't help since the registry returns only coders for matching classes. So
if a coder for NullPointerException is searched none is found, since coders
for superclasses are not taken into account.
Registering the coder for any possible Exception class is not possible since
we really don't know each kind of Exception that may arise.
We are now forced to create an ExceptionWrapper and register the coder for
that wrapper. We'll need to wrap the Exceptions into that wrapper to make
sure a coder can be found.
I understand the reason for not taking superclasses into account when
searching for coders. It makes the whole system safer. Coders won't be
chosen by accident. Nevertheless I think it should be possible to register
coders explicitely for a class and any subclasses that don't have coders
registered for them. It could be another differently named method like
registerCoderForClassAndSupclasses(Class, Coder).
Unfortunately CoderRegistry is final and even if it were not, there doesn't
seem to be any way to replace it with a custom implementation.
Cheers,
Robert
_______________________________________________
ULC-developer mailing list
[email protected]
http://lists.canoo.com/mailman/listinfo/ulc-developer
--- End Message ---
