[JBoss JIRA] (WFLY-1560) PartialObjectActivationJarTestCase fails if ran after any of InflowFlatTestCase or TwoModulesOfDifferentTypeTestCase
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1560?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1560:
-----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> made a comment on [bug 985003|https://bugzilla.redhat.com/show_bug.cgi?id=985003]
> PartialObjectActivationJarTestCase fails if ran after any of InflowFlatTestCase or TwoModulesOfDifferentTypeTestCase
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1560
> URL: https://issues.jboss.org/browse/WFLY-1560
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 8.0.0.Alpha1
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
> Attachments: server_log_snippet.txt
>
>
> PartialObjectActivationJarTestCase fails if it runs after InflowFlatTestCase. It seems that the {{inflow2}} resource adapter is not fully unregistered by InflowFlatTestCase before PartialObjectActivationJarTestCase begins to start its own RA.
> Here is the server log snippet (DEBUG level):
> http://pastebin.test.redhat.com/147968
> Line 10 of this snippet corresponds to the invocation of {{setConfiguration("basic.xml");}} in PartialObjectActivationJarTestCase. Then, the server is apparently trying to activate {{MultipleConnectionFactory2Impl}} and {{MultipleAdminObject2Impl}} even though these are not involved in {{basic.xml}} of PartialObjectActivationJarTestCase at all. A suspicious exception is on line 19 there.
> I tried to put some delay between {{remove(address);}} and {{removeModule(defaultPath);}} in {{AbstractModuleDeploymentTestCaseSetup#tearDown()}} but it did not help. I also tried to put {{@Ignore}} to both test methods in the InflowFlatTestCase which also did not help, so it is evidently related only to the RA deployment/undeployment.
--
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, 4 months
[JBoss JIRA] (WFLY-1765) JDBC object store does not change LOG_STORE_TYPE attribute
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-1765?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-1765:
-----------------------------------------------
Ivo Studensky <istudens(a)redhat.com> made a comment on [bug 1002976|https://bugzilla.redhat.com/show_bug.cgi?id=1002976]
Description of problem:
The transaction subsystem when set up to the JDBC object store should keep a note about it in the log-store-type attribute, like the HornetQ object store does. It seems not to be consistent when the latter fills this attribute, but the former does not.
This bugzilla is a clone of WFLY-1765 for EAP.
> JDBC object store does not change LOG_STORE_TYPE attribute
> ----------------------------------------------------------
>
> Key: WFLY-1765
> URL: https://issues.jboss.org/browse/WFLY-1765
> Project: WildFly
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 8.0.0.Alpha3
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
>
> The transaction subsystem when set up to JDBC object store should keep a note about it in log-store-type attribute as HornetQ object store does. It seems not to be consistent when one object store does this, but others do not.
--
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, 4 months
[JBoss JIRA] (WFLY-1972) CLI command should not allow same runtime-name to be used at another deploy
by Emmanuel Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-1972?page=com.atlassian.jira.plugin.... ]
Emmanuel Hugonnet commented on WFLY-1972:
-----------------------------------------
A little more detail... The original issue was found in domain mode:
<deployments>
<deployment name="test.war.v1" runtime-name="test.war">
<content sha1="abc..."/>
</deployment>
<deployment name="test.war.v2" runtime-name="test.war">
<content sha1="def..."/>
</deployment>
</deployments>
<server-groups>
<server-group name="main-server-group" profile="full">
<deployments>
<deployment name="test.war.v1" runtime-name="test.war"/>
<deployment name="test.war.v2" runtime-name="test.war"/>
</deployments>
</server-group>
</server-groups>
The first <deployments> section is correct. In that section, only "name" must be unique.
But the two entries in <server-group><deployments> is a bug, as runtime-name must be unique there.
The test case listed in the original BZ description is the standalone equivalent of the above configuration, where runtime-name *must* be unique but is isn't being enforced.
> CLI command should not allow same runtime-name to be used at another deploy
> ---------------------------------------------------------------------------
>
> Key: WFLY-1972
> URL: https://issues.jboss.org/browse/WFLY-1972
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Emmanuel Hugonnet
> Assignee: Brian Stansberry
>
> Having two deployments with the same runtime-name in the domain content repository, so they can be deployed to different instances, is ok.
> Having two deployments with the same runtime name actually deployed to an instance is not (that's the issue here).
> Same for standalone.
--
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, 4 months
[JBoss JIRA] (LOGMGR-68) periodic-rotating-file-handler not rotating
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-68?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on LOGMGR-68:
-----------------------------------------------
Scott Mumford <smumford(a)redhat.com> made a comment on [bug 981544|https://bugzilla.redhat.com/show_bug.cgi?id=981544]
Added a draft release note.
Setting NEEDINFO flag to request technical verification from assignee, however, at this late stage, a verification from anyone involved in the resolution of this issue will be sufficient.
If the note above is inaccurate, please reset the 'requires_doc_text' flag to '?' and leave comment with corrections.
> periodic-rotating-file-handler not rotating
> -------------------------------------------
>
> Key: LOGMGR-68
> URL: https://issues.jboss.org/browse/LOGMGR-68
> Project: JBoss Log Manager
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 1.4.0.Final
> Environment: FreeBSD hostname 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r242434M
> Reporter: Alexander Yerenkow
> Assignee: Kyle Lape
> Fix For: 1.1.2.CR1, 1.3.3.Final, 1.4.2.Final, 1.5.0.Beta1, 2.0.0.Beta1
>
>
> During day there could be few restarts of JBoss 7.2.0
> If there was one, next day logs aren't rotated.
> edb.log (contains record from 22 apr till now)
> edb.log.2013-04-12 (contains record from 06 apr till 12)
> edb.log.2013-04-17 (contains record from 13 apr till 17)
> edb.log.2013-04-19 (contains record from 18 apr till 19)
> Can't see clear system;
> Here's my config:
> <periodic-rotating-file-handler name="EDB" autoflush="true">
> <formatter>
> <pattern-formatter pattern="%d %-5p [%c] (%t:%x) %s%E%n"/>
> </formatter>
> <file relative-to="jboss.server.log.dir" path="edb.log"/>
> <suffix value=".yyyy-MM-dd"/>
> <append value="true"/>
> </periodic-rotating-file-handler>
> This all worked as charm in 7.1.1 / 7.1.3.
> Should I run some tests/ gather some info to fix this?
--
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, 4 months