Forte IIOP / Corba / Java more questions...

Hi,
I wonder if any Forte / IIOP / Java people can help...
We are a Forte site developing an application using the Forte Web SDK (
window converter / Javascript etc ) and using the Forte external connection
class to enable direct communication between Fort Service objects and Java
applets. We are considering using Corba / IIOP for Java <-> Forte comms but
I could use some advice.
Has anyone compared data transfer rates for Forte client <-> Forte remote
service object vs Java IIOP client to Forte IIOP Service object ( all
across the same LAN ) ? There are of course many factors that might
influence data transfer speeds - but any info would be appreciated. I
really just want to know IIOP communication rates differ from those handled
end-to-end by Forte.
Secondly, does anyone know about scalability of the Forte IIOP Gateway or
Forte IIOP listeners - how many simultaneous IIOP connections can be
supported ?
Thirdly, does anyone know if there are memory limitations for applets
running in browsers - can an applet request additional memory - or is it
simply part of the browsers overall allocation ( important for the Mac
platform ? )
Finally, has anyone used OrbixWeb as the IIOP Java client - experiences,
warnings etc. appreciated.
Cheers - Dave.
Dave Maclaurin, ITS, University of Otago, Dunedin, New Zealand
mailto:[email protected]
Ph (03) 4798530

Similar Messages

Forte IIOP / Corba / Java other questions...

I've a problem with Forte (3.0.E.0) generating IDL that is causing
Visigenic Visibroker 2.5 (for Java) compile errors...
It has something to do with the order(ing) of interfaces declaration
and referencing these interfaces within the generated IDL file ...
To fix thix, I've to hand edit the IDL file and declare the interfaces
before they are referenced in some other Interface declaration...Since
we have a lot of classes, it can take time to do this...
Is this a known bug ? undocumented behavior ? is there any way to
workaround this ? I would assume that Interface declaration/referencing
should be done in proper order (When forte generates IDL), but it is
not.
Thanks for any help,
--francois
Francois Orsini
Evolve Inc - 615 Battery Street - San Francisco, CA 94111
(415) 439-4076 - Email: [email protected]

I've a problem with Forte (3.0.E.0) generating IDL that is causing
Visigenic Visibroker 2.5 (for Java) compile errors...
It has something to do with the order(ing) of interfaces declaration
and referencing these interfaces within the generated IDL file ...
To fix thix, I've to hand edit the IDL file and declare the interfaces
before they are referenced in some other Interface declaration...Since
we have a lot of classes, it can take time to do this...
Is this a known bug ? undocumented behavior ? is there any way to
workaround this ? I would assume that Interface declaration/referencing
should be done in proper order (When forte generates IDL), but it is
not.
Thanks for any help,
--francois
Francois Orsini
Evolve Inc - 615 Battery Street - San Francisco, CA 94111
(415) 439-4076 - Email: [email protected]

Forte, iiop, and java 2 woes

We are running Forte 3L2, and Java 2. We'd like to make calls to a forte SO
from a Java client. We can configure the SO for export, and find the ior
file.
However, the java side never seems to work. The idl compiler for JDK 1.2.x
(idltojava, downloaded from SUN) gives lots syntax errrors, these appear
without explanation on apparently good lines. The compiler for JDK 1.3.0
(idlj) only complains about some errors coming from a escaped strings, which
I can patch around.
The java files resulting from idlj need some minor patching/renaming to
compile (Had to put some of the primitive class helpers into Framework
project manually). And then, they fail at runtime. They fail with a null
object error when run in the 1.3.0 runtime. They fail with the same CORBA
exception when run in either the JDK 1.2.2 runtime, or the naturalbridge
native java compiled runtime.
Does anybody have a specific combination of Java 2 jvm and idl compiler
which will work with Forte? Were any specific tricks needed to make it
work? I tried the technotes, but those that I found seemed out of date for
Java 2.

If you look at the exception information in the iiop manual it
discusses exteneded propties DefaultThrowsClause, ThrowsClause and
IsThrowable.
If you mark your exception class with IsThrowable it will show up in the
IDL as an exception. If you use either DefaultThrowsClause(project) or
ThrowsClause(method) you will get the appropriate raises in the idl.
This will cause the idl2java to produce code which will allow you to catch
the exception.
Tom.
At 09:41 AM 1/29/99 +0100, Giuseppe Sorce wrote:
>
Hi all,
I am currently working to an architecture to establish a communication
between a Forte' server and a Java client, using Visigenic's Visibroker and
IDL mode.
I have problems when I try to raise a Forte' exception from a method
invoked by the Java client; I would like the exception class
(ProductException) not to inherit from the class GenericException, because
the IDL I want to generate must have this structure:
exception ProductException {
string message;
Using this solution, the client application gets blocked waiting forever.
I am currently working with:
- Forte' 3.0.G.2 plus WebEnterprise 1.0.B
- JDK 1.1.5
- Visibroker 3.1
My question is: is it possible to raise an exception from the Forte' side
that is
compliant to the IDL mentioned above?
Of course it should be caught from the Java side.
Thank you in advance
Giuseppe Sorce
CSI Piemonte - C.so Unione Sovietica 216 - 10134 Torino - ITALY
tel. +39-011-3168736
fax +39-011-3168212
e-mail [email protected]
url http://www.csi.it
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Re: (forte-users) Forte and CORBA question

Hi,
The discarding the Java variable that references a distributed Forte object
doesn't cause that the distributed object will be reclaimed. In Forte client
you can use ReleaseDistReference() of the current partition (task.part) to
free the remote object. For Java client, you can implement the following
solution:
- define a method ReleaseMyObject() in the SO you are using to get the proxy
to the dist. object. As parameter for it use something that can identify
your object (attribute).
- your SO has an array or hashtable with your distributed objects, every new
object is added to it.
- in the implementation of ReleaseMyObject() find the object to release in
the array and call ReleaseDistReference() for it,
- from the Java client, call the ReleaseMyObject() for the object that is
not more needed.
Regards,
Zenon Adamek
----- Original Message -----
From: Joseph Mirwald <jomirweb.de>
To: Dave Ortman <dortmanyahoo.com>; 'Forte User Forum'
<forte-userslists.xpedior.com>
Sent: Wednesday, March 07, 2001 3:58 PM
Subject: Re: (forte-users) Forte and CORBA question
Hello Dave,
do you use a copy return or copy parameters in this method ?
If not, then maybe Forte is unable to garbage-collect this object because
it is forever
a proxy which only the server-partition may be able to drop it from memory
(object=NIL).
Try this and let us know what happens.
Hope this helps
Joseph Mirwald
At 11:49 07.03.01 -0800, Dave Ortman wrote:
We're attempting to use a Java client to access a
Forte server. In doing such, we've experienced a
problem which I hoped somebody could shed some light
on.
We've had a Java client calling Forte service objects
and passing Forte objects back and forth as CORBA
structs with no problem. However, we have experienced
some problem obtaining and using remote references to
distributed objects from the Java client.
The problem is memory utilization. Each time I obtain
a reference to a new object, the memory utilization on
the Forte server jumps up quite a bit (around 100k per
object on an NT box). Eventually, if I fetch enough
objects, the server will crash due to lack of memory.
It seems that Forte never reclaims the memory, even
though I'm not using (and don't have a handle to) this
remote objects.
The objects are very small. In fact, I created a test
Forte SO with one method, getObject(); which returns a
distributed object with a single attribute. I then
have a Java client access the getObject() method
repeatedly - discarding the reference to the object
after each iteration. After a short while, the box
will come down.
Any thoughts?
Thanks in advance,
-Dave Ortman
--- "Epari, Madhusudhan" <meparioxhp.com> wrote:
Hi All,
Following error occurs consistently on a router
partition for every call to
the service object but the partition doesn't die or
crash. I tried bumping
up the partition memory too. Any thoughts on why
it's happening?
Thanks in advance,
Madhu
SYSTEM ERROR: Failed to connect or lost connection
to the
environment manager
at FORTE_NS_ADDRESS = <Unknown>. Check that the
environment
manager is
installed at that location. If it is, then check
to be sure that
there are
enough system resources available to support this
partition.
Class: qqsp_SystemResourceException
Error #: [601, 201]
Detected at: qqdo_NsClient::FindObject at 1
Error Time: Wed Feb 21 09:30:56
Exception occurred (locally) on partition
"CSA_cl0_Part2-router",
(partitionId =
C61609A0-8270-11D3-88A9-F4D005D0AA77:0x10c5c:0x1,
taskId =
[C61609A0-8270-11D3-88A9-F4D005D0AA77:0x10c5c.8]) in
application
"MWRouting_cl1", pid 18937 on node forted1 in
environment
frtedev.
SYSTEM ERROR: Attempt to send from a partition
(C61609A0-8270-11D3-88A9-F4D005D0AA77:0x10c5c:0x1)
that no
longer exists.
Class: qqsp_DistAccessException
Error #: [601, 111]
Detected at: qqdo_PartitionMgr::SendMsg at
1
Error Time: Wed Feb 21 09:30:56
Distributed method called:
qqdo_NsServerProxy.FindObject
(object name
Unnamed) from partition
"CSA_cl0_Part2-router",
(partitionId =
C61609A0-8270-11D3-88A9-F4D005D0AA77:0x10c5c:0x1,
taskId =
[C61609A0-8270-11D3-88A9-F4D005D0AA77:0x10c5c.8]) in
application
"MWRouting_cl1", pid 18937 on node
forted1 in environment
frtedev
Exception occurred (locally) on partition
"CSA_cl0_Part2-router",
(partitionId =
C61609A0-8270-11D3-88A9-F4D005D0AA77:0x10c5c:0x1,
taskId =
[C61609A0-8270-11D3-88A9-F4D005D0AA77:0x10c5c.8])
in
application "MWRouting_cl1", pid 18937 on
node forted1 in
environment
frtedev.
LbRouter::FindMembers - CAUGHT EXCEPTION attaching
members from
For the archives, go to:
http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To
unsubscribe, send in a new
email the word: 'Unsubscribe' to:
forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com--
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

Why not this:
while myText.moveToString(' ') do
myText.ReplaceRange('-', myText.Offset, myText.Offset+1);
end while;
or if you prefer verbosity:
while myText.moveToString(source=' ') do
myText.ReplaceRange(source='-', startOffset=myText.Offset,
endOffset=myText.Offset+1);
end while;
-----Original Message-----
From: FatchJeBAM.com [mailto:FatchJeBAM.com]
Sent: Wednesday, January 12, 2000 2:51 PM
To: Troy.Burnsvacationclub.com; kamranaminyahoo.com
Subject: RE: (forte-users) search and replace within a TextData
How about this?? May have to play with start/end on ReplaceRange as I
didn't really test this
Anybody got a better way??
-- replace space with underscore
For x in 1 to myTextdata.LengthToEnd() do
If myTextData.IsSpace() then
MyTextdata.ReplaceRange('_'. Startoffset=myTextdata.offset,
endoffset=myTextdata.offset+1);
End if;
MyTextdata.MoveNext;
End for;
Jerry Fatcheric
-----Original Message-----
From: Burns, Troy [mailto:Troy.Burnsvacationclub.com]
Sent: Wednesday, January 12, 2000 9:40 AM
To: kamranaminyahoo.com
Subject: (forte-users) search and replace within a
TextData
Hello all,
I need to search within a textdata object, replacing all
occurrances of a
space
with another character. Can you give a quick code example
of how I would do
this?
Thanks in advance,
Troy
Troy Burns
Marriott Vacation Club Intl.
E-mail: troy.burnsvacationclub.com
Phone: (941) 688-7700 ext. 4408
For the archives, go to: http://lists.sageit.com/forte-users
and use
the login: forte and the password: archive. To unsubscribe,
send in a new
email the word: 'Unsubscribe' to:
forte-users-requestlists.sageit.com
For the archives, go to: http://lists.sageit.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.sageit.com

RE: Java-based Client for Forte/IIOP

We have deployed an application using JDK 1.1.6,
Swing 1.0.3, Visibroker 3.2, and Forte 3.0.G.2.
We are also using Forte's Java Interoperability
Service.
We have a closely-held client base (i.e. not a
million random yahoos off the internet), so we can
secure a Java port between client and server and
download a fairly significant client. The Java
client is deployed with Sun's JRE (to control the
environment) with the following configuration:
2.6 MB JRE
765 KB Forte.zip
2.0 MB swingall.jar
1.6 MB vbjtools.jar, vbjorb.jar
100 KB application classes
1) The Swing controls don't interoperate well
with the AWT and Symantec widgets, especially in
an internal frame. They paint slowly on top of
each other, move jerkily, and paint before moving
to the programmed coordinates so it looks silly.
100% Swing controls play well with other Swing
controls and are reasonably fast.
2) We used Symantec Cafe 2.5a to paint the
screens, and had some problems with the
setLayout(null) on things like the Swing tab
folder and split panel. Commenting out the line
fixed it, but I'm hoping Cafe 3.0 will fix it (I
have a person installing it but haven't gotten a
report...)
3) The initial search time to turn an IOR file
into a reference is an annoying 10 seconds, and
the first method call takes about 7 seconds, but
after that is less than a tenth of a second.
Haven't done any digging to find out why yet.
4) If we were deploying this as an applet, we
would probably use the IDL IIOP export--when using
the Java Interoperability service, any method call
seems to load the whole 765K across the
line...class by class. Ugly. IDL just gets what
it needs and is smaller.
5) Also, if deploying as an applet, we wouldn't
have to download the JRE or visibroker jar files,
and would only download the swing and Forte IDL
generated classes as needed, so it would be a much
smaller footprint than the 7MB above. (Note:
However, we would be at the mercy of the browser
being used by client.) Different strokes for
different folks...
-DFR
From: [email protected]
Date: Tue, 01 Dec 1998 15:15:18 -0800
Subject: RE: Java-based Client for Forte/IIOP
Sean,
My worry is that Swing, while eloquently designed,
represents an attempt to
write a totally new display system which, at least
in the case of my
project, will run on top of Windows. I really like
the Java (or a Java-like
i.e. J++) language, but I feel safer using the
native MS widgets. It does
not seem that anyone on this forum has used Swing
extensively and can
testify to its stability and performance.
Regards,
David
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

We have deployed an application using JDK 1.1.6,
Swing 1.0.3, Visibroker 3.2, and Forte 3.0.G.2.
We are also using Forte's Java Interoperability
Service.
We have a closely-held client base (i.e. not a
million random yahoos off the internet), so we can
secure a Java port between client and server and
download a fairly significant client. The Java
client is deployed with Sun's JRE (to control the
environment) with the following configuration:
2.6 MB JRE
765 KB Forte.zip
2.0 MB swingall.jar
1.6 MB vbjtools.jar, vbjorb.jar
100 KB application classes
1) The Swing controls don't interoperate well
with the AWT and Symantec widgets, especially in
an internal frame. They paint slowly on top of
each other, move jerkily, and paint before moving
to the programmed coordinates so it looks silly.
100% Swing controls play well with other Swing
controls and are reasonably fast.
2) We used Symantec Cafe 2.5a to paint the
screens, and had some problems with the
setLayout(null) on things like the Swing tab
folder and split panel. Commenting out the line
fixed it, but I'm hoping Cafe 3.0 will fix it (I
have a person installing it but haven't gotten a
report...)
3) The initial search time to turn an IOR file
into a reference is an annoying 10 seconds, and
the first method call takes about 7 seconds, but
after that is less than a tenth of a second.
Haven't done any digging to find out why yet.
4) If we were deploying this as an applet, we
would probably use the IDL IIOP export--when using
the Java Interoperability service, any method call
seems to load the whole 765K across the
line...class by class. Ugly. IDL just gets what
it needs and is smaller.
5) Also, if deploying as an applet, we wouldn't
have to download the JRE or visibroker jar files,
and would only download the swing and Forte IDL
generated classes as needed, so it would be a much
smaller footprint than the 7MB above. (Note:
However, we would be at the mercy of the browser
being used by client.) Different strokes for
different folks...
-DFR
From: [email protected]
Date: Tue, 01 Dec 1998 15:15:18 -0800
Subject: RE: Java-based Client for Forte/IIOP
Sean,
My worry is that Swing, while eloquently designed,
represents an attempt to
write a totally new display system which, at least
in the case of my
project, will run on top of Windows. I really like
the Java (or a Java-like
i.e. J++) language, but I feel safer using the
native MS widgets. It does
not seem that anyone on this forum has used Swing
extensively and can
testify to its stability and performance.
Regards,
David
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Can Forte' IIOP Client catch Java exceptions?

Hi all,
we are using Forte' IIOP features in IDL Mode, to integrate a Forte' client
and a Java server.
Our configuration is:
- java jdk 1.1.5
- Visigenic VIsibroker 3.1 for Java ORB
- Forte' 3.0.G
Is it possible for the Forte' client to catch a Java exception?
We tried to define an IDL file based on our Java server:
module querye
interface QueryClass
exception MiaSQLException{};
string EseguiQuery(in string query_string) raises
(MiaSQLException);
Using forte' corbagen utility we generated the forte' .pex file:
begin TOOL querye;
forward QueryClass;
class QueryClass inherits from Framework.Object
class MiaSQLException inherits from FrameWork.GenericException
end class;
has public method EseguiQuery(
input query_string : string
) : string;
has property
distributed=(allow=on, override=on, default=on);
end class;
method QueryClass.EseguiQuery(
input query_string : string
) : string
begin
end method;
end querye;
We we tried to import the .pex file in the forte' repository, forte' raise
a Syntax Error.
Any idea?
TIA
Giuseppe Sorce
CSI Piemonte - C.so Unione Sovietica 216 - 10134 Torino - ITALY
tel. +39-011-3168736
fax +39-011-3168212
e-mail [email protected]
url http://www.csi.it
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

I am trying to get Forte to communicate with Orbix (not the web
version) via IIOP. Right now I am trying to set up an Orbix C++
server with Forte being the client. Eventually I will need to
communicate the other way (Forte being the server -- I need to do
both). Right now I cannot get Forte to connect to the server. Any
suggestions would be appreciated.
Thanks in advance,
Dale Boan
Details
I am running Forte on an NT machine and the Orbix server under HP-UX.
Under NT, I am using Forte 3.0.F.2 with IIOP enabled (I think - it
shows up in the partition GUI).Which version of Orbix are you using? I believe 2.3c is required. At least I
know that Forte has successfully called Orbix services using 2.3c.
- Coty

Java-based Client for Forte/IIOP

My project is evaluating tools to build the next version of order
entry/production management system. The first version is written entirely
in Forte.
We are considering 3 options for the client:
1.Visual J++/ORBIX COMet (WFC widgets)
2. Visual Cafe / ORBIX for Java (Swing Widgets)
3. GOFC (Good old Forte Client)
The back-end will probably remain Forte/Oracle on Solaris.
If anyone has experience with these tools I would like to hear from you.
I've tried J++/WFC last week and it seems to be solid. I am curious if
Swing is ready for prime time.
Regards,
David
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Sean,
My worry is that Swing, while eloquently designed, represents an attempt to
write a totally new display system which, at least in the case of my
project, will run on top of Windows. I really like the Java (or a Java-like
i.e. J++) language, but I feel safer using the native MS widgets. It does
not seem that anyone on this forum has used Swing extensively and can
testify to its stability and performance.
Regards,
David
At 12:40 PM 12/1/98 -0700, you wrote:
The last I heard it is Swing and JDK 1.2 in release 4.
Cornice Consulting Inc.
Phone: (303) 688-5016
mailto:[email protected]
-----Original Message-----
From: [email protected]
[<a href="mailto:[email protected]">mailto:[email protected]]On</a> Behalf Of Thomas Mercer-Hursh,
Ph.D.
Sent: Tuesday, December 01, 1998 10:20 AM
To: [email protected]
Subject: Re: Java-based Client for Forte/IIOP
At 08:56 PM 11/30/98 -0800, [email protected] wrote:
I am curious if
Swing is ready for prime time.Isn't Swing what Forte is using in R4?
=========================================================================
Thomas Mercer-Hursh, Ph.D email: [email protected]
Computing Integrity, Inc. sales: 510-233-9329
550 Casey Drive - Cypress Point support: 510-233-9327
Point Richmond, CA 94801-3751 fax: 510-233-6950
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href=
"http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>
>>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href=
"http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>
>
>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:<a href=
"http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>

RE: (forte-users) RE: Forte 3 vs Java --Productivity

I think you should compare language to language, product to product
and standard to standard. J2EE is a standard, like CORBA. It's not
a product and it's not a language. J2EE is a standard, based on the
language Java, but the same standard can be used in the context
of Smalltalk, Cobol, Basic or TOOL as well. We have yet to see any
development tool that actually supports full J2EE. And how many
ORB's out there are really 100% CORBA 2.0 complient and offer
full interoperability through IIOP with other CORBA 2.0 complient
products?
The title of this entire thread is wrong. It's not Forte vs. Java, but
TOOL vs. Java or Forte vs. any Java-based ADE.
EJB, J2EE and CORBA are open standards, intended to facilitate
building large, component based applications. But they're only
standards, they're not usable products. Forte is a usable product.
It is a (propriaty) ORB, if offers lots of advanced component based
features and it uses a propriaty OO language called TOOL. Forte
was doing all this way before the world was debating CORBA, then
Java, then EJB and now J2EE.
Sure, when you really look at it, these standards are more complete
and include more design patterns than the way Forte solved the
problem, but the situation is still that, despite all those wonderfull
standards, Forte is still the product with the most advanced capa-
bilities that actually delivers.
The challenge to Forte is to incorporate those standards within their
own product. Are they going to build 2 products, one TOOL-based
and one Java-based, or are they going to integrate TOOL and Java,
or are they going to drop TOOL? Are they going to support J2EE
and will they keep offering those wonderfull distributed features that
are currently in Forte and are not part of J2EE? Will they switch
completely to JDBC or will they integrate DBSessions with JDBC?
Will their ORB functionality remain closed or will the Forte environ-
ment become a full CORBA 2.0 complient environment? Will they
keep supporting DCOM? Will they allow JavaBeans, EJB, Forte
service objects, OLE-objects, Servlets and Active-X components
to co-exist or will that remain SF? Are they going to support Swing?
Are they going to include an HTML-Browser widget? Are they going
to, natively, support JavaScript? What about VB-script? What
about Perl-script? What about TOOL-script??? Will they include
an object-based reporting tool, so you don't have to circumvent
the application and report against the relational database? Will
this reporting tool be Java-based, TOOL-based, both, EJB-based,
CORBA-based or whatever? Will they support JPEG and PNG as
well as BMP and GIF? Will they allow you to store these images in
the repository? Will they include a full-featured web-publisher that
supports HTML and XML as well as seemlessly integrate with Forte
applications? Will they allow you to deploy your (static) web-pages
on a web-server using E-console?
-----Original Message-----
From: Thomas Mercer-Hursh, Ph.D. [SMTP:thomascintegrity.com]
Sent: Monday, February 14, 2000 6:10 PM
To: 'kamranaminyahoo.com'
Subject: (forte-users) RE: Forte 3 vs Java -- Productivity
At 09:04 AM 2/14/2000 , Genesio, Fabrizio wrote:
Our users/customers are waiting for application right now, and
today with Java you may do it, but how expensive and reliable are all
the "+" signs of your equation? I am sure, in the moment somebody (Forté
For Java?) will propose an integrated Java environment capable to
seriously support development/assembly/deployment/maintenance, everybody
will immediately consider it as an alternative to Forté.Not an alternative ... check out FJEE, formerly known as SynerJ. They did
it right with TOOL, now they have done it right with Java. I still prefer
TOOL as the more productive, more elegant language, but if you have to use
Java, Forte has given you the way to do it right.
=========================================================================
Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
Computing Integrity, Inc. sales: 510-233-9329
550 Casey Drive - Cypress Point support: 510-233-9327
Point Richmond, CA 94801-3751 fax: 510-233-6950
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

I think you should compare language to language, product to product
and standard to standard. J2EE is a standard, like CORBA. It's not
a product and it's not a language. J2EE is a standard, based on the
language Java, but the same standard can be used in the context
of Smalltalk, Cobol, Basic or TOOL as well. We have yet to see any
development tool that actually supports full J2EE. And how many
ORB's out there are really 100% CORBA 2.0 complient and offer
full interoperability through IIOP with other CORBA 2.0 complient
products?
The title of this entire thread is wrong. It's not Forte vs. Java, but
TOOL vs. Java or Forte vs. any Java-based ADE.
EJB, J2EE and CORBA are open standards, intended to facilitate
building large, component based applications. But they're only
standards, they're not usable products. Forte is a usable product.
It is a (propriaty) ORB, if offers lots of advanced component based
features and it uses a propriaty OO language called TOOL. Forte
was doing all this way before the world was debating CORBA, then
Java, then EJB and now J2EE.
Sure, when you really look at it, these standards are more complete
and include more design patterns than the way Forte solved the
problem, but the situation is still that, despite all those wonderfull
standards, Forte is still the product with the most advanced capa-
bilities that actually delivers.
The challenge to Forte is to incorporate those standards within their
own product. Are they going to build 2 products, one TOOL-based
and one Java-based, or are they going to integrate TOOL and Java,
or are they going to drop TOOL? Are they going to support J2EE
and will they keep offering those wonderfull distributed features that
are currently in Forte and are not part of J2EE? Will they switch
completely to JDBC or will they integrate DBSessions with JDBC?
Will their ORB functionality remain closed or will the Forte environ-
ment become a full CORBA 2.0 complient environment? Will they
keep supporting DCOM? Will they allow JavaBeans, EJB, Forte
service objects, OLE-objects, Servlets and Active-X components
to co-exist or will that remain SF? Are they going to support Swing?
Are they going to include an HTML-Browser widget? Are they going
to, natively, support JavaScript? What about VB-script? What
about Perl-script? What about TOOL-script??? Will they include
an object-based reporting tool, so you don't have to circumvent
the application and report against the relational database? Will
this reporting tool be Java-based, TOOL-based, both, EJB-based,
CORBA-based or whatever? Will they support JPEG and PNG as
well as BMP and GIF? Will they allow you to store these images in
the repository? Will they include a full-featured web-publisher that
supports HTML and XML as well as seemlessly integrate with Forte
applications? Will they allow you to deploy your (static) web-pages
on a web-server using E-console?
-----Original Message-----
From: Thomas Mercer-Hursh, Ph.D. [SMTP:thomascintegrity.com]
Sent: Monday, February 14, 2000 6:10 PM
To: 'kamranaminyahoo.com'
Subject: (forte-users) RE: Forte 3 vs Java -- Productivity
At 09:04 AM 2/14/2000 , Genesio, Fabrizio wrote:
Our users/customers are waiting for application right now, and
today with Java you may do it, but how expensive and reliable are all
the "+" signs of your equation? I am sure, in the moment somebody (Forté
For Java?) will propose an integrated Java environment capable to
seriously support development/assembly/deployment/maintenance, everybody
will immediately consider it as an alternative to Forté.Not an alternative ... check out FJEE, formerly known as SynerJ. They did
it right with TOOL, now they have done it right with Java. I still prefer
TOOL as the more productive, more elegant language, but if you have to use
Java, Forte has given you the way to do it right.
=========================================================================
Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
Computing Integrity, Inc. sales: 510-233-9329
550 Casey Drive - Cypress Point support: 510-233-9327
Point Richmond, CA 94801-3751 fax: 510-233-6950
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

How to invoke A CORBA-Java Client Application, from Oracle???

Hi,
I have a CORBA-Java Client Application, which takes the input parameters from a Oracle table and calls the CORBA Server, passes these parameters to the C++ Server Application and gets the results back thorugh CORBA.
My problem is, this java application needs to be invoked, when ever there is a new record in the Oracle table.
I am not sure if i can use Java Stored Procedures in Oracle in this case, because my app is in Sun JVM and i am using BEA WebLogic Enterprise 5.1 for the CORBA.
Is there any other way by which i can invoke this app, when a new record is updated in the Oracle table?
Currently, i have just put a TIMER in my java App, to check the oracle table in every few seconds, to see if there is a new reocrd. If it finds a new record it invokes the corresponding class(corba class), or else just keep sending a messsage that no new record is available.
The problems i am facing in this method are as follows;
1. Unnecessarily, the application has to keep on running if there is no request coming frequently.
2. When there is a new record found, the Corba Class is called and the whole process (till it gets the result back from the server) takes about 20 - 30 secs. But within this period, if there is another record coming into Oracle table, my timer class doesnt invoke another corba class....(though i am using multithreading by using the RemidTask method in the timer.schedule.
(timer.schedule(new RemindTask(),10,5*1000);)
3. Also, if during the first call, there is some error, then the whole process exits, instead of another process running parallely (when a second new record is found).
So how does this timer class act like a multithreading process?
Well, i hope i am not confusing....Please let me know if anyone wants bit more elaboration on this.
It would be really helpful if someone can suggest some answer to my problem.
Thanks in advance.

Thank you very much Keith.
Though i am really getting a hope of solving this problem, from you answer, i am actually not 100% sure if i understood your reply properly.
First of all, about
1. "use the update stored procedure to place the updated record (or unique index) onto an Oracle Application Queue."
-- Why do i need to put the record in the AQ. (Frankly speaking, at this moment i dont have much idea about AQ, probably i can learn more about it from oracle technet site? Or would u suggest anything else?)
Then,
2."Your app then waits on this queue and for each new message, consumes it, gets the data required from the AQ load (e.g the index and or record), and fires off the CORBA class"
-- How does my application stay in the queue? and gets the data from the queue?
Of course, as far as i understand, i am going through the same principle...keeping on running a timer class, which keeps on checking the table for a new record, and when it finds, it calls the CORBA class.
Of course, i feel there should be a difference in running the timer continuosly and staying in queue. However i am totally unaware, how can i make my java app to wait in the queue and waits for a new record?
Can you please elaborate your answer a bit more, because i dont know about the AQ, that you have mentioned.
Thank you very much in advance for your time. But please know that it will be of great help to me and hence will be higly appreciated.
Regards,
Subhasree.

RE: (forte-users) RE: Forte 3 vs Java -- Productivity ( wasFutur e of F

Bravo. I completely agree. Right now Forte is helping me solve my business
requirements fast and that's all I care about. If Java will do that for me
tomorrow and I will use it. Otherwise I will keep using whatever
language(s)/tool(s) that helps me get the job done.
Ka
-----Original Message-----
From: Genesio, Fabrizio [mailto:fabrizio.genesiodatasign.ch]
Sent: Monday, February 14, 2000 5:22 AM
To: kamranaminyahoo.com
Subject: RE: (forte-users) RE: Forte 3 vs Java -- Productivity ( was
Futur e of Forte )
What an interesting debate....
May I just add some considerations?
- Successful Project capable to produce effective and maintainable
system. That's in my opinion should be our goal as professional IT
actors. Languages are just means to reach this goal. Therefore I would
like to see IT professional considering all the aspects of software
development, and not only the code and the languages.
- About distributed features in Java systems... Sure, you can do
in Java a lot of nice things, but, today, how much would it cost to
develop in Java real mission-critical distributed application?. I am
talking here about the IT "headaches" Forté has been capable to solve
during the past 5 years. Should I make examples? What about distributed
events, what about distributed transactions, what about fail-over, what
about load-balancing? Or, to move towards a more comprehensive view of
software development (and maintenance), what about partitioning (or, to
talk J2EE slang, assembly), what about deployment, what about monitoring
and run-time management? Is there, available today, an alternative to
Forté that cover so many aspects of enterprise-class systems? I
apologize, but I do not see one, or at least not yet. It not only a
matter of languages...Nevertheless, I believe tomorrow is another day,
Java will evolve as well as the environments for it (including Forté for
Java), and the all will be mature enough to really support distributed
application.
- This leads me to express a wish. I like the way one can turned
down the Singleton issue. However this is a perfect example of the
difference from Forté to Java. On one side you have an abstraction, that
hides complexity. On the other side you are (again) back at the
"plumbing" level. Now I do not know what you think about in my opinion
it is about time we move on from the "prehistorical age", making
abstraction, start to worry more about the business requirements (and
the users' needs). We should stop this sort of religious fight for the
best language (the term "crusade" came to my mind), and using our energy
to push for an easier integration, a effort-less plug-in between
components. There is no perfect solutions, all languages have positive
and negatives points. However all we really need is to learn to use each
technologies at the right time and place, and having all pieces
collaborating between each other. Pretty much like a house, where
several material are used, each of them useful but none of them capable
to replace all the others. Of course, it is clever to use sometimes only
wood, and some other times only concrete. However, most of the time you
need both, and you absolutely want them "collaborating" together to be
able to live in your house. Well, that's what "in primis" we have to ask
for to Forté, and to SUN, in particular: easy integration and
collaboration between TOOL and Java, a seamless cooperation between
partitions and EJBs.
I look forward to discuss all this at FORUM2000....
Fabrizio Genesio
Datasign AG für Informatik
ch. d'Eysins 53a
CH-1260 Nyon
Switzerland
Tel.: +41 22 361 04 04
Fax: +41 22 361 01 10
e-mail: fabrizio.genesiodatasign.ch
<mailto:fabrizio.genesiodatasign.ch>
URL: www.datasign.ch <http://www.datasign.ch>
-----Original Message-----
From: David Vydra [SMTP:dvydrajavamentor.com]
Sent: Thursday, 10 February 2000 04:57
To: Thomas Mercer-Hursh, Ph.D.
Cc: kamranaminyahoo.com
Subject: Re: (forte-users) RE: Forte 3 vs Java --
Productivity ( was Future of Forte )
At 03:06 PM 2/10/00 -0800, you wrote:
>At 06:28 AM 2/10/2000 , David Vydra wrote:
>How familiar are you with this product? Does it tell you
something that
>all of the FJEE tools are written in TOOL?
So what? IBM's VisualAge for Java is written in Smalltalk.
Look, if Forte management thought that they could fight the Java
invasion
they would tell their engineers to make TOOL much, much better.
Instead
they put most of the effort into SynerJ and sold the company to
Sun. Smart
move if you ask me.
>As for what is or is not a 4GL, I think that there are so many
>incomparabily different types of languages available these days
and in so
>many flavors, that any kind of division into generations is, at
the very
>best, extremely subjective. Certainly, TOOL isn't very much
like some of
>the classic procedural 4GLs, but personally I am very
comfortable calling
>it an OO4GL in comparison to the more common OO3GLs around,
like Java.
Agreed.
=========================================================================
>Thomas Mercer-Hursh, Ph.D email:
thomascintegrity.com
>Computing Integrity, Inc. sales:
510-233-9329
>550 Casey Drive - Cypress Point support:
510-233-9327
>Point Richmond, CA 94801-3751 fax:
510-233-6950
>
>--
>For the archives, go to: http://lists.xpedior.com/forte-users
and use
>the login: forte and the password: archive. To unsubscribe,
send in a new
>email the word: 'Unsubscribe' to:
forte-users-requestlists.xpedior.com
>
>
David Vydra
dvydrajavamentor.com
www.javamentor.com
(877) 270 - 9003
For the archives, go to: http://lists.xpedior.com/forte-users
and use
the login: forte and the password: archive. To unsubscribe, send
in a new
email the word: 'Unsubscribe' to:
forte-users-requestlists.xpedior.com
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

At 06:28 AM 2/10/2000 , David Vydra wrote:
Also, it is a little unfair to compare a product in its third production
release with a beta product. I agree that for certain projects Forte 3 is
the right choice today. The issue for me is: will Sun continue the support
of TOOL? How much of a 4GL is TOOL? Will TOOL become more 4GL in the
future or will it be phased out?How familiar are you with this product? Does it tell you something that
all of the FJEE tools are written in TOOL?
As for what is or is not a 4GL, I think that there are so many
incomparabily different types of languages available these days and in so
many flavors, that any kind of division into generations is, at the very
best, extremely subjective. Certainly, TOOL isn't very much like some of
the classic procedural 4GLs, but personally I am very comfortable calling
it an OO4GL in comparison to the more common OO3GLs around, like Java.
=========================================================================
Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
Computing Integrity, Inc. sales: 510-233-9329
550 Casey Drive - Cypress Point support: 510-233-9327
Point Richmond, CA 94801-3751 fax: 510-233-6950

RE: (forte-users) RE: Forte 3 vs Java -- Productivity (wasFutur e of Fo

Excellent point David, and right on the money in my opinion.
-----Original Message-----
From: David Vydra [mailto:dvydrajavamentor.com]
Sent: Thursday, February 10, 2000 10:57 AM
To: Thomas Mercer-Hursh, Ph.D.
Cc: kamranaminyahoo.com
Subject: Re: (forte-users) RE: Forte 3 vs Java -- Productivity ( was
Future of Forte )
At 03:06 PM 2/10/00 -0800, you wrote:
At 06:28 AM 2/10/2000 , David Vydra wrote:
How familiar are you with this product? Does it tell you something that
all of the FJEE tools are written in TOOL?So what? IBM's VisualAge for Java is written in Smalltalk.
Look, if Forte management thought that they could fight the Java invasion
they would tell their engineers to make TOOL much, much better. Instead
they put most of the effort into SynerJ and sold the company to Sun. Smart
move if you ask me.
As for what is or is not a 4GL, I think that there are so many
incomparabily different types of languages available these days and in so
many flavors, that any kind of division into generations is, at the very
best, extremely subjective. Certainly, TOOL isn't very much like some of
the classic procedural 4GLs, but personally I am very comfortable calling
it an OO4GL in comparison to the more common OO3GLs around, like Java.Agreed.
=========================================================================
Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
Computing Integrity, Inc. sales: 510-233-9329
550 Casey Drive - Cypress Point support: 510-233-9327
Point Richmond, CA 94801-3751 fax: 510-233-6950
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com
David Vydra
dvydrajavamentor.com
www.javamentor.com
(877) 270 - 9003
For the archives, go to: http://lists.xpedior.com/forte-users and use
the login: forte and the password: archive. To unsubscribe, send in a new
email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

At 06:28 AM 2/10/2000 , David Vydra wrote:
Also, it is a little unfair to compare a product in its third production
release with a beta product. I agree that for certain projects Forte 3 is
the right choice today. The issue for me is: will Sun continue the support
of TOOL? How much of a 4GL is TOOL? Will TOOL become more 4GL in the
future or will it be phased out?How familiar are you with this product? Does it tell you something that
all of the FJEE tools are written in TOOL?
As for what is or is not a 4GL, I think that there are so many
incomparabily different types of languages available these days and in so
many flavors, that any kind of division into generations is, at the very
best, extremely subjective. Certainly, TOOL isn't very much like some of
the classic procedural 4GLs, but personally I am very comfortable calling
it an OO4GL in comparison to the more common OO3GLs around, like Java.
=========================================================================
Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
Computing Integrity, Inc. sales: 510-233-9329
550 Casey Drive - Cypress Point support: 510-233-9327
Point Richmond, CA 94801-3751 fax: 510-233-6950

Flash/java remoting question

Hi,
i'm new to flash remoting and am finding using it with java
quite troublesome. I've also found using the FileReference class
troublesome if you use java. my question is can you somehow tie the
remoting functionality to the FileReference.upload method
fucntionality??
thanks in advance

I will use the program with photo detector to test
the response time of the LCD screenWhy Java?I second that. With a test like that, you want to reduce the experiment down to a single variable, in this case the lcd response time. Using a java program to feed the monitor input introduces a second variable, the response time of the program. The java program's timer may not be exact, the components may not be repainted completely quickly enough, etc. If this is just for your own amusement, maybe that doesn't matter, but if you want your results to have any reliability, you'll need a more accurate and controllable input source.

Newbie java - rpc question

we have the following situation: old server written in C++ running on a defined set of platforms, using rpc to expose its services. modifications of the server should be avoided. what would be the best way to access rpc from java? as I see it (and considering a defined and small set of platforms) implementing rpc calls in C-functions and calling them from java would be a good solution. are there any better ways?
thanks in advance
milan

thanks.
I have one more question regarding this configuration:
lets say, i have already developed rpc-enabled-classes. now, if i would like to use these classes in a servlet/jsp-based layer running on a different machine (with a possible firewall between them) then I would implement an RMI server executing rpc-classes and access those classes from servlet/jsp over RMI, right?
my first idea was to use EJB with rpc-classes, but EJB do not support native methods.
are there any alternatives to this?

ColdFusion 11: custom serialisers. More questions than answers

G'day:
I am reposting this from my blog ("ColdFusion 11: custom serialisers. More questions than answers") at the suggestion of Adobe support:
@dacCfml @ColdFusion Can you post your queries at http://t.co/8UF4uCajTC for all cfclient and mobile queries.— Anit Kumar Panda (@anitkumar85) April 29, 2014
This particular question is not regarding <cfclient>, hence posting it on the regular forum, not on the mobile-specific one as Anit suggested. I have edited this in places to remove language that will be deemed inappropriate by the censors here. Changes I have made are in [square brackets]. The forums software here has broken some of the styling, but so be it.
G'day:
I've been wanting to write an article about the new custom serialiser one can have in ColdFusion 11, but having looked at it I have more questions than I have answers, so I have put it off. But, equally, I have no place to ask the questions, so I'm stymied. So I figured I'd write an article covering my initial questions. Maybe someone can answer then.
ColdFusion 11 has added the notion of a custom serialiser a website can have (docs: "Support for pluggable serializer and deserializer"). The idea is that whilst Adobe can dictate the serialisation rules for its own data types, it cannot sensibly infer how a CFC instance might get serialised: as each CFC represents a different data "schema", there is no "one size fits all" approach to handling it. So this is where the custom serialiser comes in. Kind of. If it wasn't a bit rubbish. Here's my exploration thusfar.
One can specify a custom serialiser by adding a setting to Application.cfc:
component { this.name = "serialiser01"; this.customSerializer="Serialiser"; }
In this case the value - Serialiser - is the name of a CFC, eg:
// Serialiser.cfccomponent { public function canSerialize(){ logArgs(args=arguments, from=getFunctionCalledName()); return true; } public function canDeserialize(){ logArgs(args=arguments, from=getFunctionCalledName()); return true; } public function serialize(){ logArgs(args=arguments, from=getFunctionCalledName()); return "SERIALISED"; } public function deserialize(){ logArgs(args=arguments, from=getFunctionCalledName()); return "DESERIALISED"; } private function logArgs(required struct args, required string from){ var dumpFile = getDirectoryFromPath(getCurrentTemplatePath()) & "dump_#from#.html"; if (fileExists(dumpFile)){ fileDelete(dumpFile); } writeDump(var=args, label=from, output=dumpFile, format="html"); } }
This CFC needs to implement four methods:
canSerialize() - indicates whether something can be serialised by the serialiser;
canDeserialize() - indicates whether something can be deserialised by the serialiser;
serialize() - the function used to serialise something
deserialize() - the function used to deserialise something
I'm being purposely vague on those functions for a reason. I'll get to that.
The first [issue] in the implementation here is that for the custom serialisation to work, all four of those methods must be implemented in the serisalisation CFC. So common sense would dictate that a way to enforce that would be to require the CFC to implement an interface. That's what interfaces are for. Now I know people will argue the merit of having interfaces in CFML, but I don't really give a [monkey's] about that: CFML has interfaces, and this is what they're for. So when one specifies the serialiser in Application.cfc and it doesn't fulfil the interface requirement, it should error. Right then. When one specifies the inappropriate tool for the job. What instead happens is if the functions are omitted, one will get erratic behaviour in the application, through to outright errors when ColdFusion goes to call the functions and cannot find it. EG: if I have canSerialize() but no serialize() method, CF will error when it comes to serialise something:
JSON serialization failure: Unable to serialize to JSON.
Reason : The method serialize was not found in component C:/wwwroot/scribble/shared/git/blogExamples/coldfusion/CF11/customerserialiser/Serialiser .cfc.
The error occurred inC:/wwwroot/scribble/shared/git/blogExamples/coldfusion/CF11/customerserialiser/testBasic.c fm: line 4
2 : o = new Basic();
3 :
4 : serialised = serializeJson(o);5 : writeDump([serialised]);
6 :
Note that the error comes when I go to serialise something, not when ColdFusion is told about the serialiser in the first place. This is just lazy/thoughtless implementation on the part of Adobe. It invites bugs, and is just sloppy.
The second [issue] follows immediately on from this.
Given my sample serialiser above, I then run this test code to examine some stuff:
o = new Basic(); serialised = serializeJson(o); writeDump([serialised]); deserialised = deserializeJson(serialised); writeDump([deserialised]);
So all I'm doing is using (de)serializeJson() as a baseline to see how the functions work. here's Basic.cfc, btw:
component { }
And the test output:
array
1
SERIALISED
array
1
DESERIALISED
This is as one would expect. OK, so that "works". But now... you'll've noted I am logging the arguments each of the serialisation methods receives, as I got.
Here's the arguments passed to canSerialize():
canSerialize - struct
1
XML
My reaction to that is: "[WTH]?" Why is canSerialize() being passed the string "XML" when I'm trying to serialise an object of type Basic.cfc?
Here's the docs for canSerialize() (from the page I linked to earlier):
CanSerialize - Returns a boolean value and takes the "Accept Type" of the request as the argument. You can return true if you want the customserialzer to serialize the data to the passed argument type.
Again, back to "[WTH]?" What's the "Accept type" of the request? And what the hell has the request got to do with a call to serializeJson()? You might think that "Accept type" references some HTTP header or something, but there is no "Accept type" header in the HTTP spec (that I can find: "Hypertext Transfer Protocol -- HTTP/1.1: 14 Header Field Definitions"). There's an "Accept" header (in this case: "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8"), and other ones like "Accept-Encoding", "Accept-Language"... but none of which contain a value of "XML". Even if there was... how would it be relevant to the question as to whether a Basic.cfc instance can be serialised? Raised as bug: 3750730.
serialize() gets more sensible arguments:
serialize - struct
1
https://www.blogger.com/nullserialize - component scribble.shared.git.blogExamples.coldfusion.CF11.customerserialiser.Basic
2
JSON
So the first is the object to serialise (which surely should be part of the question canSerialize() is supposed to ask, and the format to serialise to. Cool.
canDeserialize() is passed this:
canDeserialize - struct
1
JSON
I guess it's because it's being called from deserializeJson(), so it's legit to expect the input value is indeed JSON. Fair enough. (Note: I'm not actually passing it JSON, but that's beside the point here).
And deserialize() is passed this:
deserialize - struct
1
SERIALISED
2
JSON
3
[empty string]
The first argument is the value to work on, and the second is the type of deserialisation to do. I have no idea what the third argument is for, and it's not mentioned directly or indirectly on that docs page. So dunno what the story is there.
The next issue isn't a code-oriented one, but an implementation one: how the hell are we expected to work with this?
The only way to work here is for each function to have a long array of IF/ELSEIF statements which somehow identify each object type that is serialisable, and then return true from canSerialise(), or in the case of serialize(), go ahead and do the serialisation. So this means this one CFC needs to know about everything which can be serialised in the entire application. Talk about a failure in "separation of concerns".
You know the best way of determining if an object can be seriaslised? Ask it! Don't rely on something else needing to know. This can be achieved very easily in one of two ways:
Check to see if the object implements a "Serializable" interface, which requires a serialize() method to exist.
Or simply take the duck-typing approach: if a CFC implements a serialize() method: it can be serialised. By calling that method. Job done.
Either approach would work fine, keeps things nicely encapsulated, and I see merits in both. And either make far more sense than Adobe's approach. Which is like something from the "OO Failures Special Needs" class.
Deserialisation is trickier. Because it relies on somehow working out how to deserialise() an object. I'm not sure of the best approach here, but - again - how to deserialise something should be as close to the thing needing deserialisation as possible. IE: something in the serialised data itself which can be used to bootstrap the process.
This could simply be a matter of specifying a CFC type at a known place in the serialised data. EG: Adobe stipulates that if the serialised data is JSON, and at the top level of the JSON is a key eg: type, and the value is an extant CFC... use that CFC's deserialize() method. Or it could look for an object which contains a type and a method, or whatever. But Adobe can specify a contract there.
The only place I see a centralised CFC being relevant here is for a mechanism for handling serialised data that is neither a ColdFusion internal type, nor identifiable as above. In this case, perhaps they could provide a mechanism for a serialisation router, which basically has a bunch of routes (if/elseifs if need be) which contains logic as to how to work out how to deserialise the data. But it should not be the actual deserialiser, it should simply have the mechanism to find out how to do it. This is actually pretty much the same in operation as the deserialize() approach in the current implementation, but it doesn't need the canDeserialize() method (it can return false at the end of the routing), and it doesn't need to know about serialising. And also it's not the main mechanism to do the deserialisation, it's just the fall back if the prescribed approach hasn't been used.
TBH, this still sounds a bit jerry-built, and I'm open for better suggestions. This is probably a well-trod subject in other languages, so it might be worth looking at how the likes of Groovy, Ruby or even PHP (eek!) achieve this.
There's still another issue with the current approach. And this demonstrates that the Adobe guys don't actually work with either CFML applications or even modern websites. This approach only works for a single, stand-alone website (like how we might have done in 2001). What if I'm not in the business of building websites, but I build applications such as FW/1 or ColdBox or the like? Or any sort of "helper" application. They cannot use the current Adobe implementation of the customserializer. Why? Because the serialisation code needs to be in a website-specific CFC. There's no way for Luis to implement a custom serialiser in ColdBox (for example), and then have it work for someone using ColdBox. Because it relies on either editing Application.cfc to specify a different CFC, or editing the existing customSerializer CFC. Neither of which are very good solutions. This should have been immediately apparent to the Adobe engineer(s) implementing this stuff had they actually had any experience with modern web applications (which generally aren't just a single monolithic site, but an aggregation of various other sub applications). Equally, I know it's not a case of having thought about this and [I'm just missing something], because when I asked them the other day, at first they didn't even get what I was asking, but when I clarified were just like "oh yeah... um... err... yeah, you can't do that. We'll... have to... ah yeah". This has been raised as bug 3750731.
So I declare the intent here valid, but the implementation to be more alpha- / pre-release- quality, not release-ready.
Still: it could be easily deprecated and rework fairly easily. I've raised this as bug 3750732.
Or am I missing something?
Adam

Yes, you can easily add additional questions to the Lookup.WebClient.Questions Lookup to allow some additional choices. We have added quite a few additional choices, we have noticed that removing them once people have selected them causes some errors.
You can also customize the required number of questions to select when each user sets them up as well as the number required to be correct to reset the password, these options are in the System Configuration settings.
If you need multi-language versions of the questions, you will also need to modify the appropriate language resource file in the xlWebApp.war file to provide the necessary translations for the values entered into the Lookup.

I have some more question

I have some more question.How can I create web.xml and check it.And
how can check the URL patten.thanks

write a simple Test servlet,compile it and place it in your WEB-INF\classes of your application context.configure this servlet class in your web.xml and access it thru your browser to test it all
Regards
padmanava

Forte IIOP / Corba / Java more questions...

Similar Messages

Maybe you are looking for