[JBoss JIRA] (ARQ-1541) Pass portlet init params to PortletArchive
by Ken Finnigan (JIRA)
[ https://issues.jboss.org/browse/ARQ-1541?page=com.atlassian.jira.plugin.s... ]
Ken Finnigan closed ARQ-1541.
-----------------------------
Fix Version/s: (was: portal_1.1.0.next)
Resolution: Rejected
Unfortunately the way Descriptors work it's not possible at the moment to construct them in a piecemeal fashion.
This restriction therefore makes it not possible to iterate over a Map of elements to make calls on the descriptor
> Pass portlet init params to PortletArchive
> ------------------------------------------
>
> Key: ARQ-1541
> URL: https://issues.jboss.org/browse/ARQ-1541
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Portal
> Reporter: Ken Finnigan
> Assignee: Ken Finnigan
>
> Be able to pass a set of portlet init parameters to the createPortlet() methods of PortletArchive.
> This will allow the portlet configuration to be customized without a developer needing to parse the existing portlet.xml to do so.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (ARQ-1557) Align undeployment logic in a proper Arquillian way
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1557?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic updated ARQ-1557:
-----------------------------------
Attachment: brainstorming.jpg
> Align undeployment logic in a proper Arquillian way
> ---------------------------------------------------
>
> Key: ARQ-1557
> URL: https://issues.jboss.org/browse/ARQ-1557
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha2
> Reporter: Stefan Miklosovic
> Attachments: brainstorming.jpg
>
>
> Right now, undeployment logic for Droidium is bound to observer which observes with precedence -100 on AfterClass event in order to be sure that this observer will be treated as the latest one.
> Right now, we have to be sure that undeployment logic is treated lastly in AfterClass since Arquillian Drone destroys WebDriver instances in AfterClass as well and the destruction of WebDriver instance, in our case, means that Selendroid server will be uninstalled from Android device.
> Since the destruction of WebDriver instance itself is executed randomly in AfterClass regarding of execution time, we can not do undeployment of APKs on UnDeployDeployment event because when doing so, uninstallation of instrumented APK automatically kills Selendroid server process as well so that in turn means that subsequent trying to destroy WebDriver instance fails since Selendroid server is not running anymore and Drone talks to nobody.
> To be sure that all Selendroid servers are uninstalled so we can proceed with the uninstallation of deployments, where it should be done, there has to be a guarantee that all WebDriver instances were already destroyed.
> The solution here seems to be quite simple - we put some positive precedence for DroneDestructor (1) however by doing so, it could cause some backward compatibility issues with Drone extension.
> (1) https://github.com/arquillian/arquillian-extension-drone/blob/master/dron...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months