Replacing Axis1 binding with Axis2
Looks like we're good to go with new Axis2 WS binding now, so what should we do with the old Axis1 binding? How about leaving the binding.axis project there and updating the pom.xml in the sca folder to have binding.axis2instead of binding.axis. That way the old axis binding is there if anyone wants it but we don't drag in all thae Axis1 dependencies. ...ant
Re: Replacing Axis1 binding with Axis2
ant elder wrote: Looks like we're good to go with new Axis2 WS binding now, so what should we do with the old Axis1 binding? How about leaving the binding.axis project there and updating the pom.xml in the sca folder to have binding.axis2instead of binding.axis. That way the old axis binding is there if anyone wants it but we don't drag in all thae Axis1 dependencies. ...ant Yes good idea. Let's just leave the old axis1 binding in place but comment it out of the sca pom.xml. Also I'll give it a try today to see if it still works :) -- Jean-Sebastien
SDO for PHP
Readers of this list may be interested to know that the first stable release of SDO for PHP recently shipped on the PHP Extension Community Library: http://pecl.php.net/package/sdo This project uses the Tuscany SDO for C++ library internally, but presents a native PHP interface. -- Caroline Maynard
[jira] Created: (TUSCANY-62) Users should not need to include axis2.jar in their application
Users should not need to include axis2.jar in their application --- Key: TUSCANY-62 URL: http://issues.apache.org/jira/browse/TUSCANY-62 Project: Tuscany Type: Improvement Components: Java SCA Axis Integration Reporter: Jeremy Boynes When using Axis2 webservices, the user needs to include the axis2 configuration file in their web application. It would be easier for them if we included default version of that in our binding implementation so that they did not need to perform this step. Alternatively, we should investigate if we can configure the Axis2 engine programmatically and include it in the binding module as another system service. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: AggregateContext.getAggregate()
Can we open this discussion? My inclination is to agree that most processing flow, as opposed to configuration, code should not rely on model objects (I'm assuming builders are configuration code). It may be useful though to provide a management interface that exposes the model, but this should only be used for introspection purposes only. Do people have objections to this approach? Jim On Feb 28, 2006, at 5:02 PM, Jeremy Boynes wrote: I have issues with this addition as it creates a reference from the runtime to the logical model and we were trying to avoid those. The only place that this used is in the Axis1 servlet that, during processing of the first request, configures the Axis engine by retrieving the logical model using this method and then digging around inside it to find the web services entry points. This function is the responsibility of the builders not the runtime and especially not a request handler. This could have been done by having the builder create the EngineConfiguration (or even the actual Engine) during initialization and passed it to the servlet by binding into the servlet context. Or, if integrated into the web container, specifically initialized the servlet during auto-creation. When done up front, the configuration processing is deterministic - it occurs when the application starts rather at some arbitrary time when the first request comes in. This makes troubleshooting the configuration in a production environment much simpler. It also means you avoid an arbitrary but extended delay on first invoke as the configuration information gets processed. It also means that all configuration and wiring is done by the builder framework which has more knowledge about the whole configuration than the binding does. For example, it can make the distinction about where to apply policy handlers (e.g. in the web services binding or as interceptors on the entry point itself). This is all from the Axis1 implementation. When we do the Axis2 version, please can we set up the engine during startup and avoid the need for the main processing flow to interact with the logical model. I will open a JIRA to track this and deprecate the getAggregate() method until we can remove it. -- Jeremy
Re: Defining WSDL to SDO
I just committed a fix so that now XSDHelper.define() will not hide generated types registered with SDOUtil.registerStaticTypes(). The new behavior is that the first registration, either using XSDHelper.define() or SDOUtil.registerStaticTypes(), of a namespace is the one that will be used. Subsequent calls to define() are a NOOP and will return the existing types. In the future, we may want to look at allowing new types to be added to an existing namespace, but currently that is not supported. Frank. Frank Budinsky/Toronto/[EMAIL PROTECTED] wrote on 03/02/2006 07:47:15 PM: Jean-Sebastien Delfino [EMAIL PROTECTED] wrote on 03/02/2006 07:10:55 PM: Jean-Sebastien Delfino wrote: ant elder wrote: For the new Axis2 based WS binding we need to get WSDL defined to SDO so that the SOAP Body XML can be (de)serialized to DataObjects correctly. Could that happen when the import.wsdl in the sca.module is being processed? Thats done by org.apache.tuscany.model.assembly.impl.AggregateImpl in the initialize method. Adding the following line just after the getAssemblyLoader().loadDefinition call seems to work: XSDHelper.INSTANCE.define(url.openStream(), null); Would this be ok? Thanks, ...ant Yes I think this is OK. If your service is flowing complex types and you have generated SDO classes then you just need one of the components in your application module to reference the generated SDO Factory to trigger the initialization of the metadata for your complex types. But in scenarios flowing elements of simple types e.g. element name=getGreetings type=xsd:string you won't have generated SDO classes so you definitely need to invoke XSDHelper.INSTANCE.define(url.openStream(), null) to get the metadata for your elements in place. I have a set of related SDO questions - and depending on the answers we may have a problem or not :) Let's say that at build time I give x.wsdl to the SDO code generator. I get SDO classes generated for the XSD types defined in my WSDL types section . Then at runtime I want to use these SDO classes in an SCA component. To trigger the initialization of the SDO metadata for these types I simply reference the generated factory or use SDOUtil.registerStaticTypes(...) when my SCA component starts. Then Ant's Axis2 Entry Point runtime does XSDHelper.INSTANCE.define(the exact same x.wsdl)... My understanding is that this will dynamically generate SDO metadata from the given WSDL.. Which version of the metadata is the SDO runtime going to use? the first one that gets registered? the last one? Is XSDHelper going to detect that already have SDO metadata registered with static types for the given namespace? Do we get new SDO metadata each time we invoke XSDHelper.define(...)? If XSDHelper.define() is called more than once, the second and subsequent calls just return the already defined types. But this is not true for statically generated classes. I think that with the current implementation the dynamically defined model will hide the generated classes. I suppose I could put a check in XSDHelper.define() to do nothing (just return) if the namespace is already registered with static classes, if that's what we want. It's an easy change, but we should think about what the right long term answer is for this whole issue. -- Jean-Sebastien
EntryPointContext change getInstance()
After talking with Sebastien the other day, it appears Axis1 uses
reflection to make invocations, requiring entry points to return
proxies implementing the exposed service (Axis2 appears different).
So, I changed getInstance(..) to return a generated proxy - if you
don't need a proxy, get the InvocationHandler directly using
getImplementationInstance() as in:
AggregateContext aggregateContext = ...
EntryPointContext ctx = (EntryPointContext)
aggregateContext.getContext(quot;sourcequot;);
Assert.assertNotNull(ctx);
InvocationHandler handler = (InvocationHandler)
ctx.getImplementationInstance();
Object response = handler.invoke(null, operation, new
Object[] { param });
I updated the Axis2 code to do this
(WebServiceEntryPointInOutSyncMessageReceiver) as well as the test
cases. Sebastien, Axis1 still creates the proxy using the
ProxyFactory from the entry point. I included a FIXME but did not
change this as I think this change will be conntected to the
discussion on getAggregate().
Jim
Re: EntryPointContext change getInstance()
I seem to remember an offline discussion a long time ago where we
thought about extending InstanceContext to provide access to the head of
the interceptor chain and head of the handler chains.
This would seem to be more flexible than going to the InvocationHandler
especially as we would like to consider replacing the use of reflection
with the bytecode generation of specialized proxies.
I imagine the code in that case would be something like:
Interceptor head = ctx.getInterceptor(operationName);
Message msg = factory.createMessage();
msg.setBody(args);
head.invoke(msg);
Does this still make sense?
--
Jeremy
Jim Marino wrote:
After talking with Sebastien the other day, it appears Axis1 uses
reflection to make invocations, requiring entry points to return
proxies implementing the exposed service (Axis2 appears different). So,
I changed getInstance(..) to return a generated proxy - if you don't
need a proxy, get the InvocationHandler directly using
getImplementationInstance() as in:
AggregateContext aggregateContext = ...
EntryPointContext ctx = (EntryPointContext)
aggregateContext.getContext(quot;sourcequot;);
Assert.assertNotNull(ctx);
InvocationHandler handler = (InvocationHandler)
ctx.getImplementationInstance();
Object response = handler.invoke(null, operation, new
Object[] { param });
I updated the Axis2 code to do this
(WebServiceEntryPointInOutSyncMessageReceiver) as well as the test
cases. Sebastien, Axis1 still creates the proxy using the ProxyFactory
from the entry point. I included a FIXME but did not change this as I
think this change will be conntected to the discussion on getAggregate().
Jim
[jira] Created: (TUSCANY-63) Need an SPI for co-ordination between EntryPoints and the infrastructure that will invoke them
Need an SPI for co-ordination between EntryPoints and the infrastructure that will invoke them -- Key: TUSCANY-63 URL: http://issues.apache.org/jira/browse/TUSCANY-63 Project: Tuscany Type: Bug Components: Java SCA Core Reporter: Jeremy Boynes In order to get the Tomcat integration code to create servlets for web-services bound entry points it needed to know implementation details of the binding. This will not allow integrators to freely embed Tuscany in different environments or binding providers to contribute new bindings without knowing something about those environments. I would suggest that we define an SPI implemented by environment integrators that will allow entry point implementations to request creation of transport endpoints. So, taking the example of Axis2 and Tomcat, the Axis2 binding would request a transport binding from the environment and which would be activated when the EP started. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-64) Tomcat integration code should be map to determine endpoint address
Tomcat integration code should be map to determine endpoint address --- Key: TUSCANY-64 URL: http://issues.apache.org/jira/browse/TUSCANY-64 Project: Tuscany Type: Bug Components: Java SCA Axis Integration, Java SCA Tomcat Integration Reporter: Jeremy Boynes The current implementation hard codes the servlet path for the Axis2 servlet to /services/* - this may not actually be what the user wants or where the URI points to. Until we solve TUSCANY-63 then we should provide a way for the integration code to determine the actual endpoint address from the EP. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: EntryPointContext change getInstance()
I was originally going to do this but the problem is we need to pass
in the operation (method) to invoke. The handler then looks up the
appropriate interceptor chain.
Another option we could do is create another InvocationHandler
interface that allows someone to get at the interceptors if they
need. I was assuming bytecode gen frameworks could still be used with
the current API - they would just have to return an interface that
supports InvocationHandler. I held off creating an alternative to
InvocationHandler since I thought the JDK one was close enough. If
people thing this is a good thing, I'm happy to put in support since
it will be straightforward. We probably will need to procide an
interface at some point we can cast to that allows a client to get
had the interceptor chains.
Jim
On Mar 3, 2006, at 4:20 PM, Jeremy Boynes wrote:
I seem to remember an offline discussion a long time ago where we
thought about extending InstanceContext to provide access to the
head of
the interceptor chain and head of the handler chains.
This would seem to be more flexible than going to the
InvocationHandler
especially as we would like to consider replacing the use of
reflection
with the bytecode generation of specialized proxies.
I imagine the code in that case would be something like:
Interceptor head = ctx.getInterceptor(operationName);
Message msg = factory.createMessage();
msg.setBody(args);
head.invoke(msg);
Does this still make sense?
--
Jeremy
Jim Marino wrote:
After talking with Sebastien the other day, it appears Axis1 uses
reflection to make invocations, requiring entry points to return
proxies implementing the exposed service (Axis2 appears
different). So,
I changed getInstance(..) to return a generated proxy - if you don't
need a proxy, get the InvocationHandler directly using
getImplementationInstance() as in:
AggregateContext aggregateContext = ...
EntryPointContext ctx = (EntryPointContext)
aggregateContext.getContext(quot;sourcequot;);
Assert.assertNotNull(ctx);
InvocationHandler handler = (InvocationHandler)
ctx.getImplementationInstance();
Object response = handler.invoke(null, operation, new
Object[] { param });
I updated the Axis2 code to do this
(WebServiceEntryPointInOutSyncMessageReceiver) as well as the test
cases. Sebastien, Axis1 still creates the proxy using the
ProxyFactory
from the entry point. I included a FIXME but did not change this
as I
think this change will be conntected to the discussion on
getAggregate().
Jim
[jira] Commented: (TUSCANY-63) Need an SPI for co-ordination between EntryPoints and the infrastructure that will invoke them
[ http://issues.apache.org/jira/browse/TUSCANY-63?page=comments#action_12368825 ] Jim Marino commented on TUSCANY-63: --- Can we have the builder set this up, perhaps through the builder registry? I was also thinking it may be useful if the Axis engine was somehow a component and we have it register as a transport in the runtime. There would be some kind of eventing mechanism where the builder passes a reference to the entry point context which when created sends a request to that reference for a transport address, etc., to be created. Normally, I would like the builder to do all of this, but we have to be careful that the transport is not notified prior to the entry point context being created. Need an SPI for co-ordination between EntryPoints and the infrastructure that will invoke them -- Key: TUSCANY-63 URL: http://issues.apache.org/jira/browse/TUSCANY-63 Project: Tuscany Type: Bug Components: Java SCA Core Reporter: Jeremy Boynes In order to get the Tomcat integration code to create servlets for web-services bound entry points it needed to know implementation details of the binding. This will not allow integrators to freely embed Tuscany in different environments or binding providers to contribute new bindings without knowing something about those environments. I would suggest that we define an SPI implemented by environment integrators that will allow entry point implementations to request creation of transport endpoints. So, taking the example of Axis2 and Tomcat, the Axis2 binding would request a transport binding from the environment and which would be activated when the EP started. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (TUSCANY-63) Need an SPI for co-ordination between EntryPoints and the infrastructure that will invoke them
[ http://issues.apache.org/jira/browse/TUSCANY-63?page=comments#action_12368832 ] Jim Marino commented on TUSCANY-63: --- We may have to think about a general eventing mechanism in the runtime (there is the basic EventContext stuff)...We could perhaps have the builder prepare everything and hand the configuration to the registry which can then send a notification to the transport, in this case Axis. Axis won 't turn on the entry point until it is notified during a MODULE_START event. Need an SPI for co-ordination between EntryPoints and the infrastructure that will invoke them -- Key: TUSCANY-63 URL: http://issues.apache.org/jira/browse/TUSCANY-63 Project: Tuscany Type: Bug Components: Java SCA Core Reporter: Jeremy Boynes In order to get the Tomcat integration code to create servlets for web-services bound entry points it needed to know implementation details of the binding. This will not allow integrators to freely embed Tuscany in different environments or binding providers to contribute new bindings without knowing something about those environments. I would suggest that we define an SPI implemented by environment integrators that will allow entry point implementations to request creation of transport endpoints. So, taking the example of Axis2 and Tomcat, the Axis2 binding would request a transport binding from the environment and which would be activated when the EP started. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (TUSCANY-66) WebServiceEntryPointServlet doesn't popluate all the WS entry points into the Axis2 service registry (It only handles the 1st module)
WebServiceEntryPointServlet doesn't popluate all the WS entry points into the Axis2 service registry (It only handles the 1st module) - Key: TUSCANY-66 URL: http://issues.apache.org/jira/browse/TUSCANY-66 Project: Tuscany Type: Bug Environment: Windows XP Reporter: Raymond Feng Priority: Blocker Attachments: rfeng.diff Caused by: java.lang.Exception: org.apache.axis2.AxisFault: AxisService Not found yet at org.apache.axis2.engine.InstanceDispatcher.fillContextsFromSessionContext(InstanceDispatcher.java:99) at org.apache.axis2.engine.InstanceDispatcher.invoke(InstanceDispatcher.java:56) at org.apache.axis2.engine.Phase.invoke(Phase.java:376) at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:351) at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:322) at org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:274) at org.apache.tuscany.binding.axis2.handler.WebServiceEntryPointServlet.doPost(WebServiceEntryPointServlet.java:179) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
