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/>
Similar Messages
-
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) 4798530Hi,
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 -
Has anyone had any success connecting a client written using Java 2.0 and
the Java 2.0 ORB classes, to a Forte Service Object?
When I try the approach taken in the Forte tutorial (Tech Note 10950), a
security exception is raised. See following:
C:\Projects\SkunkWorks\CE\IDLGen>java CEClient ce.ior
Exception in thread "main" java.lang.SecurityException: ORBSingleton: access
denied
at
com.sun.CORBA.idl.ORBSingleton.string_to_object(ORBSingleton.java:229)
at CEClient.main(CEClient.java:80)
When I try the approach taken in the Java tutorial, the NameService cannot
be resolved. See following:
C:\Projects\SkunkWorks\ForteDemo\IDLGen>java castaxc
ERROR : org.omg.CORBA.COMM_FAILURE: minor code: 1 completed: No
org.omg.CORBA.COMM_FAILURE: minor code: 1 completed: No
at com.sun.CORBA.iiop.ConnectionTable.get(Compiled Code)
at com.sun.CORBA.iiop.GIOPImpl.createRequest(GIOPImpl.java:78)
at com.sun.CORBA.iiop.GIOPImpl.createRequest(GIOPImpl.java:62)
at
com.sun.CORBA.idl.GenericCORBAClientSC.createRequest(GenericCORBAClientSC.ja
va:138)
at
com.sun.CORBA.idl.InitialNamingClient.resolve(InitialNamingClient.java:194)
at
com.sun.CORBA.idl.InitialNamingClient.cachedInitialReferences(InitialNamingC
lient.java:275)
at
com.sun.CORBA.idl.InitialNamingClient.resolve_initial_references(InitialNami
ngClient.java:184)
at com.sun.CORBA.idl.ORB.resolve_initial_references(ORB.java:1098)
at castaxc.main(castaxc.java:24)
Thanks, in advance
Perry Everitt
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>Has anyone had any success connecting a client written using Java 2.0 and
the Java 2.0 ORB classes, to a Forte Service Object?
When I try the approach taken in the Forte tutorial (Tech Note 10950), a
security exception is raised. See following:
C:\Projects\SkunkWorks\CE\IDLGen>java CEClient ce.ior
Exception in thread "main" java.lang.SecurityException: ORBSingleton: access
denied
at
com.sun.CORBA.idl.ORBSingleton.string_to_object(ORBSingleton.java:229)
at CEClient.main(CEClient.java:80)
When I try the approach taken in the Java tutorial, the NameService cannot
be resolved. See following:
C:\Projects\SkunkWorks\ForteDemo\IDLGen>java castaxc
ERROR : org.omg.CORBA.COMM_FAILURE: minor code: 1 completed: No
org.omg.CORBA.COMM_FAILURE: minor code: 1 completed: No
at com.sun.CORBA.iiop.ConnectionTable.get(Compiled Code)
at com.sun.CORBA.iiop.GIOPImpl.createRequest(GIOPImpl.java:78)
at com.sun.CORBA.iiop.GIOPImpl.createRequest(GIOPImpl.java:62)
at
com.sun.CORBA.idl.GenericCORBAClientSC.createRequest(GenericCORBAClientSC.ja
va:138)
at
com.sun.CORBA.idl.InitialNamingClient.resolve(InitialNamingClient.java:194)
at
com.sun.CORBA.idl.InitialNamingClient.cachedInitialReferences(InitialNamingC
lient.java:275)
at
com.sun.CORBA.idl.InitialNamingClient.resolve_initial_references(InitialNami
ngClient.java:184)
at com.sun.CORBA.idl.ORB.resolve_initial_references(ORB.java:1098)
at castaxc.main(castaxc.java:24)
Thanks, in advance
Perry Everitt
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/> -
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] -
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 -
Forte' and Java IOOP in mission criticalapplications.
Hi,
Has anybody had any experience in the development of Java/IIOP/Forte'
applications in large scale, mission critical, environments?
We've developped a full function prototype application and it looks as if
the Forte' IIOP listener could easily become a bottleneck in the overall
architecture configuration: infact we think it is not possible to configure
it for load balancing and/or failover and that any solution in this field
should be carried out outside Forte'.
Any ideas/comments?
Thanks a lot,
Ernesto Moscatelli
SEMAGROUP Italy
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>Hi
I've been playing with a variation of the custom router you describe below to
avoid having my server side partitions being pulled onto my client.
Essentially each of my server side partitions registers themselves with a
router set up to service that particular partition. The "clients" then request
a reference to the server side partition from the custom router. This
reference is then used to invoke the services provided by my server side
partitions.
On the box I am testing (RS 6000) my custom router (performing round robin
routing) is between 90ms and 100ms slower the Forte's own router. However,
since my server side partition can be multi-threaded as soon as there are more
tasks requiring the service than there are partitions I start to see a
performance improvement.
While I was testing this (and a few other things) I noticed that it seemed to
be awfully easy to flood a Forte partition (running Forte threads) with tasks
(around 8 as far as I could tell) to the point where the partition seems to
spend all of its time servicing the threads rather than doing any real work.
Does anyone know at what number of tasks the Forte threading model breaks down?
Or, if there are any ways of controlling the "thread processing time".
Cheers,
Darren
From: Scott Irwin <[email protected]>
To: 'Peter Sham (HTHK - Assistant Manager - Software Development, IITB)'<[email protected]>; [email protected]
Cc: [email protected]
Subject: RE: Forte' and Java IOOP in mission critical applications.
Date: 23 March 1999 13:44
We are implementing a Java Bean which communicates via IIOP to our SO. We
didn't like forte's router so we developed a custom 'Intelligent' router.
The Bean first resolves the CustomerRouterSO. The CustomerRouterSO is set
for only Fail-Over. Our real SO that does all of the work is our
ReplicateSO which is load balanced and registers with the CustomerRouterSO.
The CustomRouterSO does not hold state in case it fails. ReplicateSO know
(based on env) if they are primary or secondary type SO and tell the
CustomRouterSO.
In the CustomRouterSO you can add any type of logic you need to determine
which ReplicateSO you want to assign back from the connect(). In our case,
each ReplicateSO keeps a count of the number of clients assigned, and the
CustomRouterSO asks the ReplicateSO if it can handle another assignment.
We needed this type of behavior because our objects are chockfull of state.
If you need Message type duration then it's another game. We are heading
into Stress Test in a few weeks so we will see if this will fly.
Have Fun!
Scott Irwin
-----Original Message-----
From: Peter Sham (HTHK - Assistant Manager - Software Development,
IITB) [SMTP:[email protected]]
Sent: Tuesday, March 23, 1999 4:38 AM
To: [email protected]
Cc: [email protected]
Subject: RE: Forte' and Java IOOP in mission critical
applications.
Hi,
I'm not expert on this field, but if the configuration is like this,
should
this load-balance/failover responsibility be on the shoulder of the
COBRA
ORB, instead on Forte?
Peter Sham.
-----Original Message-----
From: [email protected]
[SMTP:[email protected]]
Sent: Tuesday, March 23, 1999 4:57 PM
To: [email protected]
Subject: Forte' and Java IOOP in mission critical
applications.
Hi,
Has anybody had any experience in the development of
Java/IIOP/Forte'
applications in large scale, mission critical, environments?
We've developped a full function prototype application and
it looks
as if
the Forte' IIOP listener could easily become a bottleneck in
the
overall
architecture configuration: infact we think it is not
possible to
configure
it for load balancing and/or failover and that any solution
in this
field
should be carried out outside Forte'.
Any ideas/comments?
Thanks a lot,
Ernesto Moscatelli
SEMAGROUP Italy
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/>
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/> -
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.comI 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 -
RE: Forte, Tuxedo and ACMS
Hallo Rick,
I have no confirmation about the actual status at Forté, but we
interfaced Tuxedo using a normal C wrapping.
It works very well, with good performances.
By the way, it exists a shareware about a Tuxedo interface. You can
download it from www.forte.com.
Let me know if you need more information,
Best regards
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
Mobile : +41 79 601 81 31
E-mail : mailto:[email protected]
Web : http://www.datasign.ch
-----Original Message-----
From: Rick Greenwald [SMTP:[email protected]]
Sent: Friday, February 06, 1998 10:20
To: '[email protected]'
Subject: Forte, Tuxedo and ACMS
All -
Does Forte have an interface to Tuxedo and/or ACMS? Have any of you
used it?
I would appreciate any information I could get. Please respond to me
directly, as I am not a regular member of the list.
- Rick GreenwaldIf 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/> -
WebEnterprise - HTML Editors and Java
I'd like to know any opinions on HTML editors and their use with
WebEnterprise. Have any of you done
evaluations to determine the best editor to use with the Forte product? Also,
do you have experience using
a Java applet as the front-end to a Forte service object? In this instance,
are you able to do so with Forte 30f2 and
WebSDK?
Thanks,
Peggy Adrian
Eli Lilly and CompanyPeggy,
FrontPage 97 / 98 have both worked really well for us, however we
discovered a slight hitch with 98 where the Editor would gobble up
<?FORTE ..> tags inside the SELECT OPTION tag, but you can work around
that one, apart from this FP98 is a great HTML editor. I also thought
HotMetal was a good fit.These observations come out of evaluating about
5-6 leading HTML editors.
Some recommended steps in the process:
1) Create a prototype by laying out all the HTML using an Editor. Figure
out all the navigation within your web. More recent features seen in
HTML editors such as JavaScript generation and DHTML / CSS support are
really difficult to work out on your own, let the advanced Editors do as
much dirty work for you as poss.
2) Once the prototype is finalized, for all the pages requiring any
dynamic content generation, figure out all the Tag Handlers you will
need. Change the HTML Content by inserting the FORTE tags as required,
code the corresponding Handlers.
3) Figure out the relation between page requests and the security
requirements for your pages, design the Session properties and data
tracing across requests using the Session object.
4) Do refer to all the Tech Notes on the Forte web site for known
issues.
As for the Java applets frontend, we have used Java - IIOP - Forte since
early beta through every Forte release (3.0.X) and it works fine with
WebEnterprise and release 30f2.
- Sameer
From: Peggy Lynn Adrian <[email protected]>
Date: Wed, 07 Jan 1998 15:19:58 -0500
Subject: WebEnterprise - HTML Editors and Java
I'd like to know any opinions on HTML editors and their use with
WebEnterprise. Have any of you done
evaluations to determine the best editor to use with the Forte
product? Also,
do you have experience using
a Java applet as the front-end to a Forte service object? In this
instance,
are you able to do so with Forte 30f2 and
WebSDK?
Thanks,
Peggy Adrian
Eli Lilly and Company -
Forte compile error java source files must have a .java suffix
Hello Guru's,
I am using Forte for Java release 2.0 build 1160, and Java SDK 1.3.1.
When I try to compile a project in Forte I get the following error :
"fastjavac: java source files must have a .java suffix C:\Program"
I have looked at the source files and they do hav .java suffix!
If this is not the correct form can someone point me in the right direction. If this is a correct forum then help is very much appreciated.
Cheers...HarkiHi,
Try to compile like this:
javac yourfile.java
Hope this helps you.
Cheers.....Dinesh -
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.comAt 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.comAt 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 -
Difference between RMI-IIOP and CORBA-IIOP
Hello,
What is the difference between RMI-IIOP and CORBA-IIOP?
Thanks
LarryLawrence Manickam <[email protected]> writes:
What is the difference between RMI-IIOP and CORBA-IIOP? RMI-IIOP is the protocol represented by the mapping of Java RMI
artifacts to IDL, i.e. you start with Java and use the RMI programming
model. CORBA / IIOP is really just the protocol used for IDL sourced
objects, i.e. you start with IDL and use the CORBA programming model.
andy
Maybe you are looking for
-
How to export the data from table to excel sheet
hi experts i have some problem am trying to export the data fro table to Excel sheet in the view controller i have created one button wit public void onActionCLEAR(com.sap.tc.webdynpro.progmodel.api.IWDCustomEvent wdEvent ) //@@begin onActionCLE
-
I am very dissatisfied with the replacement phone. How do I get help?
We purchased a casio phone, there was issues with it, and I was sent to the warranty center. They were very courteous with sending a replacement phone..but the problem was, they replaced it with a phone that was in no way comparable to the one we bou
-
Premiere cs6 crashing with Quicktime
I've recently started having problems with video disappearing in Premiere. Usually happens when I have other cs6 applications open, like after sending a sequence to Audition, or using AE dynamic link. The program monitor displays a black screen, the
-
I am dealing with BOR object BUS2091 for SES entries workflow When ever i need some info like initialtors mail ,stauts etc i use the expression ZBUS2091.ZWFInitMail which are the attributes of Zbus2091 My doubt is whenever the worflow is triggered ho
-
How soon will DW CS5 Live View Webkit support CSS3?
See above. I just tried CSS3's text-shadow (although I don't believe it's totally CSS3) and while the shadow works well in Chrome, in Opera and in Safari, DW's Live View does not render the shadow, but rather an offset black copy of the text. Webki