[
https://issues.apache.org/jira/browse/AXIS2-3864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605510#action_12605510
]
Dmitry Yakovlev commented on AXIS2-3864:
Жду ответа, как соловей лета
> NPE at
>
NPE at
org.apache.axis2.databinding.utils.BeanUtil.getPullParser(BeanUtil.java:137)
---
Key: AXIS2-3864
URL: https://issues.apache.org/jira/browse/AXIS2-3864
Project: Axi
[
https://issues.apache.org/jira/browse/AXIS2-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Gawor resolved AXIS2-3854.
Resolution: Fixed
Fix Version/s: nightly
Committed the patch to trunk (revision 668384).
>
[
https://issues.apache.org/jira/browse/AXIS2-3863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605453#action_12605453
]
Andreas Veithen commented on AXIS2-3863:
This should not be required if the shutdow
[
https://issues.apache.org/jira/browse/AXIS2-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605452#action_12605452
]
Andreas Veithen commented on AXIS2-3862:
This should not be required if the shutdow
[
https://issues.apache.org/jira/browse/AXIS2-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12605450#action_12605450
]
Andreas Veithen commented on AXIS2-3861:
I don't see the need to disable the shutdo
I haven't finished wading through the whole thread on this, but I fully
support Deepal's position that Axis2 should focus on supporting its user
base by not breaking things.
There is functionality that users have asked for (hey, do we support
consuming rpc/encoded services via ADB yet?) that would
Extract initTransport() method from AxisServlet::init( ServletConfig )
--
Key: AXIS2-3863
URL: https://issues.apache.org/jira/browse/AXIS2-3863
Project: Axis 2.0 (Axis2)
Iss
[
https://issues.apache.org/jira/browse/AXIS2-3863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Vladimirov updated AXIS2-3863:
-
Attachment: patch.txt
> Extract initTransport() method from AxisServlet::init( ServletCon
[
https://issues.apache.org/jira/browse/AXIS2-3863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Vladimirov updated AXIS2-3863:
-
Priority: Minor (was: Trivial)
> Extract initTransport() method from AxisServlet::init(
[
https://issues.apache.org/jira/browse/AXIS2-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Vladimirov updated AXIS2-3862:
-
Attachment: patch.txt
Also, startTransports() method is extracted in different method - I
ListenerManager::startedTransports is not visible to child classes
--
Key: AXIS2-3862
URL: https://issues.apache.org/jira/browse/AXIS2-3862
Project: Axis 2.0 (Axis2)
Issue Type:
[
https://issues.apache.org/jira/browse/AXIS2-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Vladimirov updated AXIS2-3861:
-
Priority: Minor (was: Major)
Issue Type: Wish (was: Bug)
Workaround:
- to overrid
Should be an option to disable ShutdownHook of ListenerManager
--
Key: AXIS2-3861
URL: https://issues.apache.org/jira/browse/AXIS2-3861
Project: Axis 2.0 (Axis2)
Issue Type: Bug
On Mon, Jun 16, 2008 at 6:41 PM, Davanum Srinivas <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Guys,
>
> Sun is promising full interop JAM<->OSGi [1]. They are trying to pull in
> Peter [2] to help. Gory details here [3]. Sun
> folks are playing politics it seem
+1
Saminda
On Mon, Jun 16, 2008 at 7:17 PM, Guillaume Sauthier <
[EMAIL PROTECTED]> wrote:
> Hi Dims & all
>
> This discussion about OSGi is very interesting.
> I agree that OSGi benefits are maybe not directly visible for the end-user
> but maybe more for the deployer/assembler.
>
> We did exac
On Mon, Jun 16, 2008 at 5:26 PM, Paul Fremantle <[EMAIL PROTECTED]> wrote:
> I think the ideal outcome would be this:
>
> * Firstly we allow Axis2 to work cleanly in a OSGi environment.
Axis2 need to lax the tight dependency between modules and services. This
should be done only in OSGi environm
Hi Dims & all
This discussion about OSGi is very interesting.
I agree that OSGi benefits are maybe not directly visible for the
end-user but maybe more for the deployer/assembler.
We did exactly what you want to do with Axis with our EJB3 container
(EasyBeans) a year ago:
* Having OSGi as an
On Mon, Jun 16, 2008 at 5:29 AM, Ruwan Linton <[EMAIL PROTECTED]>
wrote:
> Saminda,
>
> Can you please answer to these question directly (yes/no)?
>
> Will this change preserve backward compatibility?
> Will we be able to use axis2 as it is, without OSGi?
> Will the current behavior be preserved?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Guys,
Sun is promising full interop JAM<->OSGi [1]. They are trying to pull in Peter
[2] to help. Gory details here [3]. Sun
folks are playing politics it seems [4].
Bottom line, 277 may be farther away than you think. Since GlassFish has
already
Deepal
I think you completely missed the point.
Changes to the Java VM require users to migrate. That can be
difficult. Many users are still on JDK 1.4 for core systems because
they are on App Servers certified on that model. OSGi has been
designed to work *with* any JVM and therefore avoid requi
Ruwan Linton wrote:
Also just wanted to make sure, what is the advantage of being OSGi
with Java 7 which promises to provide versionning via JAM (Java
Application Modules)
How long would it be before "everyone" adopts 1.7?
I think same answer can be applied for the OSGi as well ;-)
-Dee
Ruwan Linton wrote:
Also just wanted to make sure, what is the advantage of being OSGi
with Java 7 which promises to provide versionning via JAM (Java
Application Modules)
How long would it be before "everyone" adopts 1.7?
Samisa...
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul,
That's exactly that's being done so far on the osgi module in various stages of
completion :) [Except for the last item]
thansk,
dims
Paul Fremantle wrote:
| I think the ideal outcome would be this:
|
| * Firstly we allow Axis2 to work clean
I think the ideal outcome would be this:
* Firstly we allow Axis2 to work cleanly in a OSGi environment.
* We also allow Axis2 to work in a non-OSGi environment (full
backwards compatibility).
* We define an extension to Axis2 that is available as a separate JAR
that enables OSGi
* If the OSGi ext
Saminda Abeyruwan wrote:
=
1. When aar/mar behavior is mimicked in an OSGi bundle, these bundles
be able to live in different class spaces.
ex: If the bundles needed different hibernate versions they can be
easily plug into different class spa
Dear Keith,
Thanks for your reply.
We're aware that Axis2 is much faster than Axis1.X and we have conducted
similar tests as described in the articles.
Our question is, is the performance gain in Axis2 is due to the use of
StAX API? In my opinion StAX is not faster than SAX , so how come Axis2
is
Hi,
Here are some results of performance testing We've done. You can go through
these articles to see the reality (Axis2 is FAST).
http://wso2.org/library/91
http://wso2.org/library/588
Thanks,
Keith.
On Mon, Jun 16, 2008 at 2:43 PM, <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Sorry for double posti
Generated getUniqueSuffix() should return full-qualified java.lang.String
instead String.
-
Key: AXIS2-3860
URL: https://issues.apache.org/jira/browse/AXIS2-3860
Hi,
I read somewhere that Axis2 provides better performance comparing to
Axis 1.X due to the introduction of StAX XML parsing. Based some tests,
I can see that for large XML document Axis2 is 5 to 10 times faster than
Axis 1.X. I'm a bit confused here since Axis1.X uses SAX parser which
should be
Hi,
Sorry for double posting..
I read somewhere that Axis2 provides better performance comparing to
Axis 1.X due to the introduction of StAX XML parsing. Based some tests,
I can see that for large XML document Axis2 is 5 to 10 times faster than
Axis 1.X. I'm a bit confused here since Axis1.X
Agreed.
Michele
On 16 Jun 2008, at 03:19, Asankha C. Perera wrote:
Dims
Would you object even if changes are incremental and don't affect
existing use cases / scenarios? Specifically, in a
non-osgi environment existing functionality is kept as-is?
No I will not object.. as long as the cor
32 matches
Mail list logo
