[JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions
by Bernard Labno (JIRA)
[ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.s... ]
Bernard Labno commented on ARQ-1572:
------------------------------------
But jrebel extensions would still have to add rebel.xml to that exploded archive, wouldn't it?
> Marry Persistence and JRebel extensions
> ---------------------------------------
>
> Key: ARQ-1572
> URL: https://issues.jboss.org/browse/ARQ-1572
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Persistence
> Affects Versions: persistence_1.0.0.Alpha6
> Reporter: Bernard Labno
> Assignee: Bartosz Majsak
> Fix For: persistence_1.0.0.next
>
>
> JRebel extension currently does not pick up changes in datasets.
> Here is how it works:
> If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once.
> JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*.
> Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel.
> Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions.
> It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes.
--
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
10 years, 3 months
[JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak commented on ARQ-1572:
-------------------------------------
It will work for WAR and that's what I have implemented already. Another
approach for handling EAR would be to put the jar as exploded archive in
lib directory. If that makes sense I will make it happen but we well need
to fix few small things here and there.
> Marry Persistence and JRebel extensions
> ---------------------------------------
>
> Key: ARQ-1572
> URL: https://issues.jboss.org/browse/ARQ-1572
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Persistence
> Affects Versions: persistence_1.0.0.Alpha6
> Reporter: Bernard Labno
> Assignee: Bartosz Majsak
> Fix For: persistence_1.0.0.next
>
>
> JRebel extension currently does not pick up changes in datasets.
> Here is how it works:
> If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once.
> JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*.
> Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel.
> Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions.
> It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes.
--
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
10 years, 3 months
[JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions
by Bernard Labno (JIRA)
[ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.s... ]
Bernard Labno commented on ARQ-1572:
------------------------------------
If it won't work with AS7 or Wildfly, then let's forget about that and stay with a workaround.
But if we can have a fixed name, like arquillian-persistence-datasets.jar, then I can enhance jrebel extension so that it could add auto generated rebel.xml to that archive.
> Marry Persistence and JRebel extensions
> ---------------------------------------
>
> Key: ARQ-1572
> URL: https://issues.jboss.org/browse/ARQ-1572
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Persistence
> Affects Versions: persistence_1.0.0.Alpha6
> Reporter: Bernard Labno
> Assignee: Bartosz Majsak
> Fix For: persistence_1.0.0.next
>
>
> JRebel extension currently does not pick up changes in datasets.
> Here is how it works:
> If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once.
> JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*.
> Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel.
> Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions.
> It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes.
--
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
10 years, 3 months
[JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak commented on ARQ-1572:
-------------------------------------
I could try sth like
{code:xml}
<module>
<java>lib/datasets</java>
</module>
{code}
in application.xml but it's too much manipulation of the test archive and it is not sure it will work everywhere. It certainly won't on [AS7|https://community.jboss.org/message/630869] or [Wildfly|https://issues.jboss.org/browse/WFLY-29].
> Marry Persistence and JRebel extensions
> ---------------------------------------
>
> Key: ARQ-1572
> URL: https://issues.jboss.org/browse/ARQ-1572
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Persistence
> Affects Versions: persistence_1.0.0.Alpha6
> Reporter: Bernard Labno
> Assignee: Bartosz Majsak
> Fix For: persistence_1.0.0.next
>
>
> JRebel extension currently does not pick up changes in datasets.
> Here is how it works:
> If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once.
> JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*.
> Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel.
> Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions.
> It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes.
--
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
10 years, 3 months
[JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak commented on ARQ-1572:
-------------------------------------
This will work nicely for JARs and WARs, but not for EARs, as there is no 'global classloader' for the ear package as far as I can say. I will keep it as jar in the lib/ folder with the fixed name, eg. 'arquillian-persistence-datasets.jar'. Would it work for you?
> Marry Persistence and JRebel extensions
> ---------------------------------------
>
> Key: ARQ-1572
> URL: https://issues.jboss.org/browse/ARQ-1572
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Persistence
> Affects Versions: persistence_1.0.0.Alpha6
> Reporter: Bernard Labno
> Assignee: Bartosz Majsak
> Fix For: persistence_1.0.0.next
>
>
> JRebel extension currently does not pick up changes in datasets.
> Here is how it works:
> If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once.
> JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*.
> Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel.
> Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions.
> It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes.
--
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
10 years, 3 months
[JBoss JIRA] (ARQ-1572) Marry Persistence and JRebel extensions
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-1572?page=com.atlassian.jira.plugin.s... ]
Work on ARQ-1572 started by Bartosz Majsak.
> Marry Persistence and JRebel extensions
> ---------------------------------------
>
> Key: ARQ-1572
> URL: https://issues.jboss.org/browse/ARQ-1572
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Persistence
> Affects Versions: persistence_1.0.0.Alpha6
> Reporter: Bernard Labno
> Assignee: Bartosz Majsak
> Fix For: persistence_1.0.0.next
>
>
> JRebel extension currently does not pick up changes in datasets.
> Here is how it works:
> If there is no target/jrebel-temp/.../*.meta file for given deployment then it assumes user wants full redeploy. If such file is present then deployment is blocked and tests are run at once.
> JRebel extension also checks if there is a rebel.xml file in the archive. If not then it generates such file based on exact content of the archive and explodes archive into target/jrebel-temp/*.
> Now the problem is that if resource is not in the archive then it will not be included in generated rebel.xml and thus won't be picked up by JRebel.
> Datasets are now automatically packed inside WEB-INF/lib/randomUUID.jar. JRebel will not substitute resources or classes from bundled libs. We could generate additional rebel.xml for that but I'd have to know what is the name of such archive and we would tightly couple both extensions.
> It would be easiest if Persistence ext would pack datasets directly into WE-INF/classes.
--
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
10 years, 3 months
[JBoss JIRA] (ARQ-1664) Provide custom table filter for seeding and cleaning databases
by Bartosz Majsak (JIRA)
[ https://issues.jboss.org/browse/ARQ-1664?page=com.atlassian.jira.plugin.s... ]
Bartosz Majsak updated ARQ-1664:
--------------------------------
Description: In order to resolve Foreign Key dependency and remove tables in the correct order DatabaseSequenceFilter has been introduced. As it's causing significant performance drop, especially in Oracle DB, it should be possible to define custom table filtering through SPI mechanism. This is also useful when seeding database. (was: In order to resolve Foreign Key dependency and remove tables in the correct order DatabaseSequenceFilter has been introduced. As itis causing significant performance drop, especially in Oracle DB, it should be possible to define custom table filtering through SPI mechanism. This is also useful when seeding database.)
> Provide custom table filter for seeding and cleaning databases
> --------------------------------------------------------------
>
> Key: ARQ-1664
> URL: https://issues.jboss.org/browse/ARQ-1664
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Persistence
> Affects Versions: persistence_1.0.0.Alpha6
> Reporter: Bartosz Majsak
> Assignee: Bartosz Majsak
> Fix For: persistence_1.0.0.next
>
>
> In order to resolve Foreign Key dependency and remove tables in the correct order DatabaseSequenceFilter has been introduced. As it's causing significant performance drop, especially in Oracle DB, it should be possible to define custom table filtering through SPI mechanism. This is also useful when seeding database.
--
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
10 years, 3 months
[JBoss JIRA] (ARQ-1655) NPE in WebDriverFactory.createInstance()
by Juergen Zimmermann (JIRA)
[ https://issues.jboss.org/browse/ARQ-1655?page=com.atlassian.jira.plugin.s... ]
Juergen Zimmermann commented on ARQ-1655:
-----------------------------------------
I just tried arquillian-drone-bom Version 1.3.0.Alpha1-SNAPSHOT: the issue is gone.
> NPE in WebDriverFactory.createInstance()
> ----------------------------------------
>
> Key: ARQ-1655
> URL: https://issues.jboss.org/browse/ARQ-1655
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Drone
> Affects Versions: drone_1.2.3.Final
> Reporter: Juergen Zimmermann
> Attachments: arquillian.xml, dependency-tree.txt, stacktrace.txt
>
>
> When I try to run my tests for Firefox (also Chrome and HtmlUnit) I'm getting the attached stacktrace.
> I also attach the output of "mvn dependency:tree" and arquillian.xml.
> My appserver is WildFly 8.0.0.Final.
--
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
10 years, 3 months
[JBoss JIRA] (ARQ-1654) Expose an ExecutorService to help Extension with multithreading
by Aslak Knutsen (JIRA)
[ https://issues.jboss.org/browse/ARQ-1654?page=com.atlassian.jira.plugin.s... ]
Aslak Knutsen commented on ARQ-1654:
------------------------------------
Currently I'm replicating the Context status from the Caller. So env should be == to where it was submitted from.
> Expose an ExecutorService to help Extension with multithreading
> ---------------------------------------------------------------
>
> Key: ARQ-1654
> URL: https://issues.jboss.org/browse/ARQ-1654
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Base Implementation
> Affects Versions: 1.1.3.Final
> Reporter: Aslak Knutsen
> Assignee: Aslak Knutsen
> Fix For: 2.0.0.Beta1
>
>
> Expose a Service to execute Callable's and Runnable's within a Inherited context.
> The general idea is to hide the complexity of reactivating the current Contextual information on the new Thread.
> ExecutorService needs to be a limited view of the java.utl.concurrent.ExecutorService to avoid 'abuse' like shutdown being called prematurely.
> The submit\(\*\) methods should probably be enough.
--
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
10 years, 3 months