[JBoss JIRA] Created: (JBAS-6532) TCLFilter doesn't work in jboss 5 with war's in any documented way
by robert lazarski (JIRA)
TCLFilter doesn't work in jboss 5 with war's in any documented way
------------------------------------------------------------------
Key: JBAS-6532
URL: https://jira.jboss.org/jira/browse/JBAS-6532
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Logging
Affects Versions: JBossAS-5.0.0.GA
Environment: jdk 6, linux
Reporter: robert lazarski
Assignee: Scott M Stark
Reading this doc:
http://www.jboss.org/community/docs/DOC-12203
Indicates a *-exp.war syntax is needed for TCLFilter war use, but there are no files of that type on my system running jboss 5. I've tried all the possible combinations I can think of, posted the problem to the forum, and the result is always that the file sizes and contents of the log files generated are exactly the same for the different war's, ie, no separated content. Here's my current config:
<appender name="penguinLog" class="org.apache.log4j.FileAppender">
<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"></errorHandler>
<param name="Append" value="false"/>
<param name="File" value="${jboss.server.home.dir}/log/penguinLog.log"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p %c{1} %m%n"/>
</layout>
<filter class="org.jboss.logging.filter.TCLFilter">
<param name="AcceptOnMatch" value="true"/>
<param name="DeployURL" value="penguin"/>
</filter>
</appender>
<appender name="wtfLog" class="org.apache.log4j.FileAppender">
<errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"></errorHandler>
<param name="Append" value="false"/>
<param name="File" value="${jboss.server.home.dir}/log/wtfLog.log"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%d %-5p %c{1} %m%n"/>
</layout>
<filter class="org.jboss.logging.filter.TCLFilter">
<param name="AcceptOnMatch" value="true"/>
<param name="DeployURL" value="wtf-exp.war"/>
</filter>
</appender>
<root>
<appender-ref ref="CONSOLE"/>
<appender-ref ref="FILE"/>
<appender-ref ref="penguinLog"/>
<appender-ref ref="wtfLog"/>
</root>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Created: (AS7-969) JVM resource description doesn't match operation return value
by Heiko Braun (JIRA)
JVM resource description doesn't match operation return value
-------------------------------------------------------------
Key: AS7-969
URL: https://issues.jboss.org/browse/AS7-969
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Reporter: Heiko Braun
Assignee: Brian Stansberry
Fix For: 7.0.0.CR1
Reading a JVM resource description returns this:
{noformat}
[domain@localhost:9999 /] /server-group=main-server-group/jvm=default:read-resource
{
"outcome" => "success",
"result" => {
"type" => undefined,
"agent-lib" => undefined,
"agent-path" => undefined,
"env-classpath-ignored" => undefined,
"environment-variables" => undefined,
"heap-size" => "64m",
"max-heap-size" => "512m",
"java-agent" => undefined,
"java-home" => undefined,
"jvm-options" => undefined,
"permgen-size" => undefined,
"max-permgen-size" => undefined,
"stack-size" => undefined
},
"compensating-operation" => undefined
}
{noformat}
However the resource description looks different.
It describes certain elements as children,
some of the are missing at all ('max-heap-size"')
{noformat}
[domain@localhost:9999 /] /server-group=main-server-group/jvm=default:read-resource-description
{
"outcome" => "success",
"result" => {
"type" => OBJECT,
"description" => "The JVM configuration for managed processes / servers.",
"attributes" => {
"agent-lib" => {
"type" => STRING,
"description" => "The JVM agent lib.",
"access-type" => "read-write",
"storage" => "configuration"
},
"agent-path" => {
"type" => STRING,
"description" => "The JVM agent path.",
"access-type" => "read-write",
"storage" => "configuration"
},
"env-classpath-ignored" => {
"type" => BOOLEAN,
"description" => "Ignore the environment classpath.",
"access-type" => "read-write",
"storage" => "configuration"
},
"environment-variables" => {
"type" => LIST,
"value-type" => UNDEFINED,
"description" => "The JVM environment variables.",
"access-type" => "read-write",
"storage" => "configuration"
},
"java-agent" => {
"type" => STRING,
"description" => "The java agent.",
"access-type" => "read-write",
"storage" => "configuration"
},
"java-home" => {
"type" => STRING,
"description" => "The java home",
"access-type" => "read-write",
"storage" => "configuration"
},
"jvm-options" => {
"type" => LIST,
"value-type" => STRING,
"description" => "The JVM options.",
"access-type" => "read-only",
"storage" => "configuration"
},
"stack-size" => {
"type" => STRING,
"description" => "The JVM stack size settings.",
"access-type" => "read-write",
"storage" => "configuration"
},
"type" => {
"type" => STRING,
"description" => "The JVM type can be either SUN or IBM",
"access-type" => "read-only",
"storage" => "configuration"
}
},
"children" => {
"heap-size" => {
"type" => OBJECT,
"description" => "The Heap size settings allocated by the JVM.",
"attributes" => {
"size" => STRING,
"max-size" => STRING
}
},
"permgen-size" => {
"type" => OBJECT,
"description" => "The JVM PermGen settings.",
"attributes" => {
"size" => STRING,
"max-size" => STRING
}
}
}
},
"compensating-operation" => undefined
}
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (AS7-799) Wrong Classloader Used When Deserializing Persisted Sessions
by Benjamin Browning (JIRA)
Wrong Classloader Used When Deserializing Persisted Sessions
------------------------------------------------------------
Key: AS7-799
URL: https://issues.jboss.org/browse/AS7-799
Project: Application Server 7
Issue Type: Bug
Affects Versions: 7.0.0.Beta3
Reporter: Benjamin Browning
Assignee: Jason Greene
The org.jboss.as.web:main module's classloader is being used when deserializing persisted sessions instead of the deployment's classloader. This leads to errors like the one below when any classes are referenced in the session that aren't in the dependency list of org/jboss/as/web/main/module.xml.
21:02:50,824 ERROR [org.apache.catalina.session.ManagerBase] (MSC service thread 1-1) ClassNotFoundException while loading persisted sessions: java.lang.ClassNotFoundException: org.jboss.weld.context.conversation.ConversationIdGenerator from [Module "org.jboss.as.web:main" from local module loader @32b0bad7 (roots: /Users/bbrowning/src/torquebox/integration-tests/target/integ-dist/jboss/modules)]: java.lang.ClassNotFoundException: org.jboss.weld.context.conversation.ConversationIdGenerator from [Module "org.jboss.as.web:main" from local module loader @32b0bad7 (roots: /Users/bbrowning/src/torquebox/integration-tests/target/integ-dist/jboss/modules)]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:184) [:1.0.0.Beta17]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:357) [:1.0.0.Beta17]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:329) [:1.0.0.Beta17]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:306) [:1.0.0.Beta17]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:100) [:1.0.0.Beta17]
at java.lang.Class.forName0(Native Method) [:1.6.0_24]
at java.lang.Class.forName(Class.java:247) [:1.6.0_24]
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:603) [:1.6.0_24]
at org.apache.catalina.util.CustomObjectInputStream.resolveClass(CustomObjectInputStream.java:78) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1574) [:1.6.0_24]
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495) [:1.6.0_24]
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731) [:1.6.0_24]
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328) [:1.6.0_24]
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350) [:1.6.0_24]
at org.apache.catalina.session.StandardSession.readObject(StandardSession.java:1429) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.session.StandardSession.readObjectData(StandardSession.java:934) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.session.StandardManager.doLoad(StandardManager.java:395) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.session.StandardManager.load(StandardManager.java:322) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.session.StandardManager.start(StandardManager.java:633) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.ContainerBase.setManager(ContainerBase.java:459) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.apache.catalina.core.StandardContext.start(StandardContext.java:3776) [jbossweb-7.0.0.Beta11.jar:7.0.0.Beta3]
at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:61) [jboss-as-web-7.0.0.Beta3.jar:7.0.0.Beta3]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (JBRULES-2831) The zips should contain a README_DEPENDENCIES.txt file generated by the build
by Geoffrey De Smet (JIRA)
The zips should contain a README_DEPENDENCIES.txt file generated by the build
-----------------------------------------------------------------------------
Key: JBRULES-2831
URL: https://issues.jboss.org/browse/JBRULES-2831
Project: Drools
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 5.1.1.FINAL
Reporter: Geoffrey De Smet
Assignee: Geoffrey De Smet
Priority: Optional
Fix For: FUTURE
We're removing the current README_DEPENDENCIES.txt file because it contains a lot of incorrect, misleading info.
But we'd still like to give the users that file, but correct.
The only decent way to keep it correct is to generate it of the build.
In theory we could just take the output of
mvn dependency:tree
but maybe maven has a better report.
Until we do that, the users will have to rely on our released poms, which contain correct info.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (JBRULES-2823) Sliding window of length type does not accumulate/collect correctly with multiple objects in constraints
by Mary Ellen Bench (JIRA)
Sliding window of length type does not accumulate/collect correctly with multiple objects in constraints
--------------------------------------------------------------------------------------------------------
Key: JBRULES-2823
URL: https://jira.jboss.org/browse/JBRULES-2823
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: All
Affects Versions: 5.1.1.FINAL
Environment: Windows XP Java
Reporter: Mary Ellen Bench
Assignee: Mark Proctor
When using sliding windows and a constraint that filters by an input object, it does not properly create a window for each constraints, instead one window shared by both rules which leads to undesirable affects (ie a shared sliding window filtered down to less #s).
Please also see the drools post:
http://drools-java-rules-engine.46999.n3.nabble.com/DROOLS-problem-with-s...
It is best to show the rule and output to explain it:
Background:
"I have been working with sliding windows, and they do not appear to work properly in DROOLS 5.1.1 or I am misunderstanding how they work. My goal is to have the last X number of samples averaged or summed. I've tried two mechanism, the accumulate/from, and the collect, and they both behave similarly wrong (or different than I expect), but this was much easier to follow so I've posted it for help.
The way I have the code structured, I receive values for two nodes, 1 and 2 every second or two, which each contain random values. After each value received I pass the CPUReportEvent and fire the rules. The results are bizarre. Sometimes it resets back to 1 count, sometimes it keeps the value to the previous one. It seems to also fire both rules when really only one should've been triggered? Can someone explain the results and how to adjust it to work for my specs? Thanks!
I can't see into the accumulate function, so here's the collect function, but they perform identically. "
package com.sample
import com.sample.DroolsTest.Message;
import com.sample.DroolsInput;
import com.sample.CPUReportEvent;
import com.ComEntity;
import java.util.Iterator
import java.util.ArrayList
declare CPUReportEvent
// declare a fact type as an event, default is 'fact'
@role( event )
end
rule "collect with length window"
no-loop true
when
$comEntity : ComEntity()
$list : ArrayList () from collect(
CPUReportEvent(comEntity == $comEntity)
over window:length(3) )
then
System.out.print("Entity " + $comEntity.getName() + " fired of count " + $list.size() + " value");
Double sum = 0.0;
Double count = 0.0;
for(Iterator it = $list.iterator();it.hasNext();) {
CPUReportEvent report = (CPUReportEvent) it.next();
System.out.print(" " + report.getAmount());
sum = sum + report.getAmount();
count = count + 1.0;
}
if (count > 0.0)
{
Double avg = (sum / count);
System.out.print(" - Sum " + sum + " avg " + avg + " count " + count);
}
System.out.println();
end
RESULTS:
Node1 : 7.0
Entity Node2 fired of count 0 value
Entity Node1 fired of count 1 value 7.0 - Sum 7.0 avg 7.0 count 1.0
Node2 : 94.0
Entity Node2 fired of count 1 value 94.0 - Sum 94.0 avg 94.0 count 1.0
Node1 : 43.0
Entity Node1 fired of count 2 value 7.0 43.0 - Sum 50.0 avg 25.0 count 2.0
Node2 : 85.0
Entity Node2 fired of count 2 value 94.0 85.0 - Sum 179.0 avg 89.5 count 2.0
Entity Node1 fired of count 1 value 43.0 - Sum 43.0 avg 43.0 count 1.0
Node1 : 88.0
Entity Node2 fired of count 1 value 85.0 - Sum 85.0 avg 85.0 count 1.0
Entity Node1 fired of count 2 value 43.0 88.0 - Sum 131.0 avg 65.5 count 2.0
Node2 : 47.0
Entity Node2 fired of count 2 value 85.0 47.0 - Sum 132.0 avg 66.0 count 2.0
Entity Node1 fired of count 1 value 88.0 - Sum 88.0 avg 88.0 count 1.0
Node1 : 39.0
Entity Node2 fired of count 1 value 47.0 - Sum 47.0 avg 47.0 count 1.0
Entity Node1 fired of count 2 value 88.0 39.0 - Sum 127.0 avg 63.5 count 2.0
Node1 : 0.0
Entity Node1 fired of count 2 value 39.0 0.0 - Sum 39.0 avg 19.5 count 2.0
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (AS7-951) :installed-drivers-list should not be enabled for subsystem=datasource in domain mode
by Heiko Rupp (JIRA)
:installed-drivers-list should not be enabled for subsystem=datasource in domain mode
-------------------------------------------------------------------------------------
Key: AS7-951
URL: https://issues.jboss.org/browse/AS7-951
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Reporter: Heiko Rupp
[15:05:42] <+pilhuhn> [domain@localhost:9999 subsystem=datasources] :installed-drivers-list
[15:05:42] <+pilhuhn> {
[15:05:42] <+pilhuhn> "outcome" => "success",
[15:05:42] <+pilhuhn> "result" => undefined,
[15:05:56] <+pilhuhn> Or is that a domain vs standalone thing again? Let me check that
[15:06:20] <hbraun> in domain mode this needs to executed against a host
[15:07:01] <+pilhuhn> hm. Does that make sense?
[15:07:23] <hbraun> yes, the drives can be installed as deployments
[15:07:34] <hbraun> which is a host thing
[15:08:34] <+pilhuhn> not server-group?
[15:08:52] <hbraun> no, host
[15:09:02] <+pilhuhn> And then I would expect that the /profile=x/subysy=ds/ would not support :installed-driver-list
[15:09:02] <hbraun> the host installes it as a runtime component
[15:09:15] <hbraun> yes, that's right
[15:09:22] <hbraun> it shouldn't
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month
[JBoss JIRA] Created: (JBWEB-206) New JSESSIONID for every request in JBossAS7 causing no sticky HttpSession
by Robert Baty (JIRA)
New JSESSIONID for every request in JBossAS7 causing no sticky HttpSession
--------------------------------------------------------------------------
Key: JBWEB-206
URL: https://issues.jboss.org/browse/JBWEB-206
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossWeb-7.0.0.CR4
Environment: JBossAS 7.0.0.Final server running on a Windows 7 desktop with Oracle/Sun JDK 1.6.0_26. Issue is occurring with Firefox 5, IE9 and IE8 browsers.
Reporter: Robert Baty
Assignee: Remy Maucherat
Deploying a JEE application to JBossAS7 when trying to get HttpSession data using request.getSession() a new session is created each time an no data is persisted. Tracking this down I seem to be seeing a
Set-Cookie JSESSIONID=nTokSr2GnHgUTPZnbMtpgjfS; Version=1; Path="/rjb"
in every response with no Cookie being maintained for the next request.
I have tried this on a number of browsers. It seems to be happening in Firefox 5 and Internet Explorer 8, 9. I do seem to work with an older Firefox 3.6 browser however.
After thinking I have something wrong with my browser I deployed the application to JBossAS6 and used the same Firefox 5 browser and am seeing the JSESSIONID being established and session data being maintained between pages in memory.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month