Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Subject: Re: Some Design Questions...
From: Roshan Weerasuriya <roshan@opensource.lk>
To: Apache AXIS C Developers List <axis-c-dev@ws.apache.org>
In-Reply-To: 
 <OF03D31903.FDDCDC15-ON80256EF4.00293AEF-80256EF4.0029969C@uk.ibm.com>
References: 
	 <OF03D31903.FDDCDC15-ON80256EF4.00293AEF-80256EF4.0029969C@uk.ibm.com>
Content-Type: text/plain
Organization: 
Message-Id: <1092837084.1187.20.camel@localhost.localdomain>
Mime-Version: 1.0
Date: 18 Aug 2004 19:51:24 +0600
Content-Transfer-Encoding: 7bit

hi Scott,

> (1) Has the axis server engine accommodated the possibility
> > of asynchronous handlers in either the Request or Response chains?

What do you mean by "asynchronous handlers" here?

Roshan

On Wed, 2004-08-18 at 13:34, John Hawkins wrote:
> 
> 
> Hi,
> 
> Update on trace -
> 
> AspectC++ for entry and exit trace - I think we have to declare this a
> non-starter. Having looked into it - the AspectC++ code is simply not
> capable of doing the simple things we need to do. I get compile errors all
> over the place. I'm still investigating but will not be able to implement
> in the 1.3/1.4 timeframe. I intend to introduce some other way of adding
> entry and exit trace (java pre--parser or the like) - we have a first
> version but it needs improving. I'll keep in contact with the AspectC folks
> and try to get aspects working in the future.
> 
> 
> 
> John Hawkins
> 
> 
>                                                                            
>              Samisa Abeysinghe                                             
>              <samisa_abeysingh                                             
>              e@yahoo.com>                                               To 
>                                        Apache AXIS C Developers List       
>              18/08/2004 06:05          <axis-c-dev@ws.apache.org>          
>                                                                         cc 
>                                                                            
>              Please respond to                                     Subject 
>               "Apache AXIS C           Re: Some Design Questions...        
>              Developers List"                                              
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
> 
> 
> 
> 
> Hi Scott,
>    At the moment none of the features you are looking for are available in
> Axis C++.
>    However the good news is that there are plans for a new version. Your
> ideas could be taken as
> input for the new design.
> 
> 
> > (1) Has the axis server engine accommodated the possibility
> > of asynchronous handlers in either the Request or Response chains?
> 
> Not at the moment.
> 
> >
> > (2) What is the plan for allowing AxisCpp integrators to plug-in
> > their own logging subsystem?
> >
> 
> This would require a 'logging abstraction layer'. This will be food for
> thought for the new
> design.
> Hopefully plans would be available soon.
> At the moment there is an effort going on to use Aspect C++ for tracing.
> However, as I understand
> this is not what you are looking for.
> 
> > (3) Similarly, what is the plan for custom memory managers?
> >
> 
> Memory management has been identified as one of the areas to be improved.
> The palns would be laid
> down soon.
> 
> >
> > Thank you,
> > -Scott
> >
> >
> > PS - Related to item (3) above...I saw in your TODO list that
> > you would like to walk away from STL.  FWIW, this is wise.
> > I've had to cut out all STL in my own projects because of many
> > leaks and inconsistencies amongst different STL implementations.
> > Sad, but true.
> >
> 
>     There has been much debate on dropping vs keeping STL. However, the
> community decided to keep
> it within the engine as it is believed to be efficient and easy to use.
> There had been some effort
> to eliminate STL at client stub level.
>     Considering the amount of STL being used in the core code at the
> moment, it is not an easy
> task to drop all STL overnight.
>     I too have had bad experiance with STL in the past. I hope the future
> versions would take the
> concerns into account.
> 
> Samisa...
> 
> >
> 
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail Address AutoComplete - You start. We finish.
> http://promotions.yahoo.com/new_mail
> 
> 
>