Hi Malintha,
I think configuration should be something like
<instance name="asw001" type="standalone" nonBlockingEnabled="true">
Here basically we need NHTTP for ESB and LB only. As out initial design we
check whether NHTTP and NHTTPS potts are null or not to assign this to url.
Though +1 fo introducing a configuration.
But still the servicePortType="nhttpport" does not reflect actually what we
need to do here
this should be either
<instance name="asw001" type="standalone" nonBlockingEnabled="true">
or
<instance name="asw001" type="standalone" transportType="nonBlocking">
Thank You,
Dharshana.
On Wed, Oct 30, 2013 at 11:11 PM, Malintha Adikari <malin...@wso2.com>wrote:
> *Running the test in product/stratos modes*
>
> The tenant which is used to build the test environment decides whether
> test is running on product or stratos modes. In the case of the super
> tenant user is used to build the test environment , the test is running on
> product mode. If the tenant is any other it runs in stratos mode. As an
> example :
> Following is ESB test base class.
>
>
> public class ESBIntegrationTest {
>
> ................................
> ................................
>
> protected void init() throws URISyntaxException, SAXException,
> IOException, XMLStreamException,
> ConfigurationMismatchException {
>
> ..............................
> ..............................
>
> automationContextBuilder = new
> AutomationContextBuilder("ESB","asw001");
> automationContextBuilder.build("wso2.com", "user1");
> }
>
> .........................
> }
>
> With the above configuration uses a tenant which domain is 'wso2.com'
> (not the super tenant -carbon.super) and the test will be executed in
> stratos mode.
>
>
>
> Adding custom service port type to instance nodes
>
> With the improvement Test Automation Framework users can use custom
> service port type in the case of service URL generation. This feature is
> essential for ESB tests as it uses the nhttp/nhttps ports for the service
> URL for generating. Users have to mention the type of the port which is
> expected to be used to generate the URL in the PlatformContext - >
> ProductGroup - > instance node. Also that mentioned port should be included
> as a child element of the instance node. As an example :
>
>
> <platform>
> <productGroup name="ESB" clusteringEnabled="true">
> <instance name="asw001" type="standalone"
> servicePortType="nhttpport">
> <host>localhost</host>
> <httpport>9763</httpport>
> <webContext></webContext>
> <httpsport>9443</httpsport>
> <nhttpport>8280</nhttpport>
> <nhttpsport>8280</nhttpsport>
> <qpidport>123</qpidport>
> <nhttps1>875</nhttps1>
> <nhttps2>875</nhttps2>
> <cutomport>8085</customport>
> </instance>
>
>
>
> This configuration uses the port which is given as the 'serivePortType'
> for service for URL generation ( In this case it is set to 'nhttp'). The
> instance node should have that mentioned 'nhttpport' in list of service
> port elements. Absense of that will give an execption at the begining of
> the test execution.
>
> Also users can define custom ports in the port list and use them for
> srvice URL generation when it needs.
>
>
> On Thu, Oct 24, 2013 at 5:18 PM, Malintha Adikari <malin...@wso2.com>wrote:
>
>> Hi,
>>
>> The progress of the Test Automation Framework re-factoring is as follows.
>>
>> *1. Improved user population logic for product/platform execution
>> environments*
>>
>> Improved the user population logic for populate for both product and
>> platform execution modes. Users have to change the executionEnvironment
>> tag content inside the configurations to change the environment of
>> execution. Ex: if a user want to run the test for platform environment, the
>> content of the automation.xml file should be change like
>>
>> <configurations>
>> ......................
>> .....................
>> <!--
>> Change this to product/platform to execute test on specific
>> environment
>> -->
>> <executionEnvironment>*platform*</executionEnvironment>
>>
>> .....................
>> .....................
>> </configurations>
>>
>> Note: Only product and platform environments are allowed as valid
>> environments.
>>
>> Each execution mode supports multi-tenant and single tenant mode user
>> population. Ex: if the user want to run tests in multi-tenant enabled mode,
>> the configuration in *automation.xml* should be as follows
>>
>>
>> <configurations>
>> ....................
>> ...................
>> <!--
>> Change this to true/false to execute test with user mode or
>> tenant mode
>> -->
>> <multiTenantMode>*true*</multiTenantMode>
>> ...................
>> ..................
>>
>> </configurations>
>>
>>
>>
>> *2. Added check point to catch semantic errors in automation.xml and
>> generate an exception when it found such an semantic error*
>>
>> *Platform context* of the automation.xml file should be in consistent
>> with the execution environment. The content of the automation.xml file is
>> expected to be followed these rules to accepted it as correct
>> configurations.
>>
>> If user is set the execution mode as
>>
>> 1. Product
>>
>> a). There should be only one product group under platform
>> context.
>>
>> b). There should be at least one standalone typed instance
>> node in the product group.
>>
>>
>> 2. Platform
>>
>> a). Every product group should have a load balancer manager
>> (lb_manager) typed instance node
>>
>>
>>
>>
>> On Wed, Oct 16, 2013 at 11:32 AM, Malintha Adikari <malin...@wso2.com>wrote:
>>
>>> Hi,
>>>
>>>
>>> Completed implementing the user population logic which is one of the
>>> initial task of the test execution cycle. User polulation is supported for
>>> both multi- tenant mode and single-tenant mode.
>>>
>>> Implemented a logic to allow users to add custom propertied to the
>>> specific contexts in the automation.xml and refactored the XML schema file
>>> to validate the change. Now users are allowed to add custom properties for
>>> following context modules in automation.xml file
>>>
>>>
>>> - datasources->datasource
>>>
>>>
>>>
>>> - platform ->productGroup->instance
>>>
>>>
>>>
>>> - tools -> selenium -> browser
>>>
>>>
>>> Note - Adding custom elements for other modules or removing existing
>>> elements from any module will be invalidated by the XML schema file.
>>> According to the current validation logic one has to change the XML schema
>>> file in Automation Framework (path - *
>>> org.wso2.carbon.automation.engine/src/main/resources/automationXMLSchema.xsd
>>> *) to do any other changes to the automation.xml file.
>>>
>>>
>>>
>>>
>>>
>>
>
>
> --
> Software Engineer,
> WSO2 Inc. http://wso2.com
> (M) +94(71) 2312958
>
--
Dharshana Warusavitharana
Senior Software Engineer , Test Automation
WSO2 Inc. http://wso2.com
email : dharsha...@wso2.com <dharsha...@wso2.com>
Tel : +94 11 214 5345
Fax :+94 11 2145300
cell : +94772202595
blog : http://dharshanaw.blogspot.com
lean . enterprise . middleware
_______________________________________________
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev
