Writing a Custom Condition in WSO2 CEP - wso2

I want to extend the Wso2 CEP product in our needs and try to write a custom condition as indicated in this official wso2 cep link.
However it says that "This is the latest, released WSO2 Complex Event Processor documentation (Version 2.1.0)." at the top of the page, it seems that it is outdated or having wrong information.
For example it says that,
To write a custom condition, create a class extending "org.wso2.siddhi.core.executor.conditon.AbstractGenericConditionExecutor", add the SiddhiExtionsion annotation, compile that class, and add the jar file to the class path /repertory/components/lib. Then add the fully-qualified class name for the implementation class in a new line, to the siddhi.extension file located at /repertory/conf/siddhi.
(I am assuming "repertory" is "repository"). There is no file or directory in official WSO2 CEP package as "/repertory/conf/siddhi" or "siddhi.extension", (wso2cep-2.1.0).
Is there a thing that i missed in this documentation, if not, can you recommend a new documentation about to write a custom condition in WSO2 CEP?

It is a bug, there is a folder called "sidddhi" in the , it needs to be "siddhi" (this is a small typo error).. Please change that directory name to "siddhi" and perform your task ("sidddhi" to "siddhi")...
Yes.. I have corrected the doc also with the correct "repository"... Thanks for the notification...
Regards,
Mohan

Related

visibleRoles missing from API definition

I have a sample API definition with visibility: RESTRICTED and visibleRoles: role1,role2. When I use apictl init SampleAPI --definition , the visibleRoles field is missing in the generated api.yaml file. Is there an existing defect/issue for that ?
Yes, the visibleRoles field is not getting added when generating api.yaml using apictl init in APICTL 3.2.1 which is an issue. Thank you very much for informing this. Will look into that.
Can you kindly add visibleRoles fields to your generated api.yaml as a workaround and proceed until this is fixed in APICTL 3.2.1? (This is already fixed in APICTL 4.0.0-Alpha2.)

Using UniqueEntity outside of Symfony stack

I have an app built on top of Silex and I'm using Doctrine as my ORM.
I have a problem where I'm trying to get a clean error for when a user tries to reuse an email, I found the validator UniqueEntity but it seems to be designed for the full stack version of Symfony.
My question is, is this true? I'm going a limb and assuming it as I haven't found anyone who successfully used it outside of Symfony.
My second question is, if I'm not able to use UniqueEntity, whats my next best option? I'm using the Symfony Validator component and would like to use something that's plugged into that to keep it all in the same block of code.
You can use UniqueEntity with Silex.
Here's the service provider package with the Doctrine ManagerRegistry implementation - saxulum/saxulum-doctrine-orm-manager-registry-provider. Also you can find the instructions how to use it with the UniqueEntity validator in README.
But you may want to implement you own UniqueEntity validator.
For example, if you want to validate DTO object (or any non-entity object), because it's not supported by Symfony's UniqueEntity validator (see issue on GitHub).

JAX/WS wsgen is not generating

I have a problem like this ; Could you please help me if you know the reason?
I m trying to generate jaxb classes for input and out types using wsgen command line utility.
The print screen you posted (and #home's comment is spot on - you should add the stacktrace not a print screen) tells you the problem.
#javax.jws.WebService annotated classes that do not belong to a package must have the #javax.jws.WebService.targetNamespace element.
You don't specify a target namespace and wsgen can't infer one because you classes are in the default package. Having classes in the default package is a frown upon practice. Put your classes under a package and try again or have the WebService.targetNamespace element set up which also gives you more control on what the tool generates.
#javax.jws.WebService the annotated classe who implements Web Service Business interface, must have a no-argument constructor otherwise wsGen tool gets such error.
Reference: Creating a Simple Web Service and Client with JAX-WS

Rest Template setter used in CloudFoundry client lib

We are trying to use the CloudFoundryClient (org.cloudfoundry.client.lib) to utilize the REST interface to add applications, create services etc
We see an issue in the getToken method of org.cloudfoundry.client.lib.oauth2.OauthClient where it tries to access the setRestTemplate method of the org.springramework.security.oauth2.client.token.grant.implicit.ImplicitAccessTokenProvider.
On looking up the source, we see that the setter for RestTemplate in the ImplicitAccessTokenProvider has been removed on 29th Aug, which is what is causing this inconsistency.
Could you please advise and let us know if we should try with a version of spring-security-oauth prior to this change and a link where we could find this?
The cloudfoundry-client-lib uses 1.0.0.RC1 of spring-security-oauth where this method is available. Please refer to SPRING SECURITY OAUTH 1.0.0.RC1 IS RELEASED

SharePoint Web Services - Updating ContentType field Required property?

I've been trying to programmatically reproduce the behavior of editing a Content Type's field properties in the SharePoint site management screen and selecting the "Required" radio button with no sucess using the WSS 3.0 web service's Webs.asmx "UpdateContentType" method.
The first difficulty was the issue with the MSDN documentation that said fields should be of a FieldRef type when in fact they need to be of a Field type (reference). Adding fields and deleting fields works fine after the fix, but updating fields seems to not function at all. (It should also be noted that I followed the recommendation on the previous link to use Method="2" for updating fields but it changes nothing, and using Method values other than 1 for adding or other than 3 for deleting also function correctly).
Here's the web service call (slightly modified with strings instead of XmlNode objects for readability):
SharePointWebServices.Webs webService = new SharePointWebServices.Webs();
webService.Url = "http://mysharepointserver/site";
webService.UseDefaultCredentials = true;
webService.UpdateContentType(
#"0x01005A089D9EC8A382458FB1F6C72096D52A",
#"<ContentType />",
#"<Fields />",
#"<Fields><Method ID=""1""><Field Name=""SomeField"" ID=""{8a4803c4-6545-4a7a-804d-237eebff0ce3}"" Required=""TRUE"" Hidden=""FALSE"" ReadOnly=""FALSE"" PITarget="""" PIAttribute="""" PrimaryPIAttribute="""" Aggregation="""" Node="""" /></Method></Fields>",
#"<Fields />");
After the call, the field is still Required="FALSE".
A quick look into the stssoap.dll assembly indicates that the "Required" property is apparently ignored during the update process. Is this normal behavior? If so, what is the recommended method for programmatically changing the "Required" field from client code (not executing on the SharePoint server)?
Any help would be greatly appreciated.
I've investigated this and found the same thing. I also tried adding the attribute Cmd="Update" to the Method element without success. This example of how to use UpdateContentType was helpful too.
I don't believe you will be able to do this with the out-of-the-box SharePoint services. You've verified from looking at stssoap.dll that this doesn't appear to work correctly. Another 'client'-style option is to use RPC methods but none appear to provide functionality for content types at all.
The web services are particularly frustrating because this type of not-so-edge case regularly comes up. It is very rare that I consider using them because of the time wasting involved with their limitations.
Do you have any option of deploying custom code to the server? You could develop this functionality using the object model and wrap it in your own custom web service (there is a walkthrough here) quite easily.
Here is an example adapted from Gabe Wishnie that does what you require:
SPContentType myContentType = myWeb.ContentTypes["myContentType"];
string internalName = myContentType.Fields["fieldToUpdate"].InternalName;
myContentType.FieldLinks[internalName].Required = false;
myContentType.Update(true);
Sorry this isn't more helpful but it's a common story when using the WSS 3.0 / SharePoint 2007 web services.