[JBoss JIRA] (LOGMGR-119) Wrong backup file names by PeriodicRotatingFileHandler when suffix "yyyy-ww"
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-119?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on LOGMGR-119:
------------------------------------------------
James Perkins <jperkins(a)redhat.com> changed the Status of [bug 1171020|https://bugzilla.redhat.com/show_bug.cgi?id=1171020] from NEW to CLOSED
> Wrong backup file names by PeriodicRotatingFileHandler when suffix "yyyy-ww"
> ----------------------------------------------------------------------------
>
> Key: LOGMGR-119
> URL: https://issues.jboss.org/browse/LOGMGR-119
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 1.5.2.Final
> Reporter: Osamu Nagano
> Assignee: James Perkins
>
> When {{PeriodicRotatingFileHandler}} with suffix "yyyy-ww" rotates a log file over a year, file that belongs to the new year is incorrectly named using the previous year.
> Here is a demonstrating test code supposed to be pasted into {{src/test/java/org/jboss/logmanager/handlers/PeriodicSizeRotatingFileHandlerTests.java}}. It mimics a record started from 2014-12-24 and the resulting backup log file is named {{rotating-file-handler.log.2014-01}}. It should be 2015 instead.
> {code}
> /*
> * Run with the following command:
> * mvn compile test -Dtest=PeriodicSizeRotatingFileHandlerTests#testPeriodicRotateWeekOfYear
> */
> @Test
> public void testPeriodicRotateWeekOfYear() throws Exception {
> SimpleDateFormat fmt = periodFormatMap.get(Calendar.WEEK_OF_YEAR);
> Calendar cal = Calendar.getInstance(java.util.TimeZone.getTimeZone("GMT"));
>
> PeriodicRotatingFileHandler handler = new PeriodicRotatingFileHandler();
> handler.setAutoFlush(true);
> handler.setFormatter(new PatternFormatter("%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"));
> handler.setSuffix("." + fmt.toPattern());
> handler.setFile(logFile);
>
> cal.set(Calendar.YEAR, 2014);
> cal.set(Calendar.MONTH, 12 - 1);
> cal.set(Calendar.DAY_OF_MONTH, 24);
> cal.set(Calendar.HOUR_OF_DAY, 12);
>
> for (int i = 0; i < 14; i++) {
> long tim = cal.getTimeInMillis();
> String fdate = fmt.format(tim);
> ExtLogRecord record = createLogRecord("%02d th formatted date is %s", i, fdate);
> record.setMillis(tim);
> handler.publish(record);
>
> cal.add(Calendar.DAY_OF_MONTH, 1);
> }
>
> handler.close();
>
> for (String logFile : BASE_LOG_DIR.list()) {
> System.out.println(logFile);
> }
> Assert.assertTrue("Dummy.", true);
> }
> {code}
> And here is the result of the test method.
> {code}
> % ll logs
> total 12K
> -rw-r--r--. 1 onagano onagano 228 Dec 5 17:09 rotating-file-handler.log
> -rw-r--r--. 1 onagano onagano 532 Dec 5 17:09 rotating-file-handler.log.2014-01
> -rw-r--r--. 1 onagano onagano 0 Dec 5 17:09 rotating-file-handler.log.2014-49
> -rw-r--r--. 1 onagano onagano 304 Dec 5 17:09 rotating-file-handler.log.2014-52
> % cat logs/rotating-file-handler.log.2014-52
> 2014-12-24 21:09:43,921 INFO [null] (main) 00 th formatted date is 2014-52
> 2014-12-25 21:09:43,921 INFO [null] (main) 01 th formatted date is 2014-52
> 2014-12-26 21:09:43,921 INFO [null] (main) 02 th formatted date is 2014-52
> 2014-12-27 21:09:43,921 INFO [null] (main) 03 th formatted date is 2014-52
> % cat logs/rotating-file-handler.log.2014-01
> 2014-12-28 21:09:43,921 INFO [null] (main) 04 th formatted date is 2014-01
> 2014-12-29 21:09:43,921 INFO [null] (main) 05 th formatted date is 2014-01
> 2014-12-30 21:09:43,921 INFO [null] (main) 06 th formatted date is 2014-01
> 2014-12-31 21:09:43,921 INFO [null] (main) 07 th formatted date is 2014-01
> 2015-01-01 21:09:43,921 INFO [null] (main) 08 th formatted date is 2015-01
> 2015-01-02 21:09:43,921 INFO [null] (main) 09 th formatted date is 2015-01
> 2015-01-03 21:09:43,921 INFO [null] (main) 10 th formatted date is 2015-01
> % cat logs/rotating-file-handler.log
> 2015-01-04 21:09:43,921 INFO [null] (main) 11 th formatted date is 2015-02
> 2015-01-05 21:09:43,921 INFO [null] (main) 12 th formatted date is 2015-02
> 2015-01-06 21:09:43,921 INFO [null] (main) 13 th formatted date is 2015-02
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JASSIST-241) VerifyError: Expecting a stackmap frame - Switch case statement Java 7
by Patson Luk (JIRA)
[ https://issues.jboss.org/browse/JASSIST-241?page=com.atlassian.jira.plugi... ]
Patson Luk updated JASSIST-241:
-------------------------------
Issue Type: Bug (was: Feature Request)
> VerifyError: Expecting a stackmap frame - Switch case statement Java 7
> ----------------------------------------------------------------------
>
> Key: JASSIST-241
> URL: https://issues.jboss.org/browse/JASSIST-241
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.19.0-GA
> Environment: jdk7
> Reporter: Patson Luk
> Assignee: Shigeru Chiba
>
> This could be a duplicate of issue 215 and 205.
> Tested it on the master (3.19.0-GA) with java 7. Running the below class
> {code}
> import java.util.Random;
> import javassist.ClassPool;
> import javassist.CtClass;
> import javassist.CtMethod;
> public class TestDriver {
> public static void main(String[] args) throws Exception {
> ClassPool pool = ClassPool.getDefault();
> CtClass cc = pool.get("TestClass");
>
> CtMethod testMethod = cc.getMethod("test", "(Ljava/lang/Object;)V");
> testMethod.insertAfter("System.out.println(\"inserted!\");");
> cc.toClass();
> //invoke it
> TestClass.test(new Object());
> }
> }
> class TestClass {
> public static void test(Object o) {
> //part 1
> if (o == null) {
> return;
> }
> //part 2
> int oper = new Random().nextInt();
> switch (oper) {
> case 1:
> break;
> }
> }
> }
> {code}
>
> Triggers error message as below:
> {quote}
> Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 9 in method TestClass.test(Ljava/lang/Object;)V at offset 1
> at TestDriver.main(TestDriver.java:19)
> {quote}
> *Please take note that:*
> # This is observed on Java 7. When the same code is run on Java 6, it is fine
> # Both the "part 1" - return statement (commented in the code above) and "part 2" - switch/case statement have to be there to trigger the error. If either of those are commented out, then the code runs fine
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JASSIST-241) VerifyError: Expecting a stackmap frame - Switch case statement Java 7
by Patson Luk (JIRA)
Patson Luk created JASSIST-241:
----------------------------------
Summary: VerifyError: Expecting a stackmap frame - Switch case statement Java 7
Key: JASSIST-241
URL: https://issues.jboss.org/browse/JASSIST-241
Project: Javassist
Issue Type: Feature Request
Affects Versions: 3.19.0-GA
Environment: jdk7
Reporter: Patson Luk
Assignee: Shigeru Chiba
This could be a duplicate of issue 215 and 205.
Tested it on the master (3.19.0-GA) with java 7. Running the below class
{code}
import java.util.Random;
import javassist.ClassPool;
import javassist.CtClass;
import javassist.CtMethod;
public class TestDriver {
public static void main(String[] args) throws Exception {
ClassPool pool = ClassPool.getDefault();
CtClass cc = pool.get("TestClass");
CtMethod testMethod = cc.getMethod("test", "(Ljava/lang/Object;)V");
testMethod.insertAfter("System.out.println(\"inserted!\");");
cc.toClass();
//invoke it
TestClass.test(new Object());
}
}
class TestClass {
public static void test(Object o) {
//part 1
if (o == null) {
return;
}
//part 2
int oper = new Random().nextInt();
switch (oper) {
case 1:
break;
}
}
}
{code}
Triggers error message as below:
{quote}
Exception in thread "main" java.lang.VerifyError: Expecting a stackmap frame at branch target 9 in method TestClass.test(Ljava/lang/Object;)V at offset 1
at TestDriver.main(TestDriver.java:19)
{quote}
*Please take note that:*
# This is observed on Java 7. When the same code is run on Java 6, it is fine
# Both the "part 1" - return statement (commented in the code above) and "part 2" - switch/case statement have to be there to trigger the error. If either of those are commented out, then the code runs fine
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-683) ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped
by Abel Marrero Santos (JIRA)
[ https://issues.jboss.org/browse/DROOLS-683?page=com.atlassian.jira.plugin... ]
Abel Marrero Santos updated DROOLS-683:
---------------------------------------
Attachment: catalina.out
Minimal tomcat log for this issue.
> ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped
> ---------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-683
> URL: https://issues.jboss.org/browse/DROOLS-683
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.2.0.CR4
> Environment: Ubuntu Linux x64 & Tomcat 7
> Reporter: Abel Marrero Santos
> Assignee: Marco Rietveld
> Labels: Exception, REST,, Weld
> Attachments: catalina.out
>
>
> An exception is raised when the REST method to create a new organizational unit is invoked.
> To reproduce the issue you only have to POST to /rest/organizationalunits a JSON like:
> {
> "name":"testorg",
> "description":"",
> "owner":"test",
> "repositories":[]
> }
> and then check the job result or check the server logs.
> It works fine in version 6.2.0.CR3
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-683) ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped
by Marco Rietveld (JIRA)
[ https://issues.jboss.org/browse/DROOLS-683?page=com.atlassian.jira.plugin... ]
Marco Rietveld commented on DROOLS-683:
---------------------------------------
[~marrerosantos] Thanks for raising the bug. Would mind attaching a text file that contains the stack trace/exception that you saw? That would help a lot!
> ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped
> ---------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-683
> URL: https://issues.jboss.org/browse/DROOLS-683
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.2.0.CR4
> Environment: Ubuntu Linux x64 & Tomcat 7
> Reporter: Abel Marrero Santos
> Assignee: Marco Rietveld
> Labels: Exception, REST,, Weld
>
> An exception is raised when the REST method to create a new organizational unit is invoked.
> To reproduce the issue you only have to POST to /rest/organizationalunits a JSON like:
> {
> "name":"testorg",
> "description":"",
> "owner":"test",
> "repositories":[]
> }
> and then check the job result or check the server logs.
> It works fine in version 6.2.0.CR3
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4171) Provide an html5 archetype for wildfly
by Rafael Benevides (JIRA)
[ https://issues.jboss.org/browse/WFLY-4171?page=com.atlassian.jira.plugin.... ]
Rafael Benevides commented on WFLY-4171:
----------------------------------------
Check for html5 blank archetype
> Provide an html5 archetype for wildfly
> --------------------------------------
>
> Key: WFLY-4171
> URL: https://issues.jboss.org/browse/WFLY-4171
> Project: WildFly
> Issue Type: Feature Request
> Reporter: Fred Bricon
> Assignee: Rafael Benevides
>
> We'd like to provide a Wildfly-ified version of the html5 archetype in JBoss Central, for JBoss Tools and Developer Studio, The current versions we serve right now are :
> * org.jboss.aerogear.archetypes:jboss-html5-mobile-archetype:7.1.3.Final
> * org.jboss.archetype.wfk:jboss-html5-mobile-archetype:2.6.0.Final
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-3502) Handle session attribute serialization incompatiblities
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3502?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-3502:
------------------------------------
I think it is sufficient for now to invalidate sessions whose serialized form is not compatible with the current class definition. We can always make this behavior configurable later.
> Handle session attribute serialization incompatiblities
> -------------------------------------------------------
>
> Key: WFLY-3502
> URL: https://issues.jboss.org/browse/WFLY-3502
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 8.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> When a new release of a web application is deployed to an existing cluster, any changes to the object placed in the web session can cause serialization incompatibilities. To handle this cleanly, we typically recommend that users leverage isolated cluster and mod_cluster load balancing groups (or mod_jk domains) to transition users to the new version of an application.
> For simple applications, this might be overkill. It might be acceptable/preferable to create a new session in the event of a serialization incompatibility, rather than failing the request. We should allow developers to configure this behavior per-application.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (DROOLS-683) ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/DROOLS-683?page=com.atlassian.jira.plugin... ]
Michael Anstis reassigned DROOLS-683:
-------------------------------------
Assignee: Marco Rietveld (was: Mark Proctor)
> ContextNotActiveException: WELD-001303 No active contexts for scope type javax.enterprise.context.RequestScoped
> ---------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-683
> URL: https://issues.jboss.org/browse/DROOLS-683
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.2.0.CR4
> Environment: Ubuntu Linux x64 & Tomcat 7
> Reporter: Abel Marrero Santos
> Assignee: Marco Rietveld
> Labels: Exception, REST,, Weld
>
> An exception is raised when the REST method to create a new organizational unit is invoked.
> To reproduce the issue you only have to POST to /rest/organizationalunits a JSON like:
> {
> "name":"testorg",
> "description":"",
> "owner":"test",
> "repositories":[]
> }
> and then check the job result or check the server logs.
> It works fine in version 6.2.0.CR3
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months