[Summary] Monitor Extension Functionality How to create a new monitor extension
Here is the brief summary on the monitor extensions, please review the same
and post your comments and suggestions on the same. This would help us for
the documentation.
**
*Need for Monitor Extension:*
**The need for monitor extension came as a requirement, to have a customized
exception handling on Tuscany runtime especially when the user input errors
are determined while reading, resolving and building phase of the
contribution within the Tuscany runtime. Here different users/vendors using
Tuscany with their products wanted to ignore some of the user input errors
and allow the runtime to proceed further, while the others wanted to stop
processing when a error is determined at the end of each phase.
Another important need for a monitor extension is to validate the user
inputs (via contributions) and report all the issues identified in one go
(Example: As how the java compiler does for java code).
* *
*How monitor extension is applied to the current code:*
Currently monitors are introduced into various part of the code, where we do
a validation for user input at different phases while reading, resolving and
building the contribution.
**
**
1. Errors and warnings are logged with the monitor as problems and the
processing
continues. Exceptions won't be thrown, where ever possible. Processing here
covers any processing of user input, i.e. contributions and the artifacts
they contain.
2. After each phase namely read, resolve and build contribution, the problems
are read from the monitor for display to the user (currently this will have
already happened as our current monitor will just log errors and warnings as
it receives them but you can imagine more capable monitors).
3. The controlling logic may look at the errors and warnings it is reporting
to the user and prevent further processing occurring. Or it may allow
processing
to continue. This depends on which bit of processing we are talking about
and what errors have been reported.
* *
*How to initialize the monitor from the core runtime:*
Monitors are initialized in the core runtime using the utility extensions as
shown below.
UtilityExtensionPoint utilities = extensionPoints.getExtensionPoint(
UtilityExtensionPoint.*class*);
MonitorFactory monitorFactory = utilities.*getUtility*(MonitorFactory.*class
*);
monitor = monitorFactory.createMonitor();
* *
*Creating a Monitor Extension:*
* *
*NOTE: *Please have a look at the interface design of Monitor, Problem and
MonitorFactory from monitor module in the Tuscany source code.**
* *
*Step 1: *Create a class MyMonitorImpl.java which implements the Monitor
interface.
*public* *class* MyMonitorImpl* implements* Monitor {
*private* *static* *final* Logger *logger* = Logger.*getLogger*(
MyMonitorImpl.*class*.getName());
// Cache all the problem reported to monitor for further analysis
*private* ListProblem problemCache = *new* ArrayListProblem();
*public* *void* problem(Problem problem) {
// Your custom code to handle the problem
}
}**
**
**
In this code, we keep a cache of all the problems reported via the monitor
to allow the controlling logic to decide if the processing should continue
or not.
* *
*Step 2: *Create a class MyMonitorFactoryImpl.java which implements
the MonitorFactory
interface.
*public* *class* MyMonitorFactoryImpl* implements* MonitorFactory {
*private* Monitor monitor = *null*;
*public* Monitor createMonitor() {
*if* (monitor == *null*){
monitor = *new* MyMonitorImpl();
}
*return* monitor ;
}
}
*Step 3: *Create a plain text file named as META-
INF/services/org.apache.tuscany.sca.monitor.MonitorFactory
Register the extension by adding a line in this file as shown below….
org.apache.tuscany.sca.monitor.impl.MyMonitorFactoryImpl
--
Thanks Regards,
Ramkumar Ramalingam
Re: Problem seen in Policy Processors
As explained in my previous post, after introducing a fix as shown below
Intent resolvedRequiredIntent = resolver.resolveModel(Intent.class,
requiredIntent);
if (!resolvedRequiredIntent.isUnresolved()) {
requiredIntents.add(resolvedRequiredIntent);
for the unreachable code, noticed that not always this condition holds good
to validate. The above fix holds good if all the simple intents were defined
at the top of the definitions.xml as shown below.
!-- simple intent --
intent name=confidentiality constrains=sca:binding/intent
intent name=integrity constrains=sca:binding/intentintent
name=messageProtection constrains=sca:binding
requires=test:confidentiality test:integrity
/intent
Instead when the simple intents are placed at the bottom of the
definitions.xml as shown below,
intent name=messageProtection constrains=sca:binding
requires=test:confidentiality test:integrity
/intent
!-- simple intent --
intent name=confidentiality constrains=sca:binding/intent
intent name=integrity constrains=sca:binding/intent
then the code does not seem to work as required. This is because
SCADefinitionsProcessor.java tries to resolve the policies in the order as
it was read. I believe this should not happen and needs a rewriting for
resolving the policies.
Can anyone suggest if this is the right approach?
--
Thanks Regards,
Ramkumar Ramalingam
Build error in modules/implementation/osgi tests
I am seeing JUnit test failures in modules/implementation/osgi. Is anyone else also noticing the same? Using default configuration properties. Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.432 sec FAILURE! testOSGiComponent(org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTestCase) Time elapsed: 1.422 sec ERROR! java.lang.NoSuchMethodError: org/apache/tuscany/sca/databinding/DataBindingExtensionPoint.introspectType(Lorg/apache/tuscany/sca/interfacedef/DataType;[Ljava/lang/annotation/Annotation;)Z at org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory$ObjectFactoryImplBase.init(JavaPropertyValueObjectFactory.java:214) at org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory$ObjectFactoryImpl.init(JavaPropertyValueObjectFactory.java:221) at org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory.createValueFactory(JavaPropertyValueObjectFactory.java:123) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.processProperties(OSGiImplementationProvider.java:210) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.setReferencesAndProperties(OSGiImplementationProvider.java:1143) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.start(OSGiImplementationProvider.java:1150) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:631) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:245) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113) Using default configuration properties. Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.591 sec FAILURE! testOSGiComponent(org.apache.tuscany.sca.implementation.osgi.invocation.OSGiPropertyTestCase) Time elapsed: 0.571 sec ERROR! java.lang.NoSuchMethodError: org/apache/tuscany/sca/databinding/DataBindingExtensionPoint.introspectType(Lorg/apache/tuscany/sca/interfacedef/DataType;[Ljava/lang/annotation/Annotation;)Z at org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory$ObjectFactoryImplBase.init(JavaPropertyValueObjectFactory.java:214) at org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory$ObjectFactoryImpl.init(JavaPropertyValueObjectFactory.java:221) at org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory.createValueFactory(JavaPropertyValueObjectFactory.java:123) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.processProperties(OSGiImplementationProvider.java:210) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.setReferencesAndProperties(OSGiImplementationProvider.java:1143) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.start(OSGiImplementationProvider.java:1150) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:631) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:245) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113) Tests in error: testOSGiComponent(org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTestCase) testOSGiComponent(org.apache.tuscany.sca.implementation.osgi.invocation.OSGiPropertyTestCase) Tests run: 5, Failures: 0, Errors: 2, Skipped: 0 -- Thanks Regards, Ramkumar Ramalingam
Re: [NOTICE] Scott Kurz voted as Tuscany committer
Congrats Scott ! -- Thanks Regards, Ramkumar Ramalingam
Re: Validation Exceptions was: Re: TUSCANY-2277 validation messages
Hi Simon,
I believe both the DefaultMonitorImpl and DefaultLoggingMonitorImpl would
need this change in them and also believe that any new monitor
implementation should follow the same.
The reason why I feel so is that, our aim of blocking the exception from
the code is to collect as many user-input errors from various processors.
And at the later stage our runtime should have a provision to take a
revision on these reported issues from the monitor and decide if the furthur
processing can be carried out or not.
Currently I have made the changes in both the modules, please let me know
your thoughts on this.
+1 for the change in module name as monitor-cache.
Also I noticed that, when a warning/error message is thrown from the
monitor, for most of the instance it does not show the sourceClassName where
it originated from. Hence I believe a change is also required in the way we
log something like this.
problemLogger.logp(Level.SEVERE, problem.getSourceClassName(),
null, problem.getMessageId(),
problem.getMessageParams());
Please let me know your thoughts on this. Thanks.
On 6/6/08, Simon Laws [EMAIL PROTECTED] wrote:
On Fri, Jun 6, 2008 at 1:35 PM, Ramkumar R [EMAIL PROTECTED] wrote:
Hi Simon,
After disabling most of the exceptions, now i face a problem in the itest
validations as we generally check for the last reported problem to verify
the results. Now due to disabled exception the processing continues
furthur
and more problems are reported even after the one we are expecting.
Hence the getLastLoggedProblem method in the monitor does not help us
anymore.
I have now introduced a HashMap in the monitor to cache all the problem
reported, so that we could analyze them and see if the expected errors
are
reported. Here is the piece of code that is being added in the monitor
now.
// Cache all the problem reported to monitor for furthur analysis
private MapString, Problem problemCache = new HashMapString,
Problem();
public boolean isMessageLogged(String messageId) {
if (problemCache.containsKey(messageId)) return true;
else return false;
}
Like to know your thoughts on it. Thanks.
On 6/6/08, Ramkumar R [EMAIL PROTECTED] wrote:
On 6/5/08, Simon Laws [EMAIL PROTECTED] wrote:
Here the processor would never throw ContributionReadException, when
the
exceptions are blocked as most of the ContributionReadException are
of
type1, 2 or 3.
Do you mean type 2, 3 4 here. I still expect us to throw type 1
exceptions.
Hi Simon,
You are right, i meant it to be type 2, 3 4 exceptions here. Sorry
for
the typo error.
--
Thanks Regards,
Ramkumar Ramalingam
--
Thanks Regards,
Ramkumar Ramalingam
Hi Ram
Sounds like a good idea. Was this added to DefaultMonitorImpl or
DefaultLoggingMonitorImpl?
Now that we have a default monitor that logs messages and is used if no
extension monitor is provided the name of the monitor-logging module looks
out of place. I'd like to rename that to be something like monitor-caching
or something similar so that your new map can go there. If people don't
want
to store up monitor messages they can just drop out that module and either
fall back to the default implementation or provide their own. Does that
sound sensible?
If so feel free to go ahead and make the code changes. If you create a new
monitor module with a suitable name I'll add the new one and delete the old
one. Don't worry about doing a patch for the rename as I imagine that could
get tricky.
Simon
--
Thanks Regards,
Ramkumar Ramalingam
Re: Build error in modules/implementation/osgi tests
Please ignore the above said issue... this worked. Was my mistake with my local respository. But I face a OutofMemory exception with itest/osgi-implementation, for which i like to post it in a seperate thread. On 6/9/08, Ramkumar R [EMAIL PROTECTED] wrote: I am seeing JUnit test failures in modules/implementation/osgi. Is anyone else also noticing the same? Using default configuration properties. Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.432 sec FAILURE! testOSGiComponent(org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTestCase) Time elapsed: 1.422 sec ERROR! java.lang.NoSuchMethodError: org/apache/tuscany/sca/databinding/DataBindingExtensionPoint.introspectType(Lorg/apache/tuscany/sca/interfacedef/DataType;[Ljava/lang/annotation/Annotation;)Z at org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory$ObjectFactoryImplBase.init(JavaPropertyValueObjectFactory.java:214) at org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory$ObjectFactoryImpl.init(JavaPropertyValueObjectFactory.java:221) at org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory.createValueFactory(JavaPropertyValueObjectFactory.java:123) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.processProperties(OSGiImplementationProvider.java:210) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.setReferencesAndProperties(OSGiImplementationProvider.java:1143) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.start(OSGiImplementationProvider.java:1150) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:631) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:245) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113) Using default configuration properties. Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.591 sec FAILURE! testOSGiComponent(org.apache.tuscany.sca.implementation.osgi.invocation.OSGiPropertyTestCase) Time elapsed: 0.571 sec ERROR! java.lang.NoSuchMethodError: org/apache/tuscany/sca/databinding/DataBindingExtensionPoint.introspectType(Lorg/apache/tuscany/sca/interfacedef/DataType;[Ljava/lang/annotation/Annotation;)Z at org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory$ObjectFactoryImplBase.init(JavaPropertyValueObjectFactory.java:214) at org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory$ObjectFactoryImpl.init(JavaPropertyValueObjectFactory.java:221) at org.apache.tuscany.sca.implementation.java.injection.JavaPropertyValueObjectFactory.createValueFactory(JavaPropertyValueObjectFactory.java:123) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.processProperties(OSGiImplementationProvider.java:210) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.setReferencesAndProperties(OSGiImplementationProvider.java:1143) at org.apache.tuscany.sca.implementation.osgi.invocation.OSGiImplementationProvider.start(OSGiImplementationProvider.java:1150) at org.apache.tuscany.sca.core.assembly.CompositeActivatorImpl.start(CompositeActivatorImpl.java:631) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:245) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113) Tests in error: testOSGiComponent(org.apache.tuscany.sca.implementation.osgi.invocation.OSGiTestCase) testOSGiComponent(org.apache.tuscany.sca.implementation.osgi.invocation.OSGiPropertyTestCase) Tests run: 5, Failures: 0, Errors: 2, Skipped: 0 -- Thanks Regards, Ramkumar Ramalingam -- Thanks Regards, Ramkumar Ramalingam
OutOfMemoryError in itest/osgi-implementation conversation testcases
I see a OutOfMemoryError in itest/osgi-implementation conversation testcases, and a serious of testcases fails with the following exception. Can anyone help me in identifying the issue here. Thanks. testStatelessStatefulConversationCallingEndedConversationCallback(conversation.ConversationTestCase) Time elapsed: 1.843 sec ERROR! java.lang.OutOfMemoryError at com.ibm.oti.vm.VM.initializeClassLoader(Native Method) at java.lang.ClassLoader.init(ClassLoader.java:111) at java.security.SecureClassLoader.init(SecureClassLoader.java:75) at org.apache.tuscany.sca.interfacedef.java.jaxws.GeneratedClassLoader.init(GeneratedClassLoader.java:49) at org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessor$2.run(JAXWSJavaInterfaceProcessor.java:238) at org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessor$2.run(JAXWSJavaInterfaceProcessor.java:229) at java.security.AccessController.doPrivileged(AccessController.java:197) at org.apache.tuscany.sca.interfacedef.java.jaxws.JAXWSJavaInterfaceProcessor.visitInterface(JAXWSJavaInterfaceProcessor.java:228) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceIntrospectorImpl.introspectInterface(JavaInterfaceIntrospectorImpl.java:121) at org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceFactoryImpl.createJavaInterface(JavaInterfaceFactoryImpl.java:50) at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.createService(OSGiImplementationProcessor.java:340) at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:286) at org.apache.tuscany.sca.implementation.osgi.xml.OSGiImplementationProcessor.resolve(OSGiImplementationProcessor.java:78) at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:364) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:170) at org.apache.tuscany.sca.assembly.xml.BaseAssemblyProcessor.resolveImplementation(BaseAssemblyProcessor.java:301) at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:901) at org.apache.tuscany.sca.assembly.xml.CompositeProcessor.resolve(CompositeProcessor.java:87) at org.apache.tuscany.sca.contribution.processor.DefaultStAXArtifactProcessorExtensionPoint$LazyStAXArtifactProcessor.resolve(DefaultStAXArtifactProcessorExtensionPoint.java:364) at org.apache.tuscany.sca.contribution.processor.ExtensibleStAXArtifactProcessor.resolve(ExtensibleStAXArtifactProcessor.java:170) at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:164) at org.apache.tuscany.sca.assembly.xml.CompositeDocumentProcessor.resolve(CompositeDocumentProcessor.java:56) at org.apache.tuscany.sca.contribution.processor.ExtensibleURLArtifactProcessor.resolve(ExtensibleURLArtifactProcessor.java:106) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.processResolvePhase(ContributionServiceImpl.java:528) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.addContribution(ContributionServiceImpl.java:394) at org.apache.tuscany.sca.contribution.service.impl.ContributionServiceImpl.contribute(ContributionServiceImpl.java:187) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain$3.run(DefaultSCADomain.java:296) at java.security.AccessController.doPrivileged(AccessController.java:241) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.addContribution(DefaultSCADomain.java:294) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:171) at org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.init(DefaultSCADomain.java:113) at org.apache.tuscany.sca.host.embedded.SCADomain.createNewInstance(SCADomain.java:242) at org.apache.tuscany.sca.host.embedded.SCADomain.newInstance(SCADomain.java:83) at test.OSGiTestCase.setUp(OSGiTestCase.java:58) at conversation.ConversationTestCase.setUp(ConversationTestCase.java:47) at junit.framework.TestCase.runBare(TestCase.java:132) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:35) at
Re: Validation Exceptions was: Re: TUSCANY-2277 validation messages
On 6/5/08, Simon Laws [EMAIL PROTECTED] wrote: Here the processor would never throw ContributionReadException, when the exceptions are blocked as most of the ContributionReadException are of type1, 2 or 3. Do you mean type 2, 3 4 here. I still expect us to throw type 1 exceptions. Hi Simon, You are right, i meant it to be type 2, 3 4 exceptions here. Sorry for the typo error. -- Thanks Regards, Ramkumar Ramalingam
Re: Validation Exceptions was: Re: TUSCANY-2277 validation messages
Hi Simon,
After disabling most of the exceptions, now i face a problem in the itest
validations as we generally check for the last reported problem to verify
the results. Now due to disabled exception the processing continues furthur
and more problems are reported even after the one we are expecting.
Hence the getLastLoggedProblem method in the monitor does not help us
anymore.
I have now introduced a HashMap in the monitor to cache all the problem
reported, so that we could analyze them and see if the expected errors are
reported. Here is the piece of code that is being added in the monitor now.
// Cache all the problem reported to monitor for furthur analysis
private MapString, Problem problemCache = new HashMapString, Problem();
public boolean isMessageLogged(String messageId) {
if (problemCache.containsKey(messageId)) return true;
else return false;
}
Like to know your thoughts on it. Thanks.
On 6/6/08, Ramkumar R [EMAIL PROTECTED] wrote:
On 6/5/08, Simon Laws [EMAIL PROTECTED] wrote:
Here the processor would never throw ContributionReadException, when the
exceptions are blocked as most of the ContributionReadException are of
type1, 2 or 3.
Do you mean type 2, 3 4 here. I still expect us to throw type 1
exceptions.
Hi Simon,
You are right, i meant it to be type 2, 3 4 exceptions here. Sorry for
the typo error.
--
Thanks Regards,
Ramkumar Ramalingam
--
Thanks Regards,
Ramkumar Ramalingam
Re: itest/validation problem
Hi Ant, This testcase fails due to an issue that we faced while applying the patch. FYI... This issue is also discussed in the below thread. http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200806.mbox/[EMAIL PROTECTED] Hope to get this resolved soon. On 6/4/08, ant elder [EMAIL PROTECTED] wrote: I'm getting a test fail in itest/validation with the failed test: testCalculator(impl.resource.CouldNotResolveLocationTestCase). Does this work or fail for anyone else? ...ant -- Thanks Regards, Ramkumar Ramalingam
Re: ExtensibleStAXArtifactProcessor should register error when unsupported implementation or binding types are found
Hi Hasan, The ideal place to catch these exceptions seems to be in the ExtensibleStAXArtifactProcessor read method, i think it would not be possible to categorize the exception based on implementation and binding at this stage. I believe it would be possible to throw a generic exception saying that this element is not supported by the runtime as it does not have a suitable processor to proceed. Let me know your say on this. Thanks. On 6/3/08, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, I have raised JIRA 2365 to address this issue. regards Hasan -- Thanks Regards, Ramkumar Ramalingam
Re: Splitting binding and impl models and runtimes
Hi Sebastien, One thing that comes to my mind is about the JavaRuntimeModuleActivator that also needs some modularization as we were discussing upon them some time back. For your reference: On 5/29/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: JavRuntimeModuleActivator is responsible for setting up the Java component implementation runtime, allowing you to activate Java component instances and dispatch to invocations from/to them. In theory it should be possible to initialize the model, XML reader, and introspection layers without bringing up the runtime layer. Unfortunately it's probably not possible at the moment as the implementation-java-* modules do not follow a clean layering... and mash everything up starting in JavaRuntimeModuleActivator. So to summarize: - JavaRuntimeModuleActivator mashes way too much together and should be modularized Thanks. On 6/3/08, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: I'm starting to split some of the binding and implementation models in separate modules, to allow their models to be used without dragging their runtime dependencies. We've already done that on a number of them, I'm going to follow the same pattern for the following modules as well: - implementation-widget - implementation-resource - binding-http - binding-ejb - binding-jsonrpc This shouldn't break existing code as APIs/SPIs won't change. If there's no objections I'll commit these changes later this week. -- Jean-Sebastien -- Thanks Regards, Ramkumar Ramalingam
Re: ExtensibleStAXArtifactProcessor should register error when unsupported implementation or binding types are found
I have cancelled this JIRA. On 6/4/08, Hasan Muhammad [EMAIL PROTECTED] wrote: On second thoughts.. there is no point of this JIRA if a categorized error message cannot be logged at this point.. If we do log a warning that an unrecognized element has been encountered, then it will have to be it. Nothing more useful can be done if it is not categorized.. You can cancel this JIRA. On Wed, Jun 4, 2008 at 10:10 AM, Raymond Feng [EMAIL PROTECTED] wrote: I believe that we log a warning that an unknown element is encountered. Isn't it sufficient? Thanks, Raymond -- From: Ramkumar R [EMAIL PROTECTED] Sent: Wednesday, June 04, 2008 4:37 AM To: tuscany-dev@ws.apache.org Subject: Re: ExtensibleStAXArtifactProcessor should register error when unsupported implementation or binding types are found Hi Hasan, The ideal place to catch these exceptions seems to be in the ExtensibleStAXArtifactProcessor read method, i think it would not be possible to categorize the exception based on implementation and binding at this stage. I believe it would be possible to throw a generic exception saying that this element is not supported by the runtime as it does not have a suitable processor to proceed. Let me know your say on this. Thanks. On 6/3/08, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, I have raised JIRA 2365 to address this issue. regards Hasan -- Thanks Regards, Ramkumar Ramalingam -- Thanks Regards, Ramkumar Ramalingam
Re: Where can i find xsds for implementation.das?
Thanks Luciano, you can count on me if i can help in creating one with your guidance. On 6/2/08, Luciano Resende [EMAIL PROTECTED] wrote: We would have to create one. Let me try to help you and see if I can get one available soon. On Mon, Jun 2, 2008 at 3:26 AM, Ramkumar R [EMAIL PROTECTED] wrote: While I have been working on introducing monitors to various processors across modules, I came across an instance where the DASImplementationProcessor.java (part of implementation.das module) does not provide proper validation messages when the required attributes are missing. Most of the time, the schema helps in identifying the required/optional attributes in the XML. Since i could not find a schema for implementation.das and implementation.data.xml, I found it difficult to put up some validation for these modules. Can anyone help me with the schema for these modules? Thanks. On 5/30/08, Ramkumar R [EMAIL PROTECTED] wrote: Not able to find an xsd for implementation.das and implementation.data.xml module from assembly-xsd/src/main/resources folder. Not sure if there is any reason why we don't have an xsd for these? Can anyone guide me on this? Thanks. -- Thanks Regards, Ramkumar Ramalingam -- Thanks Regards, Ramkumar Ramalingam -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/ -- Thanks Regards, Ramkumar Ramalingam
Re: TUSCANY-2344 5 - resource widget validation
Hi Luciano,
I tried with the latest code, it looks
like testCalculator(impl.resource.CouldNotResolveLocationTestCase) is
failing again due to the same issue we saw with the earlier patch. But this
time itest for implementation.widget is sucessfull as the patch for
WidgetImplementationProcessor.java got applied appropriately.
Again i could see that the patch is not fully applied
to ResourceImplementationProcessor.java file. I could see the patch file
showing the necessary changes, but could not find them in the
committed code.
Not sure if the patch files that I am creating has some issues here OR is
something going wrong while the patches are being applied. I would recommend
to verify the same and let me know if any corrections are needed from my
side.
On 6/3/08, Luciano Resende [EMAIL PROTECTED] wrote:
Hi Ram
I have just applied the TUSCANY-2362 patch. Could you please take a
quick look as I was having issues trying to get a sucessful run of the
validation iTest bucket, but I guess it's due to different issues.
Thanks
On Mon, Jun 2, 2008 at 3:18 AM, Simon Laws [EMAIL PROTECTED]
wrote:
On Mon, Jun 2, 2008 at 11:15 AM, Ramkumar R [EMAIL PROTECTED]
wrote:
Hi Simon,
I have provided the fix with TUSCANY-2362 for the same.
For Junit4, let me have a look and provide the changes accordingly.
On 6/2/08, Simon Laws [EMAIL PROTECTED] wrote:
On Mon, Jun 2, 2008 at 8:14 AM, Ramkumar R [EMAIL PROTECTED]
wrote:
Hi Simon,
After downloading the complete latest code from the repository, i
noticed
that the reason for the failure in CouldNotResolveLocation for
implementation.resource and implementation.widget validation is due
to
the
missed code while applying the patch.
The changes suggested in the patch does not seem to appear in the
committed
code. For instance TUSCANY-2344 suggested a change in
WidgetImplementationProcessor resolve method as shown below, which
is
required for the tests to be sucessfull.
while (reader.hasNext()) {
@@ -128,8 +149,11 @@
} catch (IOException e) {
ContributionResolveException ce = new
ContributionResolveException(e);
error(ContributionResolveException, resolver, ce);
- throw ce;
+ //throw ce;
}
+} else {
+error(CouldNotResolveLocation, resolver,
implementation.getLocation());
+//throw new ContributionResolveException(Could not
resolve
implementation.widget location: + implementation.getLocation());
}
Not sure, if i should open a new JIRA OR reopen the older ones to
apply
the
patch again. Please suggest.
Also would be helpful if you could elobrate more about the
conversion
of
tests to JUnit4. Thakns.
On 5/29/08, Simon Laws [EMAIL PROTECTED] wrote:
Hi
FYI. I've seen a couple of problems with the widget and resource
validation
testing during may latest build. CouldNotResolveLocation doesn't
seem
to
be
raise. I've @Ignored these tests for now just in case it's going
to
affect
others (I changed the test to JUnit4 to make this easy) .
As an aside we should probably go through these tests and convert
to
Junit4
Also I notice that the original tests I added don't fit into the
neat
categorization scheme that has been used subsequently so I'll
endeavor
to
move the original tests into the new scheme to tidy things up.
Simon
--
Thanks Regards,
Ramkumar Ramalingam
Hi Ram
Can you identify which parts of the patch are missing and create a new
patch
based on just these. As they didn't apply properly in the first place
I
don't think that trying to apply the existing patch again will have
the
desired effect.
Re. Junit4. Some of our tests in Tuscany use JUnit4 and some of them
use
older versions of JUnit. As we are creating new tests here it would be
convenient to use the latest version of JUnit.
Regards
Simon
--
Thanks Regards,
Ramkumar Ramalingam
Hi Ram
Thanks for that. The JUnit4 thing is not an emergency. As we create new
tests we can use JUnit4
Simon
--
Luciano Resende
Apache Tuscany Committer
http://people.apache.org/~lresende
http://lresende.blogspot.com/
--
Thanks Regards,
Ramkumar Ramalingam
Re: [NOTICE] Vamsavardhana Reddy voted as Tuscany committer
Congrats Vamsi!. On 6/3/08, Vamsavardhana Reddy [EMAIL PROTECTED] wrote: Hi Ant, Forgot to mention in my previous note... I accept Tuscany PMC's invitation to me to become a committer :) I already have a signed ICLA in place. My JIRA userid is vamsic. My Apache userid is vamsic007. Please add my id to the required groups so that I get the necessary permissions. Thanks and best regards, Vamsi On Mon, Jun 2, 2008 at 11:32 PM, ant elder [EMAIL PROTECTED] wrote: The Tuscany PMC has voted for Vamsavardhana Reddy to become a Tuscany committer. Congratulations and welcome! ...ant -- Thanks Regards, Ramkumar Ramalingam
Re: Validation Exceptions was: Re: TUSCANY-2277 validation messages
On 6/3/08, Simon Laws [EMAIL PROTECTED] wrote: How do we define the processor code? Here are a couple of examples. From stax artifact processor. M read(XMLStreamReader reader) throws ContributionReadException, XMLStreamException; From composite builder void build(Composite composite) throws CompositeBuilderException; I like the idea of saying NEVER throw an exception but this has to be restricted to well defined processing steps, e.g. those that and extension writer would author (Read, Write, Resolve). As an alternative and in order to maintain the current API such exceptions could be captured in the ExtensibleStAXArtifactProcessor. Hi Simon, Initially our idea was to disable most of the exception throws from the processors and log the warnings/exception via the monitors. Lets say we might still leave some exceptions to be thrown like the type1 exceptions, in such cases me might end up only throwing IOExceptions / XMLStreamExceptions. From stax artifact processor. M read(XMLStreamReader reader) throws ContributionReadException, XMLStreamException; Here the processor would never throw ContributionReadException, when the exceptions are blocked as most of the ContributionReadException are of type1, 2 or 3. Do you believe we should maintain the current API in such cases? -- Thanks Regards, Ramkumar Ramalingam
Re: TUSCANY-2344 5 - resource widget validation
Hi Simon,
After downloading the complete latest code from the repository, i noticed
that the reason for the failure in CouldNotResolveLocation for
implementation.resource and implementation.widget validation is due to the
missed code while applying the patch.
The changes suggested in the patch does not seem to appear in the committed
code. For instance TUSCANY-2344 suggested a change in
WidgetImplementationProcessor resolve method as shown below, which is
required for the tests to be sucessfull.
while (reader.hasNext()) {
@@ -128,8 +149,11 @@
} catch (IOException e) {
ContributionResolveException ce = new
ContributionResolveException(e);
error(ContributionResolveException, resolver, ce);
- throw ce;
+ //throw ce;
}
+} else {
+error(CouldNotResolveLocation, resolver,
implementation.getLocation());
+//throw new ContributionResolveException(Could not resolve
implementation.widget location: + implementation.getLocation());
}
Not sure, if i should open a new JIRA OR reopen the older ones to apply the
patch again. Please suggest.
Also would be helpful if you could elobrate more about the conversion of
tests to JUnit4. Thakns.
On 5/29/08, Simon Laws [EMAIL PROTECTED] wrote:
Hi
FYI. I've seen a couple of problems with the widget and resource validation
testing during may latest build. CouldNotResolveLocation doesn't seem to be
raise. I've @Ignored these tests for now just in case it's going to affect
others (I changed the test to JUnit4 to make this easy) .
As an aside we should probably go through these tests and convert to Junit4
Also I notice that the original tests I added don't fit into the neat
categorization scheme that has been used subsequently so I'll endeavor to
move the original tests into the new scheme to tidy things up.
Simon
--
Thanks Regards,
Ramkumar Ramalingam
Re: Where can i find xsds for implementation.das?
While I have been working on introducing monitors to various processors across modules, I came across an instance where the DASImplementationProcessor.java (part of implementation.das module) does not provide proper validation messages when the required attributes are missing. Most of the time, the schema helps in identifying the required/optional attributes in the XML. Since i could not find a schema for implementation.das and implementation.data.xml, I found it difficult to put up some validation for these modules. Can anyone help me with the schema for these modules? Thanks. On 5/30/08, Ramkumar R [EMAIL PROTECTED] wrote: Not able to find an xsd for implementation.das and implementation.data.xml module from assembly-xsd/src/main/resources folder. Not sure if there is any reason why we don't have an xsd for these? Can anyone guide me on this? Thanks. -- Thanks Regards, Ramkumar Ramalingam -- Thanks Regards, Ramkumar Ramalingam
Re: TUSCANY-2344 5 - resource widget validation
Hi Simon,
I have provided the fix with TUSCANY-2362 for the same.
For Junit4, let me have a look and provide the changes accordingly.
On 6/2/08, Simon Laws [EMAIL PROTECTED] wrote:
On Mon, Jun 2, 2008 at 8:14 AM, Ramkumar R [EMAIL PROTECTED] wrote:
Hi Simon,
After downloading the complete latest code from the repository, i noticed
that the reason for the failure in CouldNotResolveLocation for
implementation.resource and implementation.widget validation is due to
the
missed code while applying the patch.
The changes suggested in the patch does not seem to appear in the
committed
code. For instance TUSCANY-2344 suggested a change in
WidgetImplementationProcessor resolve method as shown below, which is
required for the tests to be sucessfull.
while (reader.hasNext()) {
@@ -128,8 +149,11 @@
} catch (IOException e) {
ContributionResolveException ce = new
ContributionResolveException(e);
error(ContributionResolveException, resolver, ce);
- throw ce;
+ //throw ce;
}
+} else {
+error(CouldNotResolveLocation, resolver,
implementation.getLocation());
+//throw new ContributionResolveException(Could not resolve
implementation.widget location: + implementation.getLocation());
}
Not sure, if i should open a new JIRA OR reopen the older ones to apply
the
patch again. Please suggest.
Also would be helpful if you could elobrate more about the conversion of
tests to JUnit4. Thakns.
On 5/29/08, Simon Laws [EMAIL PROTECTED] wrote:
Hi
FYI. I've seen a couple of problems with the widget and resource
validation
testing during may latest build. CouldNotResolveLocation doesn't seem
to
be
raise. I've @Ignored these tests for now just in case it's going to
affect
others (I changed the test to JUnit4 to make this easy) .
As an aside we should probably go through these tests and convert to
Junit4
Also I notice that the original tests I added don't fit into the neat
categorization scheme that has been used subsequently so I'll endeavor
to
move the original tests into the new scheme to tidy things up.
Simon
--
Thanks Regards,
Ramkumar Ramalingam
Hi Ram
Can you identify which parts of the patch are missing and create a new
patch
based on just these. As they didn't apply properly in the first place I
don't think that trying to apply the existing patch again will have the
desired effect.
Re. Junit4. Some of our tests in Tuscany use JUnit4 and some of them use
older versions of JUnit. As we are creating new tests here it would be
convenient to use the latest version of JUnit.
Regards
Simon
--
Thanks Regards,
Ramkumar Ramalingam
Where can i find xsds for implementation.das?
Not able to find an xsd for implementation.das and implementation.data.xml module from assembly-xsd/src/main/resources folder. Not sure if there is any reason why we don't have an xsd for these? Can anyone guide me on this? Thanks. -- Thanks Regards, Ramkumar Ramalingam
Re: Problem seen in Policy Processors
After doing a complete debug of the code, realized that this seems to be an
issue and we need a fix here.
I will be opening a JIRA to fix this.
On 5/29/08, Ramkumar R [EMAIL PROTECTED] wrote:
For creating an itests for the validation messages, it was a requirement to
reproduce all kind of exceptions thrown from various processors in the
runtime. I came across this issue of unreachable code in the policy
processors (especially in PolicyIntentProcessor.java and
PolicySetProcessor.java). Here is the piece of code from
resolveProfileIntent method of PolicyIntentProcessor.java to explain.
for (Intent requiredIntent : policyIntent.getRequiredIntents()) {
if (requiredIntent.isUnresolved()) {
Intent resolvedRequiredIntent = resolver.resolveModel(Intent.class,
requiredIntent);
if (resolvedRequiredIntent != null) {
requiredIntents.add(resolvedRequiredIntent);
} else {
error(RequiredIntentNotFound, resolver, requiredIntent,
policyIntent);
throw new ContributionResolveException(Required Intent - +
requiredIntent
+ not found for ProfileIntent
+ policyIntent);
}
} else {
requiredIntents.add(requiredIntent);
}
}
Here the resolver.resolveModel does not seem to return null in any case,
what happens is if the resolver is unable to resolve the model it just
returns the unresolved model. So the if condition checking for
resolvedRequiredIntent for null never fails and the later part of the code
in the else condition is never reached.
Similarly, there are 6 places (including the above said) where this kind of
issue is noticed, where the code is failing to throw the following
exceptions.
ExcludedIntentNotFound
QualifiableIntentNotFound
RequiredIntentNotFound
ReferredPolicySetNotFound
MappedIntentNotFound
ProvidedIntentNotFound
To overcome this situation, i just tried modifying the code to look like
this and it seems to be working for me.
Intent resolvedRequiredIntent = resolver.resolveModel(Intent.class,
requiredIntent);
if (!resolvedRequiredIntent.isUnresolved()) {
requiredIntents.add(resolvedRequiredIntent);
} else {
error(RequiredIntentNotFound, resolver, requiredIntent, policyIntent);
throw new ContributionResolveException(Required Intent - +
requiredIntent
+
not found for ProfileIntent
+
policyIntent);
}
Like to take help from someone, to know if this is really an issue that i
am noticing OR did i just overlook at the code.
If its really an issue, can i raise a JIRA to fix this. Thanks.
--
Thanks Regards,
Ramkumar Ramalingam
--
Thanks Regards,
Ramkumar Ramalingam
Re: Problem seen in Policy Processors
I have opened TUSCANY-2354 to fix this issue.
On 5/30/08, Ramkumar R [EMAIL PROTECTED] wrote:
After doing a complete debug of the code, realized that this seems to be an
issue and we need a fix here.
I will be opening a JIRA to fix this.
On 5/29/08, Ramkumar R [EMAIL PROTECTED] wrote:
For creating an itests for the validation messages, it was a requirement
to reproduce all kind of exceptions thrown from various processors in the
runtime. I came across this issue of unreachable code in the policy
processors (especially in PolicyIntentProcessor.java and
PolicySetProcessor.java). Here is the piece of code from
resolveProfileIntent method of PolicyIntentProcessor.java to explain.
for (Intent requiredIntent : policyIntent.getRequiredIntents()) {
if (requiredIntent.isUnresolved()) {
Intent resolvedRequiredIntent = resolver.resolveModel(Intent.class,
requiredIntent);
if (resolvedRequiredIntent != null) {
requiredIntents.add(resolvedRequiredIntent);
} else {
error(RequiredIntentNotFound, resolver, requiredIntent,
policyIntent);
throw new ContributionResolveException(Required Intent - +
requiredIntent
+ not found for ProfileIntent
+ policyIntent);
}
} else {
requiredIntents.add(requiredIntent);
}
}
Here the resolver.resolveModel does not seem to return null in any case,
what happens is if the resolver is unable to resolve the model it just
returns the unresolved model. So the if condition checking for
resolvedRequiredIntent for null never fails and the later part of the code
in the else condition is never reached.
Similarly, there are 6 places (including the above said) where this kind
of issue is noticed, where the code is failing to throw the following
exceptions.
ExcludedIntentNotFound
QualifiableIntentNotFound
RequiredIntentNotFound
ReferredPolicySetNotFound
MappedIntentNotFound
ProvidedIntentNotFound
To overcome this situation, i just tried modifying the code to look like
this and it seems to be working for me.
Intent resolvedRequiredIntent = resolver.resolveModel(Intent.class,
requiredIntent);
if (!resolvedRequiredIntent.isUnresolved()) {
requiredIntents.add(resolvedRequiredIntent);
} else {
error(RequiredIntentNotFound, resolver, requiredIntent,
policyIntent);
throw new ContributionResolveException(Required Intent - +
requiredIntent
+
not found for ProfileIntent
+
policyIntent);
}
Like to take help from someone, to know if this is really an issue that i
am noticing OR did i just overlook at the code.
If its really an issue, can i raise a JIRA to fix this. Thanks.
--
Thanks Regards,
Ramkumar Ramalingam
--
Thanks Regards,
Ramkumar Ramalingam
--
Thanks Regards,
Ramkumar Ramalingam
Problem seen in Policy Processors
For creating an itests for the validation messages, it was a requirement to
reproduce all kind of exceptions thrown from various processors in the
runtime. I came across this issue of unreachable code in the policy
processors (especially in PolicyIntentProcessor.java and
PolicySetProcessor.java). Here is the piece of code from
resolveProfileIntent method of PolicyIntentProcessor.java to explain.
for (Intent requiredIntent : policyIntent.getRequiredIntents()) {
if (requiredIntent.isUnresolved()) {
Intent resolvedRequiredIntent = resolver.resolveModel(Intent.class,
requiredIntent);
if (resolvedRequiredIntent != null) {
requiredIntents.add(resolvedRequiredIntent);
} else {
error(RequiredIntentNotFound, resolver, requiredIntent,
policyIntent);
throw new ContributionResolveException(Required Intent - +
requiredIntent
+ not found for ProfileIntent
+ policyIntent);
}
} else {
requiredIntents.add(requiredIntent);
}
}
Here the resolver.resolveModel does not seem to return null in any case,
what happens is if the resolver is unable to resolve the model it just
returns the unresolved model. So the if condition checking for
resolvedRequiredIntent for null never fails and the later part of the code
in the else condition is never reached.
Similarly, there are 6 places (including the above said) where this kind of
issue is noticed, where the code is failing to throw the following
exceptions.
ExcludedIntentNotFound
QualifiableIntentNotFound
RequiredIntentNotFound
ReferredPolicySetNotFound
MappedIntentNotFound
ProvidedIntentNotFound
To overcome this situation, i just tried modifying the code to look like
this and it seems to be working for me.
Intent resolvedRequiredIntent = resolver.resolveModel(Intent.class,
requiredIntent);
if (!resolvedRequiredIntent.isUnresolved()) {
requiredIntents.add(resolvedRequiredIntent);
} else {
error(RequiredIntentNotFound, resolver, requiredIntent, policyIntent);
throw new ContributionResolveException(Required Intent - +
requiredIntent
+ not
found for ProfileIntent
+
policyIntent);
}
Like to take help from someone, to know if this is really an issue that i am
noticing OR did i just overlook at the code.
If its really an issue, can i raise a JIRA to fix this. Thanks.
--
Thanks Regards,
Ramkumar Ramalingam
Re: [jira] Assigned: (TUSCANY-2347) Removing the exception throws from the processors
Hi Mike, Thanks for raising this, I believe we need more detailed discussion on this topic with the community and its important that we all agree upon. Simon has started a new thread in the ML to discuss about this and here is the link to same... http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200805.mbox/[EMAIL PROTECTED] You can find more detailed discussion about this topic happening here. Thanks. On 5/28/08, Mike Edwards [EMAIL PROTECTED] wrote: Ramkumar, Is this such a wise move?? What is the point of allowing processing to continue if the model is actually broken in some way? I would agree that there may be some exceptions that can be removed and replaced by the logging of messages, but is it really wise to allow the creation of a model that is broken in some important features? Yours, Mike. Ramkumar Ramalingam (JIRA) wrote: [ https://issues.apache.org/jira/browse/TUSCANY-2347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel] Ramkumar Ramalingam reassigned TUSCANY-2347: Assignee: Ramkumar Ramalingam Removing the exception throws from the processors - Key: TUSCANY-2347 URL: https://issues.apache.org/jira/browse/TUSCANY-2347 Project: Tuscany Issue Type: Bug Components: Java SCA Core Runtime Affects Versions: Java-SCA-Next Environment: Windows XP, Reporter: Ramkumar Ramalingam Assignee: Ramkumar Ramalingam Fix For: Java-SCA-Next After introducing the monitors in various part of the code (especially in the processors), while the runtime reads and resolves the contribution. Now we are trying to remove the exception that are being thrown from these modules. As a first step we are removing the exceptions that are safe to remove, by leaving the critical exceptions like a) IOException b) XMLStreamException c) PriviledegedActionException d) and ParseConfigurationExceptions As a second step, we will also be dealing with the above said exception once we have a detailed discussion as how to handle them. -- Thanks Regards, Ramkumar Ramalingam
Re: Validation Exceptions was: Re: TUSCANY-2277 validation messages
Hi Simon,
Thanks for summarizing. You are right, currently i am working on to disable
type 3 4 exceptions to allow the runtime to catch the maximum number of
user-input errors that can be reported in one-go. I don't see much issue in
disabling such exceptions as they are mostly harmless for the furthur
processing code. Here is an example from
binding.jms/JMSBindingProcessor.java parseResponseActivationSpec method for
the same.
String name = reader.getAttributeValue(null, name);
if (name != null name.length() 0) {
jmsBinding.setResponseActivationSpecName(name);
warning(DoesntProcessResponseActivationSpec, jmsBinding);
//System.err.println(JMS Binding doesn't process response activationSpec
yet);
} else {
warning(MissingResponseActivationSpec, reader);
//throw new RuntimeException(missing response ActivationSpec name);
}
Here we are sure that we are not yet processing the response activationSpec,
so we have now converted the RuntimeException as a warning message when the
name attribute is missing for the response activationSpec.
Talking about type 2 exceptions, i should say that i did some investigation
and tried to disable them basically by two ways.
a) In the processor read method, we return null after disabling the
exception if the processor ends up with type 2 exceptions.
b) In the processor resolve method, we simply return the method by saying
that we have not yet resolved the model by setting the isUnresolved=true.
I believe disabling type 2 exceptions need a careful dealing by having an
itest and make sure that we are not missing anything, that could lead to
furthur problems.
*NOTE:* For all the type 2 exceptions that are blocked, I believe we need to
make sure that the runtime should investigate the monitor messages after
reading and resolving the contribution and make sure that things are safe to
proceed furthur for building the composite.
Talking about type 1 exceptions, I believe we are still throwing the
exceptions as it is and this would the right approach to do so. Not sure if
there could be any good ways to disable them. Please let me know if any one
has thoughts on this.
Any comments/suggestions would help to improve the way we are trying to
handle this. Thanks.
On 5/29/08, Simon Laws [EMAIL PROTECTED] wrote:
On Wed, May 28, 2008 at 12:08 PM, Ramkumar R [EMAIL PROTECTED]
wrote:
Hi Simon,
After introducing the monitors in various part of the code. Now I am
trying
to remove the exception that are being thrown from these modules. As a
first
step we are removing the exceptions that are safe to remove, by leaving
the
critical exceptions like
a) IOException
b) XMLStreamException
c) PriviledegedActionException
d) and ParseConfigurationExceptions
For the above said exceptions, we need some discussion as how to handle
them.
I have now raised TUSCANY-2347 to address this issue by leaving the above
exceptions to still throw.
snip..
Hi Ram, I want to summarize the process here and make sure we are all on
the
same page. From previous ML discussions we are looking at the case where a
user provides a contribution and we want the Tuscany runtime to have the
flexibility to report as many validation exceptions as it can up front
rather than just reporting the first one.
So far the validation code has been changed so that..
A - error and warning messages have been associated with a unique ID and
have been moved into resource bundles
B - the monitor has been flowed down into the various processing objects
C - validation errors or warnings are now logged to the monitor using the
unique message ID
This leaves the validation code still throwing exceptions all over the
place. These exceptions are a mixture of things.
1 - Fundamental exceptions, such as IOException, that mean that any
subsequent processing would cause problems
2 - Validation exceptions that mean that subsequent processing would cause
problems
3 - Validation exceptions that mean that subsequent processing can continue
allowing further validation exceptions to be captured. There are probably
several levels of this, e.g. stop processing the current component but
other
components can be validated.
4 - Validation exceptions that are really warnings
IIUC you are disabling type 3 and 4 exceptions to allow a greater range of
validation exceptions to be reported before validation processing stops.
What happens with type 1 and 2 exceptions. I assume that validation
processing stops after one of these exceptions. Have you had any thoughts
about how better to categorize and deal with them since your previous
post?
Regards
Simon
--
Thanks Regards,
Ramkumar Ramalingam
Re: TUSCANY-2277 validation messages
Hi Simon, After introducing the monitors in various part of the code. Now I am trying to remove the exception that are being thrown from these modules. As a first step we are removing the exceptions that are safe to remove, by leaving the critical exceptions like a) IOException b) XMLStreamException c) PriviledegedActionException d) and ParseConfigurationExceptions For the above said exceptions, we need some discussion as how to handle them. I have now raised TUSCANY-2347 to address this issue by leaving the above exceptions to still throw. On 5/26/08, Ramkumar R [EMAIL PROTECTED] wrote: Hi Simon, The issue noticed in the CustomDomainBuilder and the test failures occuring from impl.java.ContributionResolveExceptionTestCase are now fixed. I have added the fix as a patch to TUSCANY-2338. The test failure noticed in impl.spring.UnableToResolveComponentTypeTestCase seems to be little complicated, initially though i thought it would be because of CustomDomainBuilder issue. I have posted the issue that i noticed in SpringImplementationProcess, requesting some help for the same. On 5/24/08, Ramkumar R [EMAIL PROTECTED] wrote: Hi Simon, I like to apologize for the inconvenience caused due to the huge patch file for TUSCANY-2329 and for the .pom missed out in the patch. The remaining itests for the validation messages are now available with TUSCANY-2338 along with the fix required for the test failure in interfacejava.xml.ContributionResolveExceptionTestCase. As you mentioned the test failures for impl.spring.UnableToResolveComponentTypeTestCase impl.java.ContributionResolveExceptionTestCase are basically seen due to the issue seen in CustomDomainBuilder failing to add JavaClassVisitors in the runtime. I am doing an investigation on the same to provide a fix. On 5/21/08, Simon Laws [EMAIL PROTECTED] wrote: On Wed, May 21, 2008 at 10:06 AM, Simon Laws [EMAIL PROTECTED] wrote: On Tue, May 20, 2008 at 11:19 AM, Ramkumar R [EMAIL PROTECTED] wrote: Thanks Simon, itests for these validation messages are now available with TUSCANY-2329. On 5/19/08, Simon Laws [EMAIL PROTECTED] wrote: I've just checked in Ram's patch to convert validation messages (i.e. those messages indicating that the user have provided invalid input of some form) to resource bundles and pass them through the Monitor. We need to take account of this change as we change or add code to do with validation. Primarily the change; - Pushes down a Monitor object to various parts of code that produce validation type messages. - Creates a problem object to hold any reported warning or error (sometimes there a convenience error() or warning() operation has been added if there are a lot of messages in a file) -- Each problem is identified by an id string -- The id string references into a resource bundle where the full message has been moved to. There is now a resource bundle in each module that raises validation messages - Passes the Problem on to the Monitor object Our default Monitor object simply passes the message to the JDK logger at the moment but you could imagine a Monitor that collects them all together for later analysis. Currently the majority of the exceptions that are thrown during validation are still there so I guess we need to go through taking out the ones that are not now absolutely necessary. The next job! With this done we have catalogs of all of the errors/warnings that a user is likely to come across (and examples of why the occur in the validation itests) which should help our documentation somewhat. Big thanks to Ram Simon -- Thanks Regards, Ramkumar Ramalingam Hi Ram Thanks for the patch. It was a big one. In the future it would be easier to have smaller committable chunks so we can review as you go;-) I had to fix up the pom file to make it work so maybe that got missed out of the patch. Also, you seem to have you tab key configured to include tabs. In your IDE could you change it to include four spaces instead? I'm going to check these changes in. Now we need to sort out what to do about all of the exceptions that get thrown. I'll remove the validation itests from the build temporarily while we do that. Regards Simon Ok, the tests are checked in now but I had a few problems with some of the tests. I just commented out the assets for the time being. impl.spring.UnableToResolveComponentTypeTestCase impl.java.ContributionResolveExceptionTestCase interfacejava.xml.ContributionResolveExceptionTestCase Also it seems that some of the message conversion till needs to be done, for example, Seems that some of the underlying exceptions/log statements still need converting JavaIntrospectionHelper JavaInterfaceIntrospectorImpl etc. Maybe you fixed these but didn't make a patch
Problem in recreating implementation.spring UnableToResolveComponentType exception
For an itest to validation messages, i was trying to recreate the exception
messages from implementation.spring module reported by
SpringImplementationProcessor.java code. Here is the piece of code from the
resolve method.
/* Load the Spring component type by reading the Spring application context
*/
SpringXMLComponentTypeLoader springLoader = new
SpringXMLComponentTypeLoader(assemblyFactory, javaFactory, policyFactory);
try {
// Load the Spring Implementation information from its application
context file...
springLoader.load(springImplementation);
} catch (ContributionReadException e) {
throw new ContributionResolveException(e);
}
ComponentType ct = springImplementation.getComponentType();
if (ct.isUnresolved()) {
// If the introspection fails to resolve, try to find a side file...
ComponentType componentType = resolver.resolveModel(ComponentType.class,
ct);
if (componentType.isUnresolved()) {
throw new ContributionResolveException(SpringArtifactProcessor:
unable to resolve componentType for Spring component);
}
springImplementation.setComponentType(componentType);
springImplementation.setUnresolved(false);
} // end if
I find the later part of the code trying to throw
ContributionResolveException in its resolve method saying that
SpringArtifactProcessor: unable to resolve componentType for Spring
component, is unreachable, because all the exceptions araising due to a
introspection failure to resolve the component type are caught from the
first ContributionResolveException and thrown.
Can someone help in identifying a scenario to reproduce this second
ContributionResolveException in this code?
--
Thanks Regards,
Ramkumar Ramalingam
Issue faced in creating a subset of Tuscany runtime using domain-management sample
For creating an itests for the validation messages, it was a requirement to create a subset of tuscany runtime to read contribution metadata, analyze and resolve contribution dependencies. To achieve this i just took the code from sample-domain-management to create a CustomDomainBuilder [source: itest-validation/src/test/java/domain/CustomDomainBuilder.java] which only reads and resolves the contribution and finally report what user-input errors are detected in the contribution. The code was working fine, untill i introduced the JavaRuntimeModuleActivator into the ModuleActivators and allowed it to start. NPE was thrown when CustomDomainBuilder tried to start the JavaRuntimeModuleActivator at line 61, basically because it failed to read the ProxyFactoryExtensionPoint. To make the code work, i just included the below part of the code before the ModuleActivators are started... // Create an interface contract mapper InterfaceContractMapper mapper = new InterfaceContractMapperImpl(); extensionPoints.addExtensionPoint(mapper); // Create Message factory MessageFactory messageFactory = new MessageFactoryImpl(); // Create Proxy factory ProxyFactory proxyFactory = new DefaultProxyFactoryExtensionPoint(messageFactory, mapper); extensionPoints.addExtensionPoint(proxyFactory); // Create context factory extension point ContextFactoryExtensionPoint contextFactories = new DefaultContextFactoryExtensionPoint(extensionPoints); extensionPoints.addExtensionPoint(contextFactories); Thought this piece of information would be useful, for whose who try to create a custom subset of Tuscany runtime using the new domain-management code base. Another thought is that, should we include this piece of the code in the sample-domain-management code too. Please let me know if any one has thoughts on this. -- Thanks Regards, Ramkumar Ramalingam
Re: TUSCANY-2277 validation messages
Hi Simon, I like to apologize for the inconvenience caused due to the huge patch file for TUSCANY-2329 and for the .pom missed out in the patch. The remaining itests for the validation messages are now available with TUSCANY-2338 along with the fix required for the test failure in interfacejava.xml.ContributionResolveExceptionTestCase. As you mentioned the test failures for impl.spring.UnableToResolveComponentTypeTestCase impl.java.ContributionResolveExceptionTestCase are basically seen due to the issue seen in CustomDomainBuilder failing to add JavaClassVisitors in the runtime. I am doing an investigation on the same to provide a fix. On 5/21/08, Simon Laws [EMAIL PROTECTED] wrote: On Wed, May 21, 2008 at 10:06 AM, Simon Laws [EMAIL PROTECTED] wrote: On Tue, May 20, 2008 at 11:19 AM, Ramkumar R [EMAIL PROTECTED] wrote: Thanks Simon, itests for these validation messages are now available with TUSCANY-2329. On 5/19/08, Simon Laws [EMAIL PROTECTED] wrote: I've just checked in Ram's patch to convert validation messages (i.e. those messages indicating that the user have provided invalid input of some form) to resource bundles and pass them through the Monitor. We need to take account of this change as we change or add code to do with validation. Primarily the change; - Pushes down a Monitor object to various parts of code that produce validation type messages. - Creates a problem object to hold any reported warning or error (sometimes there a convenience error() or warning() operation has been added if there are a lot of messages in a file) -- Each problem is identified by an id string -- The id string references into a resource bundle where the full message has been moved to. There is now a resource bundle in each module that raises validation messages - Passes the Problem on to the Monitor object Our default Monitor object simply passes the message to the JDK logger at the moment but you could imagine a Monitor that collects them all together for later analysis. Currently the majority of the exceptions that are thrown during validation are still there so I guess we need to go through taking out the ones that are not now absolutely necessary. The next job! With this done we have catalogs of all of the errors/warnings that a user is likely to come across (and examples of why the occur in the validation itests) which should help our documentation somewhat. Big thanks to Ram Simon -- Thanks Regards, Ramkumar Ramalingam Hi Ram Thanks for the patch. It was a big one. In the future it would be easier to have smaller committable chunks so we can review as you go;-) I had to fix up the pom file to make it work so maybe that got missed out of the patch. Also, you seem to have you tab key configured to include tabs. In your IDE could you change it to include four spaces instead? I'm going to check these changes in. Now we need to sort out what to do about all of the exceptions that get thrown. I'll remove the validation itests from the build temporarily while we do that. Regards Simon Ok, the tests are checked in now but I had a few problems with some of the tests. I just commented out the assets for the time being. impl.spring.UnableToResolveComponentTypeTestCase impl.java.ContributionResolveExceptionTestCase interfacejava.xml.ContributionResolveExceptionTestCase Also it seems that some of the message conversion till needs to be done, for example, Seems that some of the underlying exceptions/log statements still need converting JavaIntrospectionHelper JavaInterfaceIntrospectorImpl etc. Maybe you fixed these but didn't make a patch? Thanks Simon -- Thanks Regards, Ramkumar Ramalingam
Re: TUSCANY-2277 validation messages
Thanks Simon, itests for these validation messages are now available with TUSCANY-2329. On 5/19/08, Simon Laws [EMAIL PROTECTED] wrote: I've just checked in Ram's patch to convert validation messages (i.e. those messages indicating that the user have provided invalid input of some form) to resource bundles and pass them through the Monitor. We need to take account of this change as we change or add code to do with validation. Primarily the change; - Pushes down a Monitor object to various parts of code that produce validation type messages. - Creates a problem object to hold any reported warning or error (sometimes there a convenience error() or warning() operation has been added if there are a lot of messages in a file) -- Each problem is identified by an id string -- The id string references into a resource bundle where the full message has been moved to. There is now a resource bundle in each module that raises validation messages - Passes the Problem on to the Monitor object Our default Monitor object simply passes the message to the JDK logger at the moment but you could imagine a Monitor that collects them all together for later analysis. Currently the majority of the exceptions that are thrown during validation are still there so I guess we need to go through taking out the ones that are not now absolutely necessary. The next job! With this done we have catalogs of all of the errors/warnings that a user is likely to come across (and examples of why the occur in the validation itests) which should help our documentation somewhat. Big thanks to Ram Simon -- Thanks Regards, Ramkumar Ramalingam
Re: How do you plug in validation monitoring?
Patches for TUSCANY-2277 are now available with the following changes: - The monitors now have access to all of the errors and warnings that are raised during validation in the read, resolve and build phase of an SCA composite. - The code still throws all kind of exceptions as it was doing earlier, to avoid a null pointer exception in furthur processing. - All the exception/warning messages are customized using specified resource bundle. Each module has its own resource bundle. Here are few work items that are currently in progress: - itest for the validation errors. - Identify which exceptions are safe to ignore, so that we allow the processing to proceed furthur. This way we could catch hold of max possible user-errors in one go. On 5/6/08, Simon Laws [EMAIL PROTECTED] wrote: On Mon, May 5, 2008 at 5:54 PM, Hasan Muhammad [EMAIL PROTECTED] wrote: So if plugins want to create their own monitor, what will happen in this case? Now, the way plugins have control is, by looking at the messageID of the problem, they can decide whether they want to change the behaviour from a warning to error, etc. regard Hasan On Fri, May 2, 2008 at 11:23 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: Depending where you actually catch the exception you should be able to continue on and process the next artifact. Hmmm, the idea with monitors is to allow the processing code to report warnings and continue or multiple errors per artifact for example. Not sure about how it'll work with exceptions? -- Jean-Sebastien The suggestion is still that monitors get access to all the errors/warnings that the system generates for display to the user so you will be able to take the same approach. Simon -- Thanks Regards, Ramkumar Ramalingam
Re: How do you plug in validation monitoring?
Hi Simon, Noticed an issue, while we do itest to test the exception messages raised by the monitor during the validation, since we are still throwing all kind of exceptions from the code, for any kind of exception that's thrown the domain creation is stopped and hence we end-up in returning null for the domain. Since we have the domain as null, it would not be possible for us to catch hold of the monitor and check if we have got the required message. I believe we need changes in the code, by either ways: 1. To create a monitor and ask the domain to make use of the same, so that we have a control over the monitor. OR 2. Allow the domain creation to complete, irrespective of any user-errors that are encountered during validation. Like to know your thoughts on this. Thanks. On 5/13/08, Ramkumar R [EMAIL PROTECTED] wrote: Patches for TUSCANY-2277 are now available with the following changes: - The monitors now have access to all of the errors and warnings that are raised during validation in the read, resolve and build phase of an SCA composite. - The code still throws all kind of exceptions as it was doing earlier, to avoid a null pointer exception in furthur processing. - All the exception/warning messages are customized using specified resource bundle. Each module has its own resource bundle. Here are few work items that are currently in progress: - itest for the validation errors. - Identify which exceptions are safe to ignore, so that we allow the processing to proceed furthur. This way we could catch hold of max possible user-errors in one go. On 5/6/08, Simon Laws [EMAIL PROTECTED] wrote: On Mon, May 5, 2008 at 5:54 PM, Hasan Muhammad [EMAIL PROTECTED] wrote: So if plugins want to create their own monitor, what will happen in this case? Now, the way plugins have control is, by looking at the messageID of the problem, they can decide whether they want to change the behaviour from a warning to error, etc. regard Hasan On Fri, May 2, 2008 at 11:23 AM, Jean-Sebastien Delfino [EMAIL PROTECTED] wrote: Simon Laws wrote: Depending where you actually catch the exception you should be able to continue on and process the next artifact. Hmmm, the idea with monitors is to allow the processing code to report warnings and continue or multiple errors per artifact for example. Not sure about how it'll work with exceptions? -- Jean-Sebastien The suggestion is still that monitors get access to all the errors/warnings that the system generates for display to the user so you will be able to take the same approach. Simon -- Thanks Regards, Ramkumar Ramalingam -- Thanks Regards, Ramkumar Ramalingam
Re: [VOTE] Graduate Apache Tuscany as a Top Level Project (take two)
+1 from me. On 5/12/08, Rajini Sivaram [EMAIL PROTECTED] wrote: +1 On 5/10/08, ant elder [EMAIL PROTECTED] wrote: Restarting the graduation vote with the updated proposal words, please vote on the proposal below to graduate Tuscany to a TLP. +1 from me. ...ant X. Establish the Apache Tuscany Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software for distribution at no charge to the public, that simplifies the development, deployment and management of distributed applications built as compositions of service components. These components may be implemented with a range of technologies and connected using a variety of communication protocols. This software will implement relevant open standards including, but not limited to, the Service Component Architecture standard defined by the OASIS OpenCSA member section, and related technologies. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tuscany Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is responsible for the creation and maintenance of software related to Apache Tuscany; and be it further RESOLVED, that the office of Vice President, Apache Tuscany be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tuscany Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tuscany Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tuscany Project: * Adriano Crestani adrianocrestani at apache dot org * ant elder antelder at apache dot org * Brady Johnson bjohnson at apache dot org * Frank Budinsky frankb at apache dot org * Ignacio Silva-Lepe isilval at apache dot org * Jean-Sebastien Delfino jsdelfino at apache dot org * kelvin goodson kelvingoodson at apache dot org * Luciano Resende lresende at apache dot org * Mark Combellack mcombellack at apache dot org * Matthieu Riou mriou at apache dot org * Mike Edwards edwardsmj at apache dot org * Paul Fremantle pzf at apache dot org * Pete Robbins robbinspg at apache dot org * Raymond Feng rfeng at apache dot org * Simon Laws slaws at apache dot org * Simon Nash nash at apache dot org * Venkata Krishnan svkrish at apache dot org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder be appointed to the office of Vice President, Apache Tuscany, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Tuscany podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Tuscany podling encumbered upon the Apache Incubator Project are hereafter discharged. -- Thank you... Regards, Rajini -- Thanks Regards, Ramkumar Ramalingam
Re: How do you plug in validation monitoring?
Hi Simon, While converting the error/warning messages over to the monitor using TUSCANY-2277, i realized that it would be a tedious/not a practical job to include monitor in all parts of the code. For example, for converting the messages from all the ArtifactProcessor (for which we have 74 instances), I feel it would not be a good idea to pass on the monitor to each constructor and use them accordingly. Instead what we can try is to catch the exception thrown by ArtifactProcessor and log them into the monitor from the calling classes like ContributionServiceImpl OR CompositeBuilderImpl OR CompositeActivatorImpl. Hope this would help. Please let me know your thoughts. Thanks. -- Thanks Regards, Ramkumar Ramalingam On 4/29/08, Ramkumar R [EMAIL PROTECTED] wrote: Hi Simon, Thanks for your detailed comments, that gives a clear picture. I have now opened a JIRA (TUSCANY-2277) to address this issue. By this defect we will standardize the way messages are logged into the monitor. Will keep things posted in this thread for any complicated situations and if i am not sure about any exceptions that are thrown. -- Thanks Regards, Ramkumar Ramalingam On 4/29/08, Simon Laws [EMAIL PROTECTED] wrote: On Mon, Apr 28, 2008 at 1:42 PM, Ramkumar R [EMAIL PROTECTED] wrote: On 4/25/08, Simon Laws [EMAIL PROTECTED] wrote: On Thu, Apr 24, 2008 at 5:36 PM, Simon Laws [EMAIL PROTECTED] wrote: On Wed, Apr 23, 2008 at 5:39 AM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, I opened JIRA 2260 and attached a second batch of validation test cases. regards Hasan On Tue, Apr 22, 2008 at 8:16 AM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon I opened JIRA 2255 and attached a patch for the new testcases. Hasan On Fri, Apr 18, 2008 at 12:58 PM, Simon Laws [EMAIL PROTECTED] wrote: On Thu, Apr 17, 2008 at 5:44 PM, Simon Laws [EMAIL PROTECTED] wrote: On Thu, Apr 17, 2008 at 5:02 PM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, We should have an api for plugins to provide a resource bundle. This api probably needs to be on the monitor or somewhere, i am not sure. But the scenario occurs when plugins want to use the default Monitor but still want to use their own resource bundle for messageIDs. regards Hasan On Wed, Apr 16, 2008 at 3:30 PM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, I looked at the new Monitor and Problem interfaces. What do getMessageId() and getMessageParams() actually return? is MessageId a way to categorize the error message? regards Hasan On Tue, Apr 15, 2008 at 10:59 AM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, I was wondering if i can cook up some validation test cases if they do not exist. Or should we wait until the monitor issue is resolved ? Hasan On Thu, Apr 10, 2008 at 4:34 PM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, I dont think using an underlying tuscany jdk logger would be useful to plugins as they may not want to log, rather show it somewhere else such as console etc. Tuscany can use an underlying logger in it's own monitor ( as it uses today). But i think the first approach of using a monitor is better along with the condition that it be made more usable by the plugins by giving them greater control. Another point is that tuscany should use ResourceBundle for validation messages as well. I dont think this is being done today. regards Hasan On Wed, Apr 9, 2008 at 1:22 PM, Simon Laws [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 12:49 PM, Simon Laws [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 12:00 PM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon
Re: How do you plug in validation monitoring?
Hi Simon, Thanks for your detailed comments, that gives a clear picture. I have now opened a JIRA (TUSCANY-2277) to address this issue. By this defect we will standardize the way messages are logged into the monitor. Will keep things posted in this thread for any complicated situations and if i am not sure about any exceptions that are thrown. -- Thanks Regards, Ramkumar Ramalingam On 4/29/08, Simon Laws [EMAIL PROTECTED] wrote: On Mon, Apr 28, 2008 at 1:42 PM, Ramkumar R [EMAIL PROTECTED] wrote: On 4/25/08, Simon Laws [EMAIL PROTECTED] wrote: On Thu, Apr 24, 2008 at 5:36 PM, Simon Laws [EMAIL PROTECTED] wrote: On Wed, Apr 23, 2008 at 5:39 AM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, I opened JIRA 2260 and attached a second batch of validation test cases. regards Hasan On Tue, Apr 22, 2008 at 8:16 AM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon I opened JIRA 2255 and attached a patch for the new testcases. Hasan On Fri, Apr 18, 2008 at 12:58 PM, Simon Laws [EMAIL PROTECTED] wrote: On Thu, Apr 17, 2008 at 5:44 PM, Simon Laws [EMAIL PROTECTED] wrote: On Thu, Apr 17, 2008 at 5:02 PM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, We should have an api for plugins to provide a resource bundle. This api probably needs to be on the monitor or somewhere, i am not sure. But the scenario occurs when plugins want to use the default Monitor but still want to use their own resource bundle for messageIDs. regards Hasan On Wed, Apr 16, 2008 at 3:30 PM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, I looked at the new Monitor and Problem interfaces. What do getMessageId() and getMessageParams() actually return? is MessageId a way to categorize the error message? regards Hasan On Tue, Apr 15, 2008 at 10:59 AM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, I was wondering if i can cook up some validation test cases if they do not exist. Or should we wait until the monitor issue is resolved ? Hasan On Thu, Apr 10, 2008 at 4:34 PM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, I dont think using an underlying tuscany jdk logger would be useful to plugins as they may not want to log, rather show it somewhere else such as console etc. Tuscany can use an underlying logger in it's own monitor ( as it uses today). But i think the first approach of using a monitor is better along with the condition that it be made more usable by the plugins by giving them greater control. Another point is that tuscany should use ResourceBundle for validation messages as well. I dont think this is being done today. regards Hasan On Wed, Apr 9, 2008 at 1:22 PM, Simon Laws [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 12:49 PM, Simon Laws [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 12:00 PM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, I am on revision 634808. The ContributionServiceImpl has changed since then, and with the one that i have, it would lead through the CompositeProcessor instead of the CompositeDocumentProcessor. Hence the difference in exceptions.. Also, dont you think that with the error that you got should throw an exception with schema validation, rather than just a warning? Hasan On Wed, Apr 9, 2008 at 6:36 AM, Simon Laws [EMAIL PROTECTED] wrote: On Tue, Apr 8, 2008 at 2:58 PM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon
Re: How do you plug in validation monitoring?
On 4/25/08, Simon Laws [EMAIL PROTECTED] wrote: On Thu, Apr 24, 2008 at 5:36 PM, Simon Laws [EMAIL PROTECTED] wrote: On Wed, Apr 23, 2008 at 5:39 AM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, I opened JIRA 2260 and attached a second batch of validation test cases. regards Hasan On Tue, Apr 22, 2008 at 8:16 AM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon I opened JIRA 2255 and attached a patch for the new testcases. Hasan On Fri, Apr 18, 2008 at 12:58 PM, Simon Laws [EMAIL PROTECTED] wrote: On Thu, Apr 17, 2008 at 5:44 PM, Simon Laws [EMAIL PROTECTED] wrote: On Thu, Apr 17, 2008 at 5:02 PM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, We should have an api for plugins to provide a resource bundle. This api probably needs to be on the monitor or somewhere, i am not sure. But the scenario occurs when plugins want to use the default Monitor but still want to use their own resource bundle for messageIDs. regards Hasan On Wed, Apr 16, 2008 at 3:30 PM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, I looked at the new Monitor and Problem interfaces. What do getMessageId() and getMessageParams() actually return? is MessageId a way to categorize the error message? regards Hasan On Tue, Apr 15, 2008 at 10:59 AM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, I was wondering if i can cook up some validation test cases if they do not exist. Or should we wait until the monitor issue is resolved ? Hasan On Thu, Apr 10, 2008 at 4:34 PM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, I dont think using an underlying tuscany jdk logger would be useful to plugins as they may not want to log, rather show it somewhere else such as console etc. Tuscany can use an underlying logger in it's own monitor ( as it uses today). But i think the first approach of using a monitor is better along with the condition that it be made more usable by the plugins by giving them greater control. Another point is that tuscany should use ResourceBundle for validation messages as well. I dont think this is being done today. regards Hasan On Wed, Apr 9, 2008 at 1:22 PM, Simon Laws [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 12:49 PM, Simon Laws [EMAIL PROTECTED] wrote: On Wed, Apr 9, 2008 at 12:00 PM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, I am on revision 634808. The ContributionServiceImpl has changed since then, and with the one that i have, it would lead through the CompositeProcessor instead of the CompositeDocumentProcessor. Hence the difference in exceptions.. Also, dont you think that with the error that you got should throw an exception with schema validation, rather than just a warning? Hasan On Wed, Apr 9, 2008 at 6:36 AM, Simon Laws [EMAIL PROTECTED] wrote: On Tue, Apr 8, 2008 at 2:58 PM, Hasan Muhammad [EMAIL PROTECTED] wrote: Hi Simon, Thank you for the good information. First up i am trying to verify whether the schema validation works when we point to our schemas. Can you let me know what is a simple error that i can introduce so that i can verify this? I tried doing this to my composite file (In block red): component name=MyServiceComponentNew implementation.java class=mysca.test.myservice.impl.MyServiceImpl/ *binding.ws/* property name=location source=$newLocation/ property name=year source=$newYear/ /component This resulted in the following exception, but i think
Re: [VOTE] Graduate Apache Tuscany as a Top Level Project
On 4/29/08, Wang Feng [EMAIL PROTECTED] wrote: +1 from me too. Thanks, Wang Feng On 2008-04-29 02:16:50,ant elder [EMAIL PROTECTED] wrote: We've done a lot of work since last October. We now have a diverse community of contributors and have demonstrated the ability to attract new committers to create an even more diverse community, we have shown we can do releases based on Apache guidelines, and we have shown we conduct our discussions in public within full view of the community and can resolve disagreements on the lists. I think we're ready, so please vote on the proposal below to graduate Tuscany to a TLP. +1 from me. ...ant X. Establish the Apache Tuscany Project WHEREAS, the Board of Directors deems it to be in the best interests of the Foundation and consistent with the Foundation's purpose to establish a Project Management Committee charged with the creation and maintenance of open-source software that simplifies the development and deployment of service oriented applications and provides a managed service-oriented runtime based on the standards defined by the OASIS OpenCSA group, for distribution at no charge to the public. NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC), to be known as the Apache Tuscany Project, be and hereby is established pursuant to Bylaws of the Foundation; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is responsible for the creation and maintenance of software related to Apache Tuscany; and be it further RESOLVED, that the office of Vice President, Apache Tuscany be and hereby is created, the person holding such office to serve at the direction of the Board of Directors as the chair of the Apache Tuscany Project, and to have primary responsibility for management of the projects within the scope of responsibility of the Apache Tuscany Project; and be it further RESOLVED, that the persons listed immediately below be and hereby are appointed to serve as the initial members of the Apache Tuscany Project: - Adriano Crestani adrianocrestani at apache dot org - ant elder antelder at apache dot org - Brady Johnson bjohnson at apache dot org - Frank Budinsky frankb at apache dot org - Ignacio Silva-Lepe isilval at apache dot org - Jean-Sebastien Delfino jsdelfino at apache dot org - kelvin goodson kelvingoodson at apache dot org - Luciano Resende lresende at apache dot org - Mark Combellack mcombellack at apache dot org - Matthieu Riou mriou at apache dot org - Mike Edwards edwardsmj at apache dot org - Paul Fremantle pzf at apache dot org - Pete Robbins robbinspg at apache dot org - Raymond Feng rfeng at apache dot org - Simon Laws slaws at apache dot org - Simon Nash nash at apache dot org - Venkata Krishnan svkrish at apache dot org NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ant Elder be appointed to the office of Vice President, Apache Tuscany, to serve in accordance with and subject to the direction of the Board of Directors and the Bylaws of the Foundation until death, resignation, retirement, removal or disqualification, or until a successor is appointed; and be it further RESOLVED, that the Apache Tuscany Project be and hereby is tasked with the migration and rationalization of the Apache Incubator Tuscany podling; and be it further RESOLVED, that all responsibilities pertaining to the Apache Incubator Tuscany podling encumbered upon the Apache Incubator Project are hereafter discharged. +1 from me too. -- Thanks Regards, Ramkumar Ramalingam
Re: [NOTICE] Mario Antollini voted as Tuscany committer
On 4/26/08, Mike Edwards [EMAIL PROTECTED] wrote: Luciano Resende wrote: The Tuscany PPMC and Incubator PMC have voted for Mario Antollini to become a Tuscany committer. Please spend sometime to get familiar with Apache developer's pages [1], the Apache Incubator site [2] and to the Incubator Committers Guide [3]. Also, could you please submit an Apache CLA so we can get your userid and access sorted out, you can find out about the Contributor License Agreement at [4]. Congratulations and welcome Mario! [1] http://www.apache.org/dev/ [2] http://incubator.apache.org/ [3] http://incubator.apache.org/guides/committer.html [4] http://www.apache.org/licenses/#clas Mario, Congratulations and welcome on board! Yours, Mike. Congratulations Mario!! -- Thanks Regards, Ramkumar Ramalingam
Re: [Discussion] Exception Handing when adding remote binding to services
On 4/23/08, Simon Laws [EMAIL PROTECTED] wrote: On Wed, Apr 23, 2008 at 12:43 PM, Ramkumar R [EMAIL PROTECTED] wrote: On 4/18/08, Ramkumar R [EMAIL PROTECTED] wrote: On 4/18/08, Simon Laws [EMAIL PROTECTED] wrote: On Fri, Apr 18, 2008 at 9:18 AM, Ramkumar R [EMAIL PROTECTED] wrote: TUSCANY 1881, talks about throwing a warning msg when adding remote bindings to services with interfaces not marked as remotable, by which the data transformation might get messed up. From the current implementation, I understand that the datatransformation interceptor will not be inserted in the invocation chain if the target interface is not marked as remotable. Not having this interceptor will end up with binding specific data transformations not being done.. So unless the target binding does have any trouble with the arguments and returntypes because of the absence of transformations... we do not have any issues. But otherwise we might end up in runtime exceptions being thrown. While thinking at a solution to this issue, i could think of various options as shown below, but not sure which one is the right approach? OPTION 1: About issue shows how lack of Remotable ends up in runtime exception when service methods are invoked, can't we somehow trap this during component build or activatoin time itself? OPTION 2: I believe this whole thing can be solved if we can simply check in the binding if the interface is marked remote. OPTION 3: Currently DataBindingRuntimeWireProcessor.process() method checks if the source and target interfaces is remotable before it validates to see if data transformation is required. One way of solution to throw a warning msg is to check the source and target datatypes, if their datatypes are diff we assume that data transformation is required and we look if the interfaces are marked remotable, if not we throw a warning msg to alert that there could be an unexpected behaviour in data transformation. OPTION 4: In the DataBindingRuntimeWireProcessor.process() method, just check if the source and target interface is remotable OR if the source and target datatypes are different. If any one condition is satisfied then we assume that data transformation is required. Apart from the above mentioned issue, do we need to make such checks for ws binding as well OR do we need this checks for all kind of bindings. Like to know people's view on this regard. Thanks. -- Thanks Regards, Ramkumar Ramalingam Hi Ramkumar When I originally raised the JIRA I had imagined the solution would be your OPTION 1. So that we get a warning that at least tells the user that they are doing something odd. In my case it took me a while to work out what the problem was so it would have been nice if the runtime had at least said you are dong something strange are you sure you want to do this. I hadn't imagines that we could introduce a data transformation in this case. Is there code in there that tries and optimizes away the remote binding if it detects that the components are running locally? Simon Hi Simon, I believe, we don't do any validatation to identify if the component is local / remote. But anyway we assume that the component is remote by checking if the interface is remotable. I could see that we only check if the interfaces are remotable and we try to apply appropriate binding and data transformation upon them. I agree with your idea of identifying the component as local/remote and do some optimization on binding and data transformation part. If everyone agrees that we need this in place we can probably think of taking this suggestion forward. -- Thanks Regards, Ramkumar Ramalingam Hi Simon, In the mean time, while leaving the optimization part. To fix the issue mentioned in TUSCANY-1881, i believe the best solution would be to identify at the bindingProvider level (except for binding.sca) to check if the source and target interface is remotable and throw a warning message as required. Hope this helps. -- Thanks Regards, Ramkumar Ramalingam Sounds good to me. Simon Hi Simon, In case of JSON-RPC binding (our original scenario), when the interface is not defined @Remotable the runtime just ignores the data transformation between the binding without throwing any exception. But I have noticed that in case of Axis2 binding for the same scenario, we get an exception as shown below. *java.lang.IllegalArgumentException*: Can't handle *mixed* payloads between OMElements and other types. I believe, just throwing a warning would not help for all kind of bindings as such scenario could even throw
Re: [Discussion] Exception Handing when adding remote binding to services
On 4/18/08, Ramkumar R [EMAIL PROTECTED] wrote: On 4/18/08, Simon Laws [EMAIL PROTECTED] wrote: On Fri, Apr 18, 2008 at 9:18 AM, Ramkumar R [EMAIL PROTECTED] wrote: TUSCANY 1881, talks about throwing a warning msg when adding remote bindings to services with interfaces not marked as remotable, by which the data transformation might get messed up. From the current implementation, I understand that the datatransformation interceptor will not be inserted in the invocation chain if the target interface is not marked as remotable. Not having this interceptor will end up with binding specific data transformations not being done.. So unless the target binding does have any trouble with the arguments and returntypes because of the absence of transformations... we do not have any issues. But otherwise we might end up in runtime exceptions being thrown. While thinking at a solution to this issue, i could think of various options as shown below, but not sure which one is the right approach? OPTION 1: About issue shows how lack of Remotable ends up in runtime exception when service methods are invoked, can't we somehow trap this during component build or activatoin time itself? OPTION 2: I believe this whole thing can be solved if we can simply check in the binding if the interface is marked remote. OPTION 3: Currently DataBindingRuntimeWireProcessor.process() method checks if the source and target interfaces is remotable before it validates to see if data transformation is required. One way of solution to throw a warning msg is to check the source and target datatypes, if their datatypes are diff we assume that data transformation is required and we look if the interfaces are marked remotable, if not we throw a warning msg to alert that there could be an unexpected behaviour in data transformation. OPTION 4: In the DataBindingRuntimeWireProcessor.process() method, just check if the source and target interface is remotable OR if the source and target datatypes are different. If any one condition is satisfied then we assume that data transformation is required. Apart from the above mentioned issue, do we need to make such checks for ws binding as well OR do we need this checks for all kind of bindings. Like to know people's view on this regard. Thanks. -- Thanks Regards, Ramkumar Ramalingam Hi Ramkumar When I originally raised the JIRA I had imagined the solution would be your OPTION 1. So that we get a warning that at least tells the user that they are doing something odd. In my case it took me a while to work out what the problem was so it would have been nice if the runtime had at least said you are dong something strange are you sure you want to do this. I hadn't imagines that we could introduce a data transformation in this case. Is there code in there that tries and optimizes away the remote binding if it detects that the components are running locally? Simon Hi Simon, I believe, we don't do any validatation to identify if the component is local / remote. But anyway we assume that the component is remote by checking if the interface is remotable. I could see that we only check if the interfaces are remotable and we try to apply appropriate binding and data transformation upon them. I agree with your idea of identifying the component as local/remote and do some optimization on binding and data transformation part. If everyone agrees that we need this in place we can probably think of taking this suggestion forward. -- Thanks Regards, Ramkumar Ramalingam Hi Simon, In the mean time, while leaving the optimization part. To fix the issue mentioned in TUSCANY-1881, i believe the best solution would be to identify at the bindingProvider level (except for binding.sca) to check if the source and target interface is remotable and throw a warning message as required. Hope this helps. -- Thanks Regards, Ramkumar Ramalingam
How to configure a remotable service, exposed with default binding?
Lets say we have a component A in composite C1, which needs a reference to a remotable service exposed with default binding (i.e., binding.sca) in component B under composite C2. In such scenario how should i configure the (binding) reference in composite C1? -- Thanks Regards, Ramkumar Ramalingam
svn-commit r650405 - org.apache.tuscany.sca.node.impl.DomainDrivenTestCase.java
org.apache.tuscany.sca.node.NodeException: org.apache.tuscany.sca.interfacedef.InvalidOperationException: Method should not declare exceptions with an @OneWay annotation. at org.apache.tuscany.sca.node.impl.SCANodeImpl.init(SCANodeImpl.java:222) at org.apache.tuscany.sca.node.impl.SCANodeImpl.init(SCANodeImpl.java:128) at org.apache.tuscany.sca.node.impl.SCANodeFactoryImpl.createSCANode(SCANodeFactoryImpl.java:54) at org.apache.tuscany.sca.node.impl.NodeDrivenTestCase.init(NodeDrivenTestCase.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74) at org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879) DomainDrivenTestCase fails with the above exception as we have a destroyNode() method in org.apache.tuscany.sca.node.management.SCANodeManagerService.java interface with @OneWay annotation, but declared to throw NodeException. As per the specs, Any method that returns void and has no declared exceptions may be marked with an @OneWay annotation. I am raising a JIRA to fix this issue by making the destroyNode() method not to throw any exception. -- Thanks Regards, Ramkumar Ramalingam
Re: svn-commit r650405 - org.apache.tuscany.sca.node.impl.DomainDrivenTestCase.java
On 4/22/08, Ramkumar R [EMAIL PROTECTED] wrote: org.apache.tuscany.sca.node.NodeException: org.apache.tuscany.sca.interfacedef.InvalidOperationException: Method should not declare exceptions with an @OneWay annotation. at org.apache.tuscany.sca.node.impl.SCANodeImpl.init(SCANodeImpl.java:222) at org.apache.tuscany.sca.node.impl.SCANodeImpl.init(SCANodeImpl.java:128) at org.apache.tuscany.sca.node.impl.SCANodeFactoryImpl.createSCANode(SCANodeFactoryImpl.java:54) at org.apache.tuscany.sca.node.impl.NodeDrivenTestCase.init(NodeDrivenTestCase.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74) at org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50) at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33) at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125) at org.apache.maven.surefire.Surefire.run(Surefire.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:615) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:308) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:879) DomainDrivenTestCase fails with the above exception as we have a destroyNode() method in org.apache.tuscany.sca.node.management.SCANodeManagerService.java interface with @OneWay annotation, but declared to throw NodeException. As per the specs, Any method that returns void and has no declared exceptions may be marked with an @OneWay annotation. I am raising a JIRA to fix this issue by making the destroyNode() method not to throw any exception. -- Thanks Regards, Ramkumar Ramalingam I have raised TUSCANY-2252 to make the destroyNode() method not to throw any exception. Please let me know if there could be any other issue by doing so. Thanks. -- Thanks Regards, Ramkumar Ramalingam
[Discussion] Exception Handing when adding remote binding to services
TUSCANY 1881, talks about throwing a warning msg when adding remote bindings to services with interfaces not marked as remotable, by which the data transformation might get messed up. From the current implementation, I understand that the datatransformation interceptor will not be inserted in the invocation chain if the target interface is not marked as remotable. Not having this interceptor will end up with binding specific data transformations not being done.. So unless the target binding does have any trouble with the arguments and returntypes because of the absence of transformations... we do not have any issues. But otherwise we might end up in runtime exceptions being thrown. While thinking at a solution to this issue, i could think of various options as shown below, but not sure which one is the right approach? OPTION 1: About issue shows how lack of Remotable ends up in runtime exception when service methods are invoked, can't we somehow trap this during component build or activatoin time itself? OPTION 2: I believe this whole thing can be solved if we can simply check in the binding if the interface is marked remote. OPTION 3: Currently DataBindingRuntimeWireProcessor.process() method checks if the source and target interfaces is remotable before it validates to see if data transformation is required. One way of solution to throw a warning msg is to check the source and target datatypes, if their datatypes are diff we assume that data transformation is required and we look if the interfaces are marked remotable, if not we throw a warning msg to alert that there could be an unexpected behaviour in data transformation. OPTION 4: In the DataBindingRuntimeWireProcessor.process() method, just check if the source and target interface is remotable OR if the source and target datatypes are different. If any one condition is satisfied then we assume that data transformation is required. Apart from the above mentioned issue, do we need to make such checks for ws binding as well OR do we need this checks for all kind of bindings. Like to know people's view on this regard. Thanks. -- Thanks Regards, Ramkumar Ramalingam
Re: [Discussion] Exception Handing when adding remote binding to services
On 4/18/08, Simon Laws [EMAIL PROTECTED] wrote: On Fri, Apr 18, 2008 at 9:18 AM, Ramkumar R [EMAIL PROTECTED] wrote: TUSCANY 1881, talks about throwing a warning msg when adding remote bindings to services with interfaces not marked as remotable, by which the data transformation might get messed up. From the current implementation, I understand that the datatransformation interceptor will not be inserted in the invocation chain if the target interface is not marked as remotable. Not having this interceptor will end up with binding specific data transformations not being done.. So unless the target binding does have any trouble with the arguments and returntypes because of the absence of transformations... we do not have any issues. But otherwise we might end up in runtime exceptions being thrown. While thinking at a solution to this issue, i could think of various options as shown below, but not sure which one is the right approach? OPTION 1: About issue shows how lack of Remotable ends up in runtime exception when service methods are invoked, can't we somehow trap this during component build or activatoin time itself? OPTION 2: I believe this whole thing can be solved if we can simply check in the binding if the interface is marked remote. OPTION 3: Currently DataBindingRuntimeWireProcessor.process() method checks if the source and target interfaces is remotable before it validates to see if data transformation is required. One way of solution to throw a warning msg is to check the source and target datatypes, if their datatypes are diff we assume that data transformation is required and we look if the interfaces are marked remotable, if not we throw a warning msg to alert that there could be an unexpected behaviour in data transformation. OPTION 4: In the DataBindingRuntimeWireProcessor.process() method, just check if the source and target interface is remotable OR if the source and target datatypes are different. If any one condition is satisfied then we assume that data transformation is required. Apart from the above mentioned issue, do we need to make such checks for ws binding as well OR do we need this checks for all kind of bindings. Like to know people's view on this regard. Thanks. -- Thanks Regards, Ramkumar Ramalingam Hi Ramkumar When I originally raised the JIRA I had imagined the solution would be your OPTION 1. So that we get a warning that at least tells the user that they are doing something odd. In my case it took me a while to work out what the problem was so it would have been nice if the runtime had at least said you are dong something strange are you sure you want to do this. I hadn't imagines that we could introduce a data transformation in this case. Is there code in there that tries and optimizes away the remote binding if it detects that the components are running locally? Simon Hi Simon, I believe, we don't do any validatation to identify if the component is local / remote. But anyway we assume that the component is remote by checking if the interface is remotable. I could see that we only check if the interfaces are remotable and we try to apply appropriate binding and data transformation upon them. I agree with your idea of identifying the component as local/remote and do some optimization on binding and data transformation part. If everyone agrees that we need this in place we can probably think of taking this suggestion forward. -- Thanks Regards, Ramkumar Ramalingam
Re: svn commit: r648763 - /incubator/tuscany/java/sca/modules/databinding/src/main/java/org/apache/tuscany/sca/databinding/impl/DirectedGraph.java
Hi Simon, I am also facing this issue, here Raymond have used ConcurrentHashMap to resolve the issue as mentioned in TUSCANY-2069, but we can't be using ConcurrentHashMap in this case as this collection (ConcurrentHashMap) does not allow null value to be inserted in the Map. Since the DirectedGraph.java class explicitly tries to insert null value in its getShortestPath() method we see this exception. For now we can revert to the old code of having HashMap to resolve this issue. -- Thanks Regards, Ramkumar Ramalingam
Re: [NOTICE] Wang Feng voted as Tuscany committer
Congrats, Wang Feng!! -- Thanks Regards, Ramkumar Ramalingam
Handling exceptions for @OneWay Annotations
Hi, By working on TUSCANY-1881, i am just tyring to fix the issue for producing better exception message for those methods with @OneWay annotations, when these method does not have void return type. As mentioned in the specs Any method that returns void and has no declared exceptions may be marked with an @OneWay annotation. As a fix, I figured that org.apache.tuscany.sca.interfacedef.java.impl.JavaInterfaceIntrospectorImpl class needs to throw the exception in its getOperations() method as shown in my comments to TUSCANY-1881. But, I am not sure if this is the only place we need a fix for this issue? Please suggest -- Thanks Regards, Ramkumar Ramalingam
Re: Handling exceptions for @OneWay Annotations
Sorry for mentioning TUSCANY-1881.. the actual JIRA is TUSCANY-1867. -- Thanks Regards, Ramkumar Ramalingam
Re: A solution to avoid ConcurrentModificationException
Thanks Simon, for your recommendation on synchronizing the access to loadListeners() method for TUSCANY-2192, i agree with you and have reopened the JIRA to apply the fix. Thanks Raymond and Scott for your inputs on this regard. For the scenario explained by Scott it looks like synchronizing the access to loadDataBindings() method resolves the issue. To get the better understanding on JIRA's TUSCANY-2192 and TUSCANY-2170, it would be of great help if Greg can share the scenario for which he is facing this issue. In the mean time i am planning to put an itest (as suggested by Simon) in place to replicate these issues. Thanks, Ramkumar Ramalingam
A solution to avoid ConcurrentModificationException
Hi All, Looking at the history of JIRA's (2170, 2085, 2092) raised due to ConcurrentModificationException, its evident that our runtime would throw more such exceptions in the coming days, such problem occurs if two threads try to add a contribution simultaneously. Also the above mentioned JIRA's gives us a clue that mostly these issues are noticed for the ExtensionPoint implementation classes. Current Implementation of ExtensionPoint classes use either ArrayList OR HashMap to maintain the list of processors, listeners, factories and providers. Basically the Implementation of ArrayList HashMap are not synchronized, hence If multiple threads try to access an ArrayList/HashMap instance concurrently, and at least one of the threads modifies the list/map structurally, it must be synchronized externally. Hence a fix is required for these classes, *please have a look at JIRA-2170 comments for more details on the implemented solution*. As a precautionary measure, I like to raise a JIRA for all the ExtensionPoint classes to provide this fix for the above said issue, before we encounter them one by one. Before I go ahead, I like to hear from people about their thought on this regard. Thanks. -- Thanks Regards, Ramkumar Ramalingam
Need access to assign a JIRA
Hi, An issue that's mentioned in JIRA ( https://issues.apache.org/jira/browse/TUSCANY-2092) seems to be something of my interest and i would like to have this JIRA assigned to myself and provide a fix. Noticed that i do have enough rights to assign a JIRA to my ID=ramkumar.rj. Can anyone help me on this regard? Thanks. -- Thanks Regards, Ramkumar Ramalingam
Synchronizing the access to SCADefinitions
Hi All, I am new to Tuscany Community, being interested in contributing and trying to catch up. Right now am going through the code to get a feel of it and the threading issue (as mentioned in http://www.mail-archive.com/tuscany-dev%40ws.apache.org/msg29138.html) seems to be something simple that I can fix to try a hand with Tuscany. Looking at the current implementation SCADefinitionsImpl.java uses java ArrayList to store the list of policy sets, intents, binding types etc. Possible solutions to this issue woule be to a) synchronize the methods that does the operations like clear/addAll OR b) replace the existing ArrayList with Vectors OR c) replace the existing ArrayList with CopyOnWriteArrayList (new with Java1.5) Option (a) seems to be a bad idea for me as it would lock the entire method, instead i would go for option (b) OR (c). Going for option (b), using Vectors OR Collections.synchronizedList synchronizes your list object. However, the iterators implemented in the java.util Collections classes are fail-fast, which means that if one thread changes a collection while another thread is traversing it through an Iterator, the next Iterator.hasNext() or Iterator.next() call will throw ConcurrentModificationException. If we have to prevent ConcurrentModificationException, we must lock the entire List while you are iterating by wrapping it with a synchronized block, which inturn is costly. Option (c) seems to be a good solution to the above problem, the CopyOnWriteArrayList class from util.concurrent (which will also appear in the java.util.concurrent package in JDK 1.5) is a thread-safe implementation of ArrayList that offers far better concurrency. Multiple reads can almost always execute concurrently, simultaneous reads and writes can usually execute concurrently, and multiple simultaneous writes can often execute concurrently. Also CopyOnWriteArrayList contains a mutable reference to an immutable array, so as long as that reference is held fixed, you get all the thread-safety benefits of immutability without the need for locking. I have opened a JIRA (Tuscany-2170) to fix this issue. Please suggest me if this one is the right approach. -- Thanks Regards, Ramkumar Ramalingam
Re: Removing definitions
On 3/27/08, Greg Dritschler [EMAIL PROTECTED] wrote: I'm not sure I'm getting the multi-threading thing, could you say a bit more about it? -- Jean-Sebastien [EMAIL PROTECTED] Thread 1 and thread 2 call ContributionService.contribute. Each contribution contains a defintions.xml file so both threads try to add policy sets etc. Since SCADefinitions uses unsynchronized ArrayLists this is exposed to failure. SCADefinitionsUtil also has some code that isn't thread safe. Greg Hi, I am new to Tuscany Community and trying to catch up. Right now am going through the code to get a feel of it and this threading issue seems to something simple that I can fix to try a hand with Tuscany. Can I create a JIRA for the threading issue alone and attach a patch ? -- Thanks Regards, Ramkumar Ramalingam
