This was the first pass at just getting Axis 2.0 in.
Long term I can
come up with 3 integration strategies (philosophies) :
1) Axis 2.0 hidden. We programmatically build the
Axis 2.0
configuration context solely from SCDL web services
binding. The only
presences the user is aware of Axis 2.0 are the jars
being required.
2) Axis 2.0 partially exposed. Tuscany exposes those
configurations of
Axis 2.0 we think users could or should tweak. This
is pretty much the
same as 1, but we allow users through our own
configuration some of Axis
2.0 configuration options. Could it be in the SCDL in
an axis 2.0
section/extension (namespace)?
3) Axis 2.0 fully exposed. This is pretty much what we
have today.
Tuscany can fully configure Axis 2.0 from SCDL, but
for the power user
the full Axis 2.0 configuration is natively defined in
the Axis2.xml
format. We can even go as far that if determined a
user has configured
the associated entry or exist point service we bow out
and say you must
know must know what you're doing. Once Axis 2.0
allows for stream to
configure we could decide where this configuration is
kept (ie resource
in the classpath, or extension in the SCDL ? Other
ideas welcome)
Does anyone else see any other alternatives ?
To be fair I'm kinda partial to door number 3. I like
to be assisted
but come to a bind I perfer the option to take full
control of something.
Option 1 gets rid of Axis2.xml and thus the problem
where to put it is
solved. Tuscany fully configures Axis 2.0 and if
something goes wrong
we've messed up. It can be faster to load and no
chance of not finding
the configuration file. On downside there maybe
configuration options
user could do with Axis 2.0 that we've now made
inaccessible. If the
Axis 2.0 API is in a state flux this can becomes a bit
of a maintenance
issue with each new version of Axis 2.0 we step up to.
Option 2 gets rid of Axis2.xml but may just push where
it configured
elsewhere. We need to second guess what we want to
expose and how.
Since we can control what is exposed, Axis 2.0 should
always be
configured correctly. This has the same maintenance
issues and
potentially worse than the previous option.
Option 3 we're left to what we have today, but when
the ability to
configure from a stream is available it can be made a
little more
cleaner. Look for the axis2.xml configuration if not
present read the
standard configuration from a resource. Could it be
possible even in
this case to move this to an Axis 2.0 configuration to
an extension in
the SCDL ?
The plus side I think this is less of maintenance
issue. Just update
default configuration xml when we move to another
version of Axis 2.0.
User still have full control of Axis 2.0 should they
desire. For example
today I think should be possible to still add a global
handler, reuse
and existing Axis 2.0 developed service.) On the
downside users using
this could configure Axis 2.0 to not work with
Tuscany.
More thoughts?
Jean-Sebastien Delfino wrote:
> rick rineholt wrote:
>
>> Hello,
>> I kept failing running the tomcat test with the JMS
>> transport not being
>> present. Typical of Axis2.xml not found, I did
notice
>> the copy
>> statement in the build.xml, but because for some
>> reason, I believe it to
>> be I played with vanilla Axis2 beforehand, I
already
>> had an axis2.xml
>> and the copy only works if destination is older
and
>> in my particular
>> case it was not. One solution is to add the
overwrite
>> attribute and set
>> it to true. However in a more general perspective
I'm
>> not comfortable
>> with just over writing some projects global
artifact.
>> Could some Axis2
>> users having set this deliberately not take kindly
>> that we silently
>> write over this?
>>
>> I wonder if the ServiceClient code may have for
>> obtaining ServiceClient
>> String tuskAxisRoot=
>> System.getProperty("tuscany.axis2root");
>> tuskAxisRoot= tuskAxisRoot== null ? "." :
>> tuskAxisRoot;
>>
>> new ServiceClient(
>> new
>>
ConfigurationContextFactory().createConfigurationContextFromFileSystem(tuskAxisRoot),
>>
>> null);
>>
>>
>> Then we could have had the in test resource of the
>> client or local dir
>> an Axis2.xml ( I haven't tested this ... just from
>> eyeballing the code)
>>
>> BTW I have asked the Axis2 developers to
restructure
>> createConfigurationContextFromFileSystem to accept
a
>> stream and I think
>> they were ok with it. So hopefully this will all go
>> away.
>>
>> BTW2 to error is human ( I just posted this on the
>> axis2 dev first :-)
>>
>>
>> Cheers.
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam
protection around
>> http://mail.yahoo.com
>>
>
> Yes I agree with you, the Axis2 home could be used
for other Axis 2
> services independent of Tuscany, so I think that
what you propose is a
> good idea. To go even further do you think we could
derive a location
> for our Axis2 repository automatically instead of
requiring the user to
> configure a system property?
>
> Also what about constructing the Axis2
ConfigurationContext
> programmatically instead of reading it from an
axis2.xml file? Would
> that work? Do you know the pros and cons of that
approach compared to
> reading an axis2.xml file?
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
