[JBoss JIRA] (AS7-5648) Unwanted system properties in a connectiondefinition/adminobject from another connectiondefinition/adminobject in the same resource adapter
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-5648?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri commented on AS7-5648:
--------------------------------------
Maybe I'm not understanding...but it's exactly the idea: having metadatas that is results of merging raxml and cmd and use this merged metadatas (w/ all defaults) to create resourceAdapter classes. BTW in this service doesn't make sense to merge ijcmd that should be always empty because this service is triggered only for RA defined in standalone.xml, not having an ironjacamr.xml inside the rar.
But maybe I'm not understanding the problem you are experiencing and I so I can't hint you. You can contact me on IRC (maeste on #jboss-as7 in Freenode), or if it's impossible for you, give me more context here, giving me an example of polluted metadatas and why you consider them wrong.
regards
S.
> Unwanted system properties in a connectiondefinition/adminobject from another connectiondefinition/adminobject in the same resource adapter
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-5648
> URL: https://issues.jboss.org/browse/AS7-5648
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.1.3.Final (EAP), 7.2.0.Alpha1
> Reporter: Simone Gotti
> Assignee: Stefano Maestri
>
> With the effects of issue AS7-5644 I noticed that the connection definition with missing system properties, instead of failing, was using properties from another connection definition (with a lot of consequent problems)
> After a lot of analysis the problem is that the org.jboss.jca.common.api.metadata.ra.Connector's system properties are polluted with the merged values of the user specified connectiondefinitions/adminobjects and these system properties's defaults are inserted in the user defined connectiondefinition/adminobject that don't define them.
> I think that the wrong operation is in the start method of org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.java:
> cmd = (new Merger()).mergeConnectorWithCommonIronJacamar(raxml, cmd);
> I think that merging should be between IronJacamar -> Connector and not raxml -> Connector:
> cmd = (new Merger()).mergeConnectorWithCommonIronJacamar(ijmd, cmd);
> After this change I see that the Connector is clean and no unwanted default are added inside my connectiondefinitions/adminobjects
> I'll attach the possible pull request.
--
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
13 years, 9 months
[JBoss JIRA] (AS7-5586) Memory leak with JSF ManagedBean
by Mauricio Fenoglio (JIRA)
Mauricio Fenoglio created AS7-5586:
--------------------------------------
Summary: Memory leak with JSF ManagedBean
Key: AS7-5586
URL: https://issues.jboss.org/browse/AS7-5586
Project: Application Server 7
Issue Type: Bug
Components: JSF
Affects Versions: 7.1.2.Final (EAP), 7.1.1.Final, 7.2.0.Alpha1
Environment: Initializing Mojarra 2.1.7-jbossorg-2 (20120412-0335) and all native Jboss JSF impl
Reporter: Mauricio Fenoglio
Assignee: Stan Silvert
All JSF ManagedBean are not destroyed and generate a great memory problem.
This happen for session and view Scopes
Nor are running @PreDestroy
It is not possible to have production environments with jsf, so it is a blocker issue.
--
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
13 years, 9 months
[JBoss JIRA] (JBRULES-3639) Improve Drools Fusion Documentation of Event expiration mechanism
by Matteo Mortari (JIRA)
Matteo Mortari created JBRULES-3639:
---------------------------------------
Summary: Improve Drools Fusion Documentation of Event expiration mechanism
Key: JBRULES-3639
URL: https://issues.jboss.org/browse/JBRULES-3639
Project: Drools
Issue Type: Patch
Security Level: Public (Everyone can see)
Components: drools-compiler (fusion), drools-core (fusion)
Affects Versions: 5.4.0.Final
Environment: Eclipse 3.7 SR2, Jboss Tools, Drools 5.4.0.Final, Win XP. Attaching Eclipse project
Reporter: Matteo Mortari
Assignee: Mark Proctor
h4. Executive Summary
This is to kindly request, if you can please improve the Drools Fusion documentation to explain more specifically about “Automatic Event Lifecycle Management”, and the basis how Event expiration actually works. Possibly by means of simple examples, or blueprints detailing CEP best implementation patterns specifically for Fusion, could greatly benefit.
Thank you, I love RedHat and the JBoss Community :) but trying to understand completely Fusion’s Event expiration is making me crazy :P
h4. Rationale
The documentation in [par. “2.5.2. Stream Mode”| http://docs.jboss.org/drools/release/5.4.0.Final/drools-fusion-docs/html_...] is imho vague in the second requirement, specifically the generic statement “the use of non-time-synchronized streams may result in some unexpected results”. Especially it seems to me not only streams must be time-synchronized, but +also streams and the session clock must be strictly in-sync?+
Take for instance the attached Eclipse project, to replicate one un-expected behavior - I’m specifically not raising this JIRA as a bug, because of the aforementioned “vagueness” in the doc, I don’t have specific evidence this is strictly a bug.
(!) The assumption in this application: Events are inserted with a lag if compared to the session clock to simulate a communication lag and slight delay. However, all Events are inserted in strict chronological order. The issue here is: *because Events, despite in chronological order, are inserted slightly late if compared to the session clock, some unexpected behavior of the After LHS operator occurs*
There is a simple rule that checks for two Event of type Message to happen within 1minute delay.
{code:title=Sample.drl|borderStyle=solid}
declare Message
@role(event)
@timestamp (timestamp)
end
rule "asd"
when
$m1 : Message()
$m2 : Message(this after[0, 1m] $m1, this != $m1)
then
System.out.println("x");
end
{code}
Events are being inserted in strict chronological order. A first Event of type Message is inserted. Pseudo clock is advanced rapidly. Then a second Event of type Message is inserted having timestamp {{\+1}} second to the previous one.
In the Audit log, also attached, you will see the very first Event, matched as {{$m1}}, get expired and retracted immediately after the rule has fired. This is OK: now the very first Event can no longer match in this rule, and because is the only rule available, gets expired and retracted. As you would expect from the documentation. Happily.
This analogously repeats in the application and reflected in the audit log.
Now skip to the *last* Event of type Message inserted. The consequence of this last Event being inserted is that the rule had fired again; analogously, this is the only Event of type Message remaining in the working memory. Happily.
As the pseudo clock gets advanced rapidly, now no more Events are inserted. When the pseudo clock reaches {{\+60}} seconds from the +session time+ when this last Event was inserted, the Event is retracted. This is the issue and the unexpected behavior. I have NOT specified {{window:time(1m)}} in my rule, but seems to behaving like that. Shouldn’t the engine wait for a very next Event *of any type* to be inserted into the working memory, to evaluate the current stream timestamp and therefore infer this Event can now safely be expired and retracted?
The rule, by the way it’s written, would check to see if two Events of type Message are available within a 1minute of timespan. While instead, seems to me by the unexpected results, this also implicitly stating {{window:time(1m)}} being the Max of the parameters for the time constraint operators available in the rule.
If you can explain better the Event expiration mechanism and improve the Documentation, it would greatly help to understand for instance why this scenario behaves in this (from my perspective) unexpected behavior.
I seize the chance to thank you once again, Ciao
--
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
13 years, 9 months
[JBoss JIRA] (AS7-5417) fix messaging paths
by Jeff Mesnil (JIRA)
Jeff Mesnil created AS7-5417:
--------------------------------
Summary: fix messaging paths
Key: AS7-5417
URL: https://issues.jboss.org/browse/AS7-5417
Project: Application Server 7
Issue Type: Feature Request
Components: JMS
Reporter: Jeff Mesnil
Assignee: Jeff Mesnil
messaging subsystems defines paths used to store HornetQ journal and metadata.
The resources are not exposed in a consistent fashion:
{noformat}
[standalone@localhost:9999 /] cd /subsystem=messaging/hornetq-server=default
[standalone@localhost:9999 hornetq-server=default] ./:read-children-names(child-type=path)
{
"outcome" => "success",
"result" => []
}
[standalone@localhost:9999 hornetq-server=default] ./:read-children-names(child-type=path)
{
"outcome" => "success",
"result" => []
}
[standalone@localhost:9999 hornetq-server=default] ./path=*:read-resource
{
"outcome" => "failed",
"failure-description" => "JBAS014739: No handler for read-resource at address [
(\"subsystem\" => \"messaging\"),
(\"hornetq-server\" => \"default\"),
(\"path\" => \"*\")
]",
"rolled-back" => true
}
[standalone@localhost:9999 hornetq-server=default] ./path=*:read-resource-description
{
"outcome" => "failed",
"failure-description" => "JBAS014739: No handler for read-resource-description at address [
(\"subsystem\" => \"messaging\"),
(\"hornetq-server\" => \"default\"),
(\"path\" => \"*\")
]",
"rolled-back" => true
}
[standalone@localhost:9999 hornetq-server=default] ./:read-resource-description(recursive=true, recursive-depth=1)
{
"outcome" => "success",
"result" => {
"description" => "A HornetQ server instance.",
...
"children" => {
...
"path" => {
"description" => "A filesystem path pointing to one of the locations where HornetQ stores persistent data.",
"model-description" => {
"journal-directory" => {
"description" => "The directory in which the message journal lives. The default is ${jboss.server.data.dir}/messaging/journal.",
"attributes" => {
"path" => {
"type" => STRING,
"description" => "The actual filesystem path. Treated as an absolute path, unless the 'relative-to' attribute is specified, in which case the value is treated as relative to that path. <p>If treated as an absolute path, the actual runtime pathname specified by the value of this attribute will be determined as follows: </p>If this value is already absolute, then the value is directly used. Otherwise the runtime pathname is resolved in a system-dependent way. On UNIX systems, a relative pathname is made absolute by resolving it against the current user directory. On Microsoft Windows systems, a relative pathname is made absolute by resolving it against the current directory of the drive named by the pathname, if any; if not, it is resolved against the current user directory.",
"expressions-allowed" => true,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
},
"relative-to" => {
"type" => STRING,
"description" => "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute. The standard paths provided by the system include:<ul><li>jboss.home - the root directory of the JBoss AS distribution</li><li>user.home - user's home directory</li><li>user.dir - user's current working directory</li><li>java.home - java installation directory</li><li>jboss.server.base.dir - root directory for an individual server instance</li><li>jboss.server.data.dir - directory the server will use for persistent data file storage</li><li>jboss.server.log.dir - directory the server will use for log file storage</li><li>jboss.server.tmp.dir - directory the server will use for temporary file storage</li><li>jboss.domain.servers.dir - directory under which a host controller will create the working area for individual server instances</li></ul>",
"expressions-allowed" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
}
},
"operations" => undefined,
"children" => {}
},
"paging-directory" => {
"description" => "The directory where page files are stored. The default is ${jboss.server.data.dir}/messaging/paging.",
"attributes" => {
"path" => {
"type" => STRING,
"description" => "The actual filesystem path. Treated as an absolute path, unless the 'relative-to' attribute is specified, in which case the value is treated as relative to that path. <p>If treated as an absolute path, the actual runtime pathname specified by the value of this attribute will be determined as follows: </p>If this value is already absolute, then the value is directly used. Otherwise the runtime pathname is resolved in a system-dependent way. On UNIX systems, a relative pathname is made absolute by resolving it against the current user directory. On Microsoft Windows systems, a relative pathname is made absolute by resolving it against the current directory of the drive named by the pathname, if any; if not, it is resolved against the current user directory.",
"expressions-allowed" => true,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
},
"relative-to" => {
"type" => STRING,
"description" => "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute. The standard paths provided by the system include:<ul><li>jboss.home - the root directory of the JBoss AS distribution</li><li>user.home - user's home directory</li><li>user.dir - user's current working directory</li><li>java.home - java installation directory</li><li>jboss.server.base.dir - root directory for an individual server instance</li><li>jboss.server.data.dir - directory the server will use for persistent data file storage</li><li>jboss.server.log.dir - directory the server will use for log file storage</li><li>jboss.server.tmp.dir - directory the server will use for temporary file storage</li><li>jboss.domain.servers.dir - directory under which a host controller will create the working area for individual server instances</li></ul>",
"expressions-allowed" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
}
},
"operations" => undefined,
"children" => {}
},
"large-messages-directory" => {
"description" => "The directory in which large messages are stored. The default is ${jboss.server.data.dir}/messaging/largemessages.",
"attributes" => {
"path" => {
"type" => STRING,
"description" => "The actual filesystem path. Treated as an absolute path, unless the 'relative-to' attribute is specified, in which case the value is treated as relative to that path. <p>If treated as an absolute path, the actual runtime pathname specified by the value of this attribute will be determined as follows: </p>If this value is already absolute, then the value is directly used. Otherwise the runtime pathname is resolved in a system-dependent way. On UNIX systems, a relative pathname is made absolute by resolving it against the current user directory. On Microsoft Windows systems, a relative pathname is made absolute by resolving it against the current directory of the drive named by the pathname, if any; if not, it is resolved against the current user directory.",
"expressions-allowed" => true,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
},
"relative-to" => {
"type" => STRING,
"description" => "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute. The standard paths provided by the system include:<ul><li>jboss.home - the root directory of the JBoss AS distribution</li><li>user.home - user's home directory</li><li>user.dir - user's current working directory</li><li>java.home - java installation directory</li><li>jboss.server.base.dir - root directory for an individual server instance</li><li>jboss.server.data.dir - directory the server will use for persistent data file storage</li><li>jboss.server.log.dir - directory the server will use for log file storage</li><li>jboss.server.tmp.dir - directory the server will use for temporary file storage</li><li>jboss.domain.servers.dir - directory under which a host controller will create the working area for individual server instances</li></ul>",
"expressions-allowed" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
}
},
"operations" => undefined,
"children" => {}
},
"bindings-directory" => {
"description" => "The directory in which the bindings journal lives. The default is ${jboss.server.data.dir}/messaging/bindings.",
"attributes" => {
"path" => {
"type" => STRING,
"description" => "The actual filesystem path. Treated as an absolute path, unless the 'relative-to' attribute is specified, in which case the value is treated as relative to that path. <p>If treated as an absolute path, the actual runtime pathname specified by the value of this attribute will be determined as follows: </p>If this value is already absolute, then the value is directly used. Otherwise the runtime pathname is resolved in a system-dependent way. On UNIX systems, a relative pathname is made absolute by resolving it against the current user directory. On Microsoft Windows systems, a relative pathname is made absolute by resolving it against the current directory of the drive named by the pathname, if any; if not, it is resolved against the current user directory.",
"expressions-allowed" => true,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
},
"relative-to" => {
"type" => STRING,
"description" => "The name of another previously named path, or of one of the standard paths provided by the system. If 'relative-to' is provided, the value of the 'path' attribute is treated as relative to the path specified by this attribute. The standard paths provided by the system include:<ul><li>jboss.home - the root directory of the JBoss AS distribution</li><li>user.home - user's home directory</li><li>user.dir - user's current working directory</li><li>java.home - java installation directory</li><li>jboss.server.base.dir - root directory for an individual server instance</li><li>jboss.server.data.dir - directory the server will use for persistent data file storage</li><li>jboss.server.log.dir - directory the server will use for log file storage</li><li>jboss.server.tmp.dir - directory the server will use for temporary file storage</li><li>jboss.domain.servers.dir - directory under which a host controller will create the working area for individual server instances</li></ul>",
"expressions-allowed" => false,
"nillable" => true,
"min-length" => 1L,
"max-length" => 2147483647L,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "all-services"
}
},
"operations" => undefined,
"children" => {}
}
},
"min-occurs" => 4,
"max-occurs" => 4
},
...
}
}
}
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-5648) Unwanted system properties in a connectiondefinition/adminobject from another connectiondefinition/adminobject in the same resource adapter
by Simone Gotti (JIRA)
[ https://issues.jboss.org/browse/AS7-5648?page=com.atlassian.jira.plugin.s... ]
Simone Gotti edited comment on AS7-5648 at 9/27/12 11:30 AM:
-------------------------------------------------------------
Hi Stefano,
from what I understand, that instruction is doing the inverse, it's merging the raxml (standalone.xml/domain.xml) inside cmd which is META-INF/ra.xml of the resource adapter.
Isn't the operation of merging the defaults inside the raxml done inside the initAndInject method called by createObjectsAndInjectValue of org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.java (Object om = initAndInject(mcfClz, cdMeta.getConfigProperties(), cl); at line 1676) ?
In fact, during my analysis when initAndInject is called the values of the cdMeta.getConfigProperties() are polluted withns all the bad default took from the raxml.
Thanks!
Bye!
was (Author: simone.gotti):
Hi Stefano,
from what I understand, that instruction is doing the inverse, it's merging the raxml (standalone.xml/domain.xml) inside cmd which is META-INF/ra.xml of the resource adapter.
The instruction of merging the defaults inside the raxml isn't done inside the initAndInject method called by createObjectsAndInjectValue of org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.java (Object om = initAndInject(mcfClz, cdMeta.getConfigProperties(), cl); at line 1676) ?
In fact, during my analysis when initAndInject is called the values of the cdMeta.getConfigProperties() are polluted withns all the bad default took from the raxml.
Thanks!
Bye!
> Unwanted system properties in a connectiondefinition/adminobject from another connectiondefinition/adminobject in the same resource adapter
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-5648
> URL: https://issues.jboss.org/browse/AS7-5648
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.1.3.Final (EAP), 7.2.0.Alpha1
> Reporter: Simone Gotti
> Assignee: Stefano Maestri
>
> With the effects of issue AS7-5644 I noticed that the connection definition with missing system properties, instead of failing, was using properties from another connection definition (with a lot of consequent problems)
> After a lot of analysis the problem is that the org.jboss.jca.common.api.metadata.ra.Connector's system properties are polluted with the merged values of the user specified connectiondefinitions/adminobjects and these system properties's defaults are inserted in the user defined connectiondefinition/adminobject that don't define them.
> I think that the wrong operation is in the start method of org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.java:
> cmd = (new Merger()).mergeConnectorWithCommonIronJacamar(raxml, cmd);
> I think that merging should be between IronJacamar -> Connector and not raxml -> Connector:
> cmd = (new Merger()).mergeConnectorWithCommonIronJacamar(ijmd, cmd);
> After this change I see that the Connector is clean and no unwanted default are added inside my connectiondefinitions/adminobjects
> I'll attach the possible pull request.
--
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
13 years, 9 months
[JBoss JIRA] (AS7-5648) Unwanted system properties in a connectiondefinition/adminobject from another connectiondefinition/adminobject in the same resource adapter
by Simone Gotti (JIRA)
[ https://issues.jboss.org/browse/AS7-5648?page=com.atlassian.jira.plugin.s... ]
Simone Gotti commented on AS7-5648:
-----------------------------------
Hi Stefano,
from what I understand, that instruction is doing the inverse, it's merging the raxml (standalone.xml/domain.xml) inside cmd which is META-INF/ra.xml of the resource adapter.
The instruction of merging the defaults inside the raxml isn't done inside the initAndInject method called by createObjectsAndInjectValue of org.jboss.jca.deployers.common.AbstractResourceAdapterDeployer.java (Object om = initAndInject(mcfClz, cdMeta.getConfigProperties(), cl); at line 1676) ?
In fact, during my analysis when initAndInject is called the values of the cdMeta.getConfigProperties() are polluted withns all the bad default took from the raxml.
Thanks!
Bye!
> Unwanted system properties in a connectiondefinition/adminobject from another connectiondefinition/adminobject in the same resource adapter
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-5648
> URL: https://issues.jboss.org/browse/AS7-5648
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.1.3.Final (EAP), 7.2.0.Alpha1
> Reporter: Simone Gotti
> Assignee: Stefano Maestri
>
> With the effects of issue AS7-5644 I noticed that the connection definition with missing system properties, instead of failing, was using properties from another connection definition (with a lot of consequent problems)
> After a lot of analysis the problem is that the org.jboss.jca.common.api.metadata.ra.Connector's system properties are polluted with the merged values of the user specified connectiondefinitions/adminobjects and these system properties's defaults are inserted in the user defined connectiondefinition/adminobject that don't define them.
> I think that the wrong operation is in the start method of org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.java:
> cmd = (new Merger()).mergeConnectorWithCommonIronJacamar(raxml, cmd);
> I think that merging should be between IronJacamar -> Connector and not raxml -> Connector:
> cmd = (new Merger()).mergeConnectorWithCommonIronJacamar(ijmd, cmd);
> After this change I see that the Connector is clean and no unwanted default are added inside my connectiondefinitions/adminobjects
> I'll attach the possible pull request.
--
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
13 years, 9 months
[JBoss JIRA] (AS7-4554) AS 7 + Wicket: ClassNotFoundException: org.jboss.msc.service.ServiceName on deserialization
by Ondrej Zizka (JIRA)
Ondrej Zizka created AS7-4554:
---------------------------------
Summary: AS 7 + Wicket: ClassNotFoundException: org.jboss.msc.service.ServiceName on deserialization
Key: AS7-4554
URL: https://issues.jboss.org/browse/AS7-4554
Project: Application Server 7
Issue Type: Bug
Reporter: Ondrej Zizka
Assignee: Ondrej Zizka
This belongs under quickstarts.
ClassNotFoundException: org.jboss.msc.service.ServiceName from [Module "deployment.ROOT.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
STR:
* See http://test-ondra.rhcloud.com/
* Add some record, then go to / , refresh few times.
* Wicket will redirect you e.g. to /?4
* When you change that to a lower number, Wicket tries to get the old page state by deserializing.
* That's why it happens during deserialization.
See Gist for few more info: https://gist.github.com/2409907
{code}
Root cause:
java.lang.ClassNotFoundException: org.jboss.msc.service.ServiceName from [Module "deployment.ROOT.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.apache.wicket.application.AbstractClassResolver.resolveClass(AbstractClassResolver.java:108)
at org.apache.wicket.serialize.java.JavaSerializer$ClassResolverObjectInputStream.resolveClass(JavaSerializer.java:216)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1592)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1513)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1749)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:368)
at java.util.HashMap.readObject(HashMap.java:1047)
at java.lang.reflect.Method.invoke(Method.java:616)
at java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:988)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1865)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1770)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1963)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1887)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1770)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1963)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1887)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1770)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1963)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1887)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1770)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1963)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1887)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1770)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1963)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1887)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1770)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1963)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1887)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1770)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1346)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:368)
at org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:120)
at org.apache.wicket.pageStore.DefaultPageStore.deserializePage(DefaultPageStore.java:388)
at org.apache.wicket.pageStore.DefaultPageStore.getPage(DefaultPageStore.java:127)
at org.apache.wicket.page.PageStoreManager$SessionEntry.getPage(PageStoreManager.java:192)
at org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPage(PageStoreManager.java:327)
at org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager.java:102)
at org.apache.wicket.page.PageManagerDecorator.getPage(PageManagerDecorator.java:50)
at org.apache.wicket.page.PageAccessSynchronizer$2.getPage(PageAccessSynchronizer.java:257)
at org.apache.wicket.DefaultMapperContext.getPageInstance(DefaultMapperContext.java:117)
at org.apache.wicket.request.handler.PageProvider.getStoredPage(PageProvider.java:292)
at org.apache.wicket.request.handler.PageProvider.isNewPageInstance(PageProvider.java:205)
at org.apache.wicket.request.mapper.AbstractBookmarkableMapper.mapHandler(AbstractBookmarkableMapper.java:349)
at org.apache.wicket.request.mapper.MountedMapper.mapHandler(MountedMapper.java:366)
at org.apache.wicket.request.mapper.CompoundRequestMapper.mapHandler(CompoundRequestMapper.java:157)
at org.apache.wicket.request.cycle.RequestCycle.mapUrlFor(RequestCycle.java:404)
at org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:146)
at org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:167)
at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:781)
at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:255)
at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:212)
at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:283)
at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:185)
at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:241)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50)
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:154)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930)
at java.lang.Thread.run(Thread.java:679)
Complete stack:
java.lang.RuntimeException: Could not deserialize object using: class org.apache.wicket.serialize.java.JavaSerializer$ClassResolverObjectInputStream
at org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:137)
at org.apache.wicket.pageStore.DefaultPageStore.deserializePage(DefaultPageStore.java:388)
at org.apache.wicket.pageStore.DefaultPageStore.getPage(DefaultPageStore.java:127)
at org.apache.wicket.page.PageStoreManager$SessionEntry.getPage(PageStoreManager.java:192)
at org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPage(PageStoreManager.java:327)
at org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager.java:102)
at org.apache.wicket.page.PageManagerDecorator.getPage(PageManagerDecorator.java:50)
at org.apache.wicket.page.PageAccessSynchronizer$2.getPage(PageAccessSynchronizer.java:257)
at org.apache.wicket.DefaultMapperContext.getPageInstance(DefaultMapperContext.java:117)
at org.apache.wicket.request.handler.PageProvider.getStoredPage(PageProvider.java:292)
at org.apache.wicket.request.handler.PageProvider.isNewPageInstance(PageProvider.java:205)
at org.apache.wicket.request.mapper.AbstractBookmarkableMapper.mapHandler(AbstractBookmarkableMapper.java:349)
at org.apache.wicket.request.mapper.MountedMapper.mapHandler(MountedMapper.java:366)
at org.apache.wicket.request.mapper.CompoundRequestMapper.mapHandler(CompoundRequestMapper.java:157)
at org.apache.wicket.request.cycle.RequestCycle.mapUrlFor(RequestCycle.java:404)
at org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:146)
at org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:167)
at org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:781)
at org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:64)
at org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java:255)
at org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:212)
at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:283)
at org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:185)
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] (AS7-5648) Unwanted system properties in a connectiondefinition/adminobject from another connectiondefinition/adminobject in the same resource adapter
by Stefano Maestri (JIRA)
[ https://issues.jboss.org/browse/AS7-5648?page=com.atlassian.jira.plugin.s... ]
Stefano Maestri commented on AS7-5648:
--------------------------------------
That merge is correct because it's merging raxml metadatas (aka those got from standalone.xml) and not ijmd (metadasta got from ironjacamar.xml).
they could have defaults, even if not specified by user, according to resource description in DMR. What you can do is to check if these values are only ones for which a default is defined. To get them just execute in CLI
/subsystem=resource-adapters/resource-adapter=*:read-resource-description(recursive=true)
and have a look to attributes w/ default defined. For example in connection-definition use-java-context has default = true
"use-java-context" => {
"type" => BOOLEAN,
"description" => "Setting this to false will bind the object into global JNDI",
"expressions-allowed" => true,
"nillable" => true,
"default" => true,
"access-type" => "read-write",
"storage" => "configuration",
"restart-required" => "no-services"
},
> Unwanted system properties in a connectiondefinition/adminobject from another connectiondefinition/adminobject in the same resource adapter
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: AS7-5648
> URL: https://issues.jboss.org/browse/AS7-5648
> Project: Application Server 7
> Issue Type: Bug
> Components: JCA
> Affects Versions: 7.1.3.Final (EAP), 7.2.0.Alpha1
> Reporter: Simone Gotti
> Assignee: Stefano Maestri
>
> With the effects of issue AS7-5644 I noticed that the connection definition with missing system properties, instead of failing, was using properties from another connection definition (with a lot of consequent problems)
> After a lot of analysis the problem is that the org.jboss.jca.common.api.metadata.ra.Connector's system properties are polluted with the merged values of the user specified connectiondefinitions/adminobjects and these system properties's defaults are inserted in the user defined connectiondefinition/adminobject that don't define them.
> I think that the wrong operation is in the start method of org.jboss.as.connector.services.resourceadapters.deployment.ResourceAdapterXmlDeploymentService.java:
> cmd = (new Merger()).mergeConnectorWithCommonIronJacamar(raxml, cmd);
> I think that merging should be between IronJacamar -> Connector and not raxml -> Connector:
> cmd = (new Merger()).mergeConnectorWithCommonIronJacamar(ijmd, cmd);
> After this change I see that the Connector is clean and no unwanted default are added inside my connectiondefinitions/adminobjects
> I'll attach the possible pull request.
--
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
13 years, 9 months