Implement CGI deployment support for Axis2/C
--
Key: AXIS2C-1143
URL: https://issues.apache.org/jira/browse/AXIS2C-1143
Project: Axis2-C
Issue Type: New Feature
Environment: Linux\Window
FYI, VTD-XML's XPath implementation may be a good referece point
Supun Kamburugamuva writes:
Hi Varuna,
Didn't herd from you for a while. What is the status of the XPath
implementation. Are you catching up with Axis2/C and specially with Axiom/C.
I hope everything is going smoothly in the XP
Hi Varuna,
"Supun Kamburugamuva" <[EMAIL PROTECTED]> writes:
> Also if you have done any coding feel free to upload them to a Jira so we can
> look at them and give you feedback.
When we were doing Gsoc-2005, we used to update a wiki on weekly basis
[1], I think that would very good thing to trac
Hi Varuna,
Didn't herd from you for a while. What is the status of the XPath
implementation. Are you catching up with Axis2/C and specially with Axiom/C.
I hope everything is going smoothly in the XPath implementation.
XPath is a very important component for Axis2/C as well as other modules
like
Please see my comments inline.
It is good news that you have figured the reason for large data set problem.
> I think it is critical that we uplift performance for large data sets as
> well. Could you please point me to the source file location where you found
> the problem so that I too could hav
Fan, Jan-fon wrote:
Hi,
I created a simple “hello world” web services by using Microsoft .NET.
User specifies the first name and last name, this service just returns
“Hello World first_name last_name” to the user.
The soap request defined for this web services is:
http://www.w3.org/2001/XM
Supun Kamburugamuva wrote:
I think I have found the reason behind Guththila's low performance on
large data sets. Guththila's token cache gets too big in large
requests. A simple release statement was missing in the code and that
causes the cache to get too big. I need to investigate further on
+1 for starting with CGI.
Regards
Nandika
On Thu, May 15, 2008 at 10:53 PM, Samisa Abeysinghe <[EMAIL PROTECTED]> wrote:
> IMHO, if we can only have CGI to start with within the GSOC time frame, that
> would be quite an achievement.
> You can do the FCGI stuff after GSOC ;) That is the whole poin
IMHO, if we can only have CGI to start with within the GSOC time frame,
that would be quite an achievement.
You can do the FCGI stuff after GSOC ;) That is the whole point of GSOC,
make you a long time contributor :)
On the logging thing, yes it does not make sense at all to write
multiple log
Hi again,
I noticed that Steve came up with a patch, let me check on that first. It
might be a better solution.
Regards,
Senaka
> Hi Supun,
>
> Yes, That needs to be sorted for the REST case. But, I believe that this
> rather a bug in the REST portion of the engine, and the SOAP portion
> should
Hi Supun,
Yes, That needs to be sorted for the REST case. But, I believe that this
rather a bug in the REST portion of the engine, and the SOAP portion
should not be affected. BTW, it is better if we could split the engine's
dependent portions of HTTP common to another lib. Say, HTTP Core?
Thought
Hi Senaka,
Did you mean something like providing a compile time flag for not including
these stuff if rest is not needed? If that is the case we are in the same
position when rest is needed (we have circular dependencies).
Regards,
Supun.
On Thu, May 15, 2008 at 5:30 PM, Senaka Fernando <[EMAIL
Hi devs,
AFAIK, this is because of the REST portions of the engine depending on the
HTTP libraries. So if someone is not interested in REST can we instead not
link these libraries?
Regards,
Senaka
> Circular dependency between engine and http_common libraries
> --
[
https://issues.apache.org/jira/browse/AXIS2C-1142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Nairn updated AXIS2C-1142:
Attachment: http_common.patch
The attached patch against r656580 of trunk) contains a proposed sol
Circular dependency between engine and http_common libraries
Key: AXIS2C-1142
URL: https://issues.apache.org/jira/browse/AXIS2C-1142
Project: Axis2-C
Issue Type: Bug
Comp
Yes FCGI is far more better. I will first try to implement CGI as fast
as possible, probably there will be time left for FCGI, but FCGI as I
read is rather complicated and will take much more time.
Only problem is with log files in CGI, it a little stupid to make a new
file for every process, I'
[
https://issues.apache.org/jira/browse/AXIS2C-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Supun Kamburugamuva closed AXIS2C-1141.
---
> Guththila doesn't release the tokens for end elements
> --
[
https://issues.apache.org/jira/browse/AXIS2C-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Supun Kamburugamuva resolved AXIS2C-1141.
-
Resolution: Fixed
Fixed the issue in the trunk.
> Guththila doesn't release the
Guththila doesn't release the tokens for end elements
-
Key: AXIS2C-1141
URL: https://issues.apache.org/jira/browse/AXIS2C-1141
Project: Axis2-C
Issue Type: Bug
Components: guthth
19 matches
Mail list logo
