Update 1 disappointment!
Vincent Parrett (VSoft)
D6 :
Create a component that uses the D6 soap stuff in any way, or a descendant
of one of hte soap components. Try to install your component in package.
result : required package coreide not found.
This is because (wrongly) the dclsoap package requires coreide. Doh!
Vincent Parrett
VSoft Technologies Pty Ltd
Email : vincent [ at ] vsoft - tech dot com dot au
-------------------------------------------------
Automate your Software Build Process
with FinalBuilder! - http://www.finalbuilder.com
Dave Nottage
> This is because (wrongly) the dclsoap package requires coreide. Doh!
I feel your pain <g>
I have built a SOAP server that loads webservices via packages, but it can
only be deployed on a machine that has Delphi 6 Enterprise installed, due to
requiring coreide (as well as dclsoap) to be present.
--
Dave Nottage
Vincent Parrett (VSoft)
news:3bb27e8a_2@dnews...
Hmm, I can't even create my components dynamically because of another bug in
the soap components resulting in a property never being set correctly. I'm
about ready to give up on D6 SOAP at this stage of the game. Java is
starting to look very attractive.....
Regards
Steve Garland
about ready to give up on D6 SOAP at this stage of the game
have you seen www.rapware.com? It looks *very* nice.
--
Steve Garland sgar...@astatech.com
Cross Platform Messaging and TDataSet Components: TAstaPDADataSets
Servers (Win32,Linux,Java) Clients (Win32,Linux,Java,Palm,WinCE,Linux PDA's)
ASTA Technology Group http://www.astatech.com http://www.astawireless.com
Dave Nottage
> Hmm, I can't even create my components dynamically because of another bug
in
> the soap components resulting in a property never being set correctly.
What are the details?
> Java is starting to look very attractive.....
Using JBuilder or something else? Any particular toolkit?
I ask because I will be using both Delphi 6 and Java for SOAP, soon.
--
Dave Nottage
Vincent Parrett (VSoft)
news:3bb285a0$1_2@dnews...
> <. I'm
> about ready to give up on D6 SOAP at this stage of the game
>
> have you seen www.rapware.com? It looks *very* nice.
Sort of, I have the beta but not the time to check it out properly. Having
said that, it just moved up my todo list about 10 places today!
Jean-Marie Babet
First I should say that I apologize that something like this did not get
fixed. Unfortunately (without going into details and getting myself in
trouble) some resources were diverted while we were working on this patch.
Some of my teammates were on vacation and others were jumpstarting another
related effort.
About this specific issue (requiring COREIDE), it stems from the fact that
we don't have a runtime package for SOAP. The reason we opted not to build a
runtime package was due to the fact that it was obvious that the SOAP
implementation was at it first revision and it would evolve. There's a rule
here that patches cannot change interface signatures of runtime packages
(additions are OK but no changes). If you grep the sources you'll often see
comments like "Define new class to avoid changing method signature".
Until this is resolved, I'll be happy to provide assistance to build a
runtime package. As I've mentioned in another thread, I've received the OK
to make sure that we provide all SOAP runtime sources. Due to the nature of
packages, using the SOAP component from a runtime package will mean removing
the current DCLSOAP60 one (which means the SOAP IDE wizards will not be
unavailable) which working on a project that uses the components. [I can't
commit to this but if we opted for that path, I try to find some time to
create a DCLSOAP60 that did not have the components that moved to the
runtime package].
I also want to assure you that creating a runtime package is the list of
things we want to do. I opted to let it go for patch#1 because I also was
not sure we'd reach a stable interface (specially since we were not done
with doc|lit support). Now, I wished maybe that we had built the runtime
package.
Regards,
Bruneau.
"Dave Nottage" <da...@removethis.b3.com.au> wrote in message
news:3bb27e8a_2@dnews...
Dave Nottage
> Until this is resolved, I'll be happy to provide assistance to build a
> runtime package.
Yes, please: Can you supply a Soap60.dpk, or at least a list of units that
need to be included?
I started making a dpk myself, but had next to no clue as to which units to
include.
Thanks very much for your efforts.
--
Dave Nottage
Vincent Parrett (VSoft)
Firstly, thanks for your attention to this matter!
> I also want to assure you that creating a runtime package is the list of
> things we want to do. I opted to let it go for patch#1 because I also was
> not sure we'd reach a stable interface (specially since we were not done
> with doc|lit support). Now, I wished maybe that we had built the runtime
> package.
My main issue is not so much a problem with runtime packages, but with
design time. I want to install a THTTPReqResp descendant component, but
can't because dclsoap requires coreide. All that I really need is for
dclsoap to be recompiled without requiring coreide. Obviously, losing the
wizards would be a real pain in the ......
I understand that Dave does need the runtime package though. I don't see a
problem with providing one now, even if the interfaces may change, the
delphi sopa users know and do understand that soap is still a bit of a
moving target. I certianly wouldn't be installing any soap runtime packages
in my system32 directory, just in the same directory application.
Regards
Vincent Parrett (VSoft)
Currently I have to make this change myself to get my component to work
properly. Also, when a new HTTPWebNode component is assigned to the THTTPRIO
component at runtime, the HTTPWebNode.WSDLView property is not set, and this
will cause any soap method calls to fail. This may not be a problem once I
can install the component, but at the moment I have to do a real (dangerous)
hack to work around it.
FWIW, here is the source to my component, what it does is make the soap
method calls happen in a thread, so that the user interface doesn't block
waiting for the request to return. I have used a similar technique
(implmenting the interface on a thread object) before with Corba with great
success.
//************************
unit HTTPReqRespThreaded;
//Author : Vincent Parrett - vin...@vsoft-tech.com.au
//Copyright (c) 2001 - VSoft Technologies Pty Ltd.
// Allows soap method calls to execute withing a thread, so the ui still
remains responsive
// the method calls are stil syncronous though.
//TODO - Exception handling
//Aborting soap methodcalls
interface
uses
Windows, Messages, SysUtils, Classes, SoapHTTPTrans,WebNode;
type
THTTPReqRespThreaded = class;
THTTPReqRespThread =class(TThread)
private
FOwner: THTTPReqRespThreaded;
FDataMsg : string;
FResponse : TStream;
FCompleted : boolean;
protected
procedure Execute;override;
public
constructor CreateEx(AOwner : THTTPReqRespThreaded);
destructor Destroy; override;
procedure ExecuteRequest(const DataMsg: WideString; Response: TStream);
property Completed : boolean read FCompleted write FCompleted;
end;
THTTPReqRespThreaded = class(THTTPReqResp, IInterface, IWebNode)
private
{ Private declarations }
FThread : THTTPReqRespThread;
protected
{ Protected declarations }
//procedure IWebNode.Execute = IWebNodeExecute; // doesn't work, Execute
is not called via interface ref??
public
{ Public declarations }
constructor Create(AOwner : TComponent);override;
destructor Destroy;override;
procedure Execute(const DataMsg: WideString; Response:
TStream);override;// I modified THTTPReqResp.Execute to make it virtual
procedure DoExecute(const DataMsg: WideString; Response: TStream);
published
{ Published declarations }
end;
procedure Register;
implementation
uses
forms,SoapHTTPClient;
procedure Register;
begin
RegisterComponents('WebServices', [THTTPReqRespThreaded]);
end;
Type
TCrackHTTPRIO = class(THTTPRIO);
{ THTTPReqRespThread }
constructor THTTPReqRespThread.CreateEx(AOwner: THTTPReqRespThreaded);
begin
inherited Create(True);
FreeOnTerminate := true;
FCompleted := False;
FOwner := AOwner;
end;
destructor THTTPReqRespThread.Destroy;
begin
inherited;
end;
procedure THTTPReqRespThread.Execute;
begin
while Terminated = False do
begin
FOwner.DoExecute(FDataMsg,FResponse);
FCompleted := True;
Suspend;
end;
end;
procedure THTTPReqRespThread.ExecuteRequest(const DataMsg: WideString;
Response: TStream);
begin
FDataMsg := DataMsg;
FResponse := Response;
FCompleted := False;
Resume;
end;
{ THTTPReqRespThreaded }
constructor THTTPReqRespThreaded.Create(AOwner: TComponent);
begin
inherited Create(AOwner);
FThread := THTTPReqRespThread.CreateEx(Self);
// the following is a hack to get around the fact that the WSDLView is not
set when you assign a new HTTPWebNode
// it relies on the component being created dynamically with the HTTPRIO
component as the owner.
if AOwner is THTTPRIO then
Self.WSDLView := THTTPRIO(AOwner).HTTPWebNode.WSDLView;
end;
destructor THTTPReqRespThreaded.Destroy;
begin
FThread.Terminate;
FThread.Resume;
inherited;
end;
procedure THTTPReqRespThreaded.DoExecute(const DataMsg: WideString;
Response: TStream);
begin
inherited Execute(DataMsg,Response);
end;
procedure THTTPReqRespThreaded.Execute(const DataMsg: WideString; Response:
TStream);
begin
FThread.ExecuteRequest(DataMsg,Response);
while FThread.Completed = false do
Application.ProcessMessages;
end;
end.
*************************
Vincent Parrett (VSoft)
> "Vincent Parrett (VSoft)" wrote:
> > Hmm, I can't even create my components dynamically because of another
bug
> in
> > the soap components resulting in a property never being set correctly.
>
> What are the details?
See my other post in reply to Bruneau.
> > Java is starting to look very attractive.....
>
> Using JBuilder or something else? Any particular toolkit?
>
> I ask because I will be using both Delphi 6 and Java for SOAP, soon.
Don't know on both counts at this stage, but most likely JBuilder. I'm still
investigating EJB's etc for moving a ISAPI/COM+/SQLServer app to Java. Lots
of issues to consider....
Jean-Marie Babet
I'll get that started right away. To keep up with the other runtime packages
(adortl, bdertl, dbrtl, xmlrtl, etc), I'll call it soaprtl.dpk (the suffix
will come via the $LIBSUFFIX directive).
As to the file list itself, I suspect the following:
InvokeRegistry in 'InvokeRegistry.pas',
Invoker in 'Invoker.pas',
InvConst in 'InvConst.pas',
InvRules in 'InvRules.pas',
OPConvert in 'OPConvert.pas',
OPToSoapDomConv in 'OPToSoapDomConv.pas',
Rio in 'Rio.pas',
SoapConst in 'SoapConst.pas',
SoapEnv in 'SoapEnv.pas',
SoapHTTPDisp in 'SOAPHTTPDisp.pas',
SoapHTTPTrans in 'SoapHTTPTrans.pas',
SOAPHTTPPasInv in 'SOAPHTTPPasInv.pas',
TypeTrans in 'TypeTrans.pas',
WSDLNode in 'WSDLNode.pas',
EncdDecd in 'EncdDecd.pas',
WebNode in 'WebNode.pas',
WebBrokerSoap in 'WebBrokerSOAP.pas',
SOAPHTTPClient in 'SoapHTTPClient.pas',
OPToSoapDomCustom in 'OPToSoapDomCustom.pas',
HTTPSOAPToPasBind in 'HTTPSOAPToPasBind.pas',
SoapDm in 'SoapDm.pas',
IntfInfo in 'IntfInfo.pas',
SOAPMidas in 'SOAPMidas.pas',
WSDLSoap in 'WSDLSoap.pas',
SoapDomConv in 'SOAPDomConv.pas',
WSDLBind in 'WSDLBind.pas',
WSDLIntf in 'WSDLIntf.pas',
WSDLPub in 'WSDLPub.pas',
WSDLItems in 'WSDLItems.pas',
SOAPPasInv in 'soappasinv.pas',
SOAPLinked in 'soaplinked.pas',
WebServExp in 'WebServExp.pas',
SoapConn in 'SoapConn.pas',
XSBuiltIns in 'XSBuiltIns.pas';
I've left out SoapReg.pas from the above since it contains both design-time
and runtime registration. For the patch we moved registrations from various
sources into SoapReg.pas; however, we did not distinguish between
design-time registration and runtime. I suspect we'll have to split
registrations into two units.
Regards,
Bruneau.
PS: I also need to run a check for any sources listed above that's not
included with the distribution.
"Dave Nottage" <da...@removethis.b3.com.au> wrote in message
news:3bb2a564_2@dnews...
Jean-Marie Babet
Yes, definitely! That's the type of change we want to make before releasing
redistributable(i.e. runtime) packages.
> Also, when a new HTTPWebNode component is assigned to the THTTPRIO
> component at runtime, the HTTPWebNode.WSDLView property is not set, and
this
> will cause any soap method calls to fail
Good find!! And the SOAPAction too! (Which is set when you request the
interface from the RIO and which allows Delphi<->Delphi to work with just
URL endpoint).
[Side-note: we're looking at options that don't require the WSDL/WSDLView at
runtime. Currently we use it to look up the SOAPAction, Namespace and
endpoint; the Namespace is in the registry already (provided you did not use
'AutoGenerate' when importing - that option is going away soon:); the URL
can be specified in lieu of the WSDL; so that leaves the SOAPAction, which
currently we're planning to have the importer register; Please do let me
know if you have any suggestions/comments in that area]
I love your idea of threading the call. If you ever wanted to see
THTTPReqRespThread in the library and did not mind us shipping it, please do
let me know. I promise to make sure that (a) we ship the source and (b) it
acknowledges the author!
Regards,
Bruneau.
"Vincent Parrett (VSoft)" <vin...@nospam.vsoft-tech.com.au> wrote in
message news:3bb2afdc$1_1@dnews...
Vincent Parrett (VSoft)
news:3bb2bacf$1_1@dnews...
> > BTW, is there any chance you could make THTTPReqResp.Execute virtual.
>
> Yes, definitely! That's the type of change we want to make before
releasing
> redistributable(i.e. runtime) packages.
Cool!
> Good find!! And the SOAPAction too! (Which is set when you request the
> interface from the RIO and which allows Delphi<->Delphi to work with just
> URL endpoint).
Ok, I don't know much about those, but it did work with the WSDLView set ok.
> I love your idea of threading the call. If you ever wanted to see
> THTTPReqRespThread in the library and did not mind us shipping it, please
do
> let me know. I promise to make sure that (a) we ship the source and (b) it
> acknowledges the author!
Absolutely! Feel free to use as you see fit! Note that the component is far
from complete, but there is enough there to get started with. The main issue
is exception handling, as the exceptions need to be re-raised in the main
application thread. I have added some quick and dirty exception handling but
it is completely untested :
//***********************************
unit HTTPReqRespThreaded;
//Author : Vincent Parrett - vin...@vsoft-tech.com.au
//Copyright (c) 2001 - VSoft Technologies Pty Ltd.
// Allows soap method calls to execute withing a thread, so the ui still
remains responsive
// the method calls are still syncronous though.
//TODO Better Exception handling
//TODO Aborting soap methodcalls
interface
uses
Windows, Messages, SysUtils, Classes, SoapHTTPTrans,WebNode;
type
THTTPReqRespThreaded = class;
THTTPReqRespThread =class(TThread)
private
FOwner: THTTPReqRespThreaded;
FDataMsg : string;
FResponse : TStream;
FCompleted : boolean;
FException : Exception;
procedure Register;
implementation
uses
forms,SoapHTTPClient;
Type
TCrackHTTPRIO = class(THTTPRIO);
{ THTTPReqRespThread }
destructor THTTPReqRespThread.Destroy;
begin
inherited;
end;
FException := nil;
Try
FOwner.DoExecute(FDataMsg,FResponse);
except
on e: Exception do
begin
//are we losing any specific Exception info here?
// is there a way to keep the specific exceptions
// as we can't do FException := e
// and then raise it, as that does not work because the
// exception does not live outside the handler code section.
FException := Exception.Create(e.Message);
end;
end;
FCompleted := True;
Suspend;
end;
end;
procedure THTTPReqRespThread.ExecuteRequest(const DataMsg: WideString;
Response: TStream);
begin
FDataMsg := DataMsg;
FResponse := Response;
FCompleted := False;
Resume;
end;
{ THTTPReqRespThreaded }
constructor THTTPReqRespThreaded.Create(AOwner: TComponent);
begin
inherited Create(AOwner);
FThread := THTTPReqRespThread.CreateEx(Self);
// pure hack, remove !!!!!!!
if AOwner is THTTPRIO then
Self.WSDLView := THTTPRIO(AOwner).HTTPWebNode.WSDLView;
end;
destructor THTTPReqRespThreaded.Destroy;
begin
FThread.Terminate;
FThread.Resume;
inherited;
end;
procedure THTTPReqRespThreaded.DoExecute(const DataMsg: WideString;
Response: TStream);
begin
inherited Execute(DataMsg,Response);
end;
procedure THTTPReqRespThreaded.Execute(const DataMsg: WideString; Response:
TStream);
begin
FThread.ExecuteRequest(DataMsg,Response);
while FThread.Completed = false do
Application.ProcessMessages;
//if an exception occurred in the thread then raise here
if FThread.FException <> nil then
raise FThread.FException;
end;
end.
//********************
Thanks
Dave Nottage
> As to the file list itself, I suspect the following:
When I build my SOAP Server using the runtime package built with those
units:
"[Fatal Error] SOAPServer.dpr(7): Unit WebReq was compiled with a different
version of HTTPApp.TDefaultWebAppServices2"
--
Dave Nottage
Steve Garland
still
investigating EJB's etc for moving a ISAPI/COM+/SQLServer app to Java. Lots
of issues to consider....
how about EJB's on the server and being able to access them with a Delphi
(or palm/wince client).
We are working on something (running in house) that uses a Jasta Java Server
via JNDI to talk to EJB servers and can then be accessed from Delphi (and
palm/wince) clients.
Jean-Marie Babet
rebuild a dependent package. Thanks for the heads-up. Let me investigate.
More later...
Bruneau.
"Dave Nottage" <da...@removethis.b3.com.au> wrote in message
news:3bb2cf84_1@dnews...
Dave Nottage
> Oops! Seems that someone changed something in the patch but failed to
> rebuild a dependent package. Thanks for the heads-up. Let me investigate.
I've managed to work around it by using a modified WebReq unit that creates
an instance of TDefaultWebAppServices instead of TDefaultWebAppServices2. I
cant see any immediate reason why it was changed at all.
With that fix, I have managed to make it work with the new runtime package.
Now all I need to do is test it on a machine that doesnt have Delphi
installed <g>
--
Dave Nottage
Dave Nottage
> The switch to TDefaultWebAppServices2 was to fix some memory leaks under
> ISAPI (it's one of those cases I mentioned yesterday about not being able
to
> change signature in a patch which prompted us not to create a SOAP runtime
> in the first place)... so I'm not too comfortable about you having to
switch
> back to the previous implementation.
Neither am I <g>
I wont be deploying anything serious just yet (and wont until the patch has
been "finalized" <g>), however I've managed to have my app up and running,
using the runtime package. I've also verified it on a machine that doesnt
have Delphi 6 installed (proving that the design-time package dependencies
are removed).
> I've just downloaded your .DPK and will spend some time on this tomorrow.
> Also, did you move the components registration calls??
Er.. move them from where, to where?
--
Dave Nottage
Jean-Marie Babet
The switch to TDefaultWebAppServices2 was to fix some memory leaks under
ISAPI (it's one of those cases I mentioned yesterday about not being able to
change signature in a patch which prompted us not to create a SOAP runtime
in the first place)... so I'm not too comfortable about you having to switch
back to the previous implementation.
I've just downloaded your .DPK and will spend some time on this tomorrow.
Also, did you move the components registration calls??
Regards,
Bruneau.
"Dave Nottage" <da...@removethis.b3.com.au> wrote in message
news:3bb3c283_1@dnews...
Jean-Marie Babet
make DCLSOAP depend on it and things look good. I've built a simple SOAP
application and confirmed that the .EXE imports SOAPRTL60 and not DCLSOAP60.
About the component registration, I was wrong; it seems that it was all
taken care in the patch#1. I remember us moving the calls but we were doing
for another reason (the GroupDescendentsWith() would pull in unnecessary
code); so I thought we still have some laying around in runtime modules.
DCLSOAP.DPK now looks as follows.
You did a wonderful job!!
Regards,
Bruneau.
=======================================================
package dclsoap;
{$R *.res}
{$ALIGN 8}
{ ASSERTIONS ON}
{$BOOLEVAL OFF}
{ DEBUGINFO OFF}
{$EXTENDEDSYNTAX ON}
{$IMPORTEDDATA ON}
{$IOCHECKS ON}
{ LOCALSYMBOLS OFF}
{$LONGSTRINGS ON}
{$OPENSTRINGS ON}
{$OPTIMIZATION ON}
{$OVERFLOWCHECKS OFF}
{$RANGECHECKS OFF}
{$REFERENCEINFO OFF}
{$SAFEDIVIDE OFF}
{ STACKFRAMES OFF}
{$TYPEDADDRESS OFF}
{$VARSTRINGCHECKS ON}
{$WRITEABLECONST ON}
{$MINENUMSIZE 1}
{$IMAGEBASE $500DFFFD}
{$DESCRIPTION 'Borland Soap Components'}
{$LIBSUFFIX '60'}
{$DESIGNONLY}
{$IMPLICITBUILD OFF}
requires
coreide,
rtl,
dbrtl,
xmlrtl,
vcl,
inet,
soaprtl,
designide,
dclstd,
dclnet,
dsnap;
contains
SoapReg in 'SoapReg.pas',
SoapLibX in 'SoapLibX.pas',
WSDLReg in 'WSDLReg.pas',
RIOReg in 'RIOReg.pas',
WSDLWiz in 'WSDLWiz.pas',
SoapWizReg in 'SoapWizReg.pas',
SoapDMX in 'SoapDmX.pas',
SoapWiz in 'SoapWiz.pas',
wsdlimportdlg in 'wsdlimportdlg.pas' {WSDLImporter},
DmxForm in 'DmxForm.pas' {SoapDMForm},
SoapDmConst in 'SoapDmConst.pas',
WebServImp in '..\internet\WebServImp.pas',
soapdesconst in 'soapdesconst.pas';
end.
"Dave Nottage" <da...@removethis.b3.com.au> wrote in message
news:3bb3ed08_1@dnews...
Jean-Marie Babet
See the 'SOAP runtime package files' message in the attachments section. I
successfully created a descendant of THTTPReqResp. The only dependencies
will (should) be RTL60, SOAPRTL60 and XMLRTL60.
Regards,
Bruneau.
"Vincent Parrett (VSoft)" <vin...@nospam.vsoft-tech.com.au> wrote in
message news:3bb2abb5$1_1@dnews...
Jean-Marie Babet
I'm puzzled by the warning you're noticing. Thanks.
Regards,
Bruneau.
"Dave Nottage" <da...@removethis.b3.com.au> wrote in message
news:3bb3ed08_1@dnews...
Dave Nottage
> If time allows, can you try the files I sent you in the attachments
section.
> I'm puzzled by the warning you're noticing. Thanks.
Refer to my reply in .attachments. I was referring to the .DPK file.
--
Dave Nottage
Dave Nottage
> About the component registration, I was wrong; it seems that it was all
> taken care in the patch#1.
Hm.. then a caveat (ie that update 1 is needed) applies to using/building
the runtime package?
> DCLSOAP.DPK now looks as follows.
Thanks very much.
> You did a wonderful job!!
Just following your instructions (except that I added to the requires
clause, via the .DCUs). <g>
--
Dave Nottage
Vincent Parrett (VSoft)
> Vincent,
>
> See the 'SOAP runtime package files' message in the attachments section. I
> successfully created a descendant of THTTPReqResp. The only dependencies
> will (should) be RTL60, SOAPRTL60 and XMLRTL60.
I tried, but without the dcp or dcu files I can't install anything. Also,
the THTTPReqResp.Execute methos is still not virtual in your code, so I got
a compiler error first up.
Jean-Marie Babet
I've sent you an email regarding the virtual change.
Regards,
Bruneau.
"Vincent Parrett (VSoft)" <vin...@nospam.vsoft-tech.com.au> wrote in
message news:3bb40328_1@dnews...