[JBoss JIRA] (JBEE-149) Patch Taglibs Bug 33934
by Kevin Formsma (JIRA)
Kevin Formsma created JBEE-149:
----------------------------------
Summary: Patch Taglibs Bug 33934
Key: JBEE-149
URL: https://issues.jboss.org/browse/JBEE-149
Project: JBoss JavaEE Spec APIs
Issue Type: Bug
Components: jboss-jstl-api
Affects Versions: jboss-jstl-api_1.2_spec-1.0.5.Final
Reporter: Kevin Formsma
Assignee: Shelly McGowan
Taglibs fixed a bug where SetTag would retain references to the target object, causing pooled SetTag instances to have much higher memory usage when the target object is large. When using many web threads in JBoss 7.2.2, our heap grows due to these objects being associated to pooled SetTags.
https://issues.apache.org/bugzilla/show_bug.cgi?id=33934
Can this patch be fixed in the jboss fork of taglibs as well?
--
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, 9 months
[JBoss JIRA] (WFLY-3040) Missing modules
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3040?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3040:
----------------------------------------
The org.jboss.genericjms.provider module needs to be provided by the user, containing the necessary binaries provided by the provider (e.g. Tibco) they wish to integrate.
> Missing modules
> ---------------
>
> Key: WFLY-3040
> URL: https://issues.jboss.org/browse/WFLY-3040
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Affects Versions: 8.0.0.Final
> Environment: Windows 64 bits
> Reporter: David Cabillic
> Assignee: Thomas Diesler
>
> I listed modules with links to missing ones :
> || module || missing module ||
> | org.infinispan.client.hotrod | com.google.protobuf |
> | org.jboss.as.aggregate | org.jboss.as.managed-beans |
> | org.jboss.genericjms | org.jboss.genericjms.provider |
--
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, 9 months
[JBoss JIRA] (WFLY-2581) Provide API for use by ejb-security-interceptors quick start.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2581?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-2581:
-----------------------------------
Description:
The quick start accesses the currently authenticated user, unfortunately this representation is with a bunch of internal implementation classes.
• org.jboss.as.domain.management.security.RealmUser.
• org.jboss.as.security.remoting.RemotingContext.
• org.jboss.as.controller.security.SubjectUserInfo
The first problem is the RemotingContext, we use it internally to associate the remoting connection with the thread processing the request, the only reason we really use it is to obtain the identity of the user associated with the connection, we may be better simplifying this down to just associate a simple ConnectionSecurityContext with the thread instead.
Secondly once we have used the identity associated with the connection we clear the association, this is probably the wrong way round and instead we should be setting something to say we have used the identity.
The SubjectUserInfo is essentially the ConnectionSecurityContext I mention above, we need a simple representation of this that can be used.
Finally there is RealmUser, we should also add RealmGroup - these two classes just need to be in their own public module or inherit from something that is.
As a closing point should these be marked as deprecated? Security services are being re-worked in WildFly and this whole quick start is just an alternative solution to the new services.
was:The quick start accesses the currently authenticated user, unfortunately this representation is with a bunch of internal implementation classes.
> Provide API for use by ejb-security-interceptors quick start.
> -------------------------------------------------------------
>
> Key: WFLY-2581
> URL: https://issues.jboss.org/browse/WFLY-2581
> Project: WildFly
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 8.0.1.Final
>
>
> The quick start accesses the currently authenticated user, unfortunately this representation is with a bunch of internal implementation classes.
> • org.jboss.as.domain.management.security.RealmUser.
> • org.jboss.as.security.remoting.RemotingContext.
> • org.jboss.as.controller.security.SubjectUserInfo
> The first problem is the RemotingContext, we use it internally to associate the remoting connection with the thread processing the request, the only reason we really use it is to obtain the identity of the user associated with the connection, we may be better simplifying this down to just associate a simple ConnectionSecurityContext with the thread instead.
> Secondly once we have used the identity associated with the connection we clear the association, this is probably the wrong way round and instead we should be setting something to say we have used the identity.
> The SubjectUserInfo is essentially the ConnectionSecurityContext I mention above, we need a simple representation of this that can be used.
> Finally there is RealmUser, we should also add RealmGroup - these two classes just need to be in their own public module or inherit from something that is.
> As a closing point should these be marked as deprecated? Security services are being re-worked in WildFly and this whole quick start is just an alternative solution to the new services.
--
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, 9 months
[JBoss JIRA] (WFLY-3040) Missing modules
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3040?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-3040:
------------------------------
Component/s: Build System
(was: OSGi)
> Missing modules
> ---------------
>
> Key: WFLY-3040
> URL: https://issues.jboss.org/browse/WFLY-3040
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Build System
> Affects Versions: 8.0.0.Final
> Environment: Windows 64 bits
> Reporter: David Cabillic
> Assignee: Thomas Diesler
>
> I listed modules with links to missing ones :
> || module || missing module ||
> | org.infinispan.client.hotrod | com.google.protobuf |
> | org.jboss.as.aggregate | org.jboss.as.managed-beans |
> | org.jboss.genericjms | org.jboss.genericjms.provider |
--
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, 9 months
[JBoss JIRA] (WFLY-3046) Not possible change the object store type from hornetq to jdbc via cli commands
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3046?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-3046:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1038993
> Not possible change the object store type from hornetq to jdbc via cli commands
> -------------------------------------------------------------------------------
>
> Key: WFLY-3046
> URL: https://issues.jboss.org/browse/WFLY-3046
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Final
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
>
> When you have set the object store to be type of hornetq and then you change your mind to set it for jdbc object store the jboss-cli permits this operation but no change is propagated to model and XML file.
> How to reproduce:
> # ./bin/standalone.xml (start eap 6.2.0.GA)
> # ./bin/jboss-cli.sh -c (connect to running eap)
> # /subsystem=transactions:write-attribute(name=use-hornetq-store, value=true)
> # :reload# /subsystem=transactions/log-store=log-store:read-attribute(name=type)# /subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)# :reload
> # /subsystem=transactions/log-store=log-store:read-attribute(name=type)
> The object store stays to be set to hornetq and no change happens in the standalone.xml file.
--
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, 9 months
[JBoss JIRA] (WFLY-3046) Not possible change the object store type from hornetq to jdbc via cli commands
by Ivo Studensky (JIRA)
[ https://issues.jboss.org/browse/WFLY-3046?page=com.atlassian.jira.plugin.... ]
Ivo Studensky commented on WFLY-3046:
-------------------------------------
A comment taken from BZ:
You need to disable {{use-hornetq-store}} first as {{TransactionSubsystemXMLPersister}} prefers the hornetq store to the jdbc store which is also wrong, see the code snippet below:
{code:java|title=TransactionSubsystemXMLPersister.java}
if(node.hasDefined(CommonAttributes.USEHORNETQSTORE) && node.get(CommonAttributes.USEHORNETQSTORE).asBoolean()) {
..
} else if (node.hasDefined(CommonAttributes.USE_JDBC_STORE) && node.get(CommonAttributes.USE_JDBC_STORE).asBoolean()) {
..
}
{code}
Other possibility would be to enhance {{use-hornetq-store}} and {{use-jdbc-store}} write handlers to disable the opposite option.
> Not possible change the object store type from hornetq to jdbc via cli commands
> -------------------------------------------------------------------------------
>
> Key: WFLY-3046
> URL: https://issues.jboss.org/browse/WFLY-3046
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Transactions
> Affects Versions: 8.0.0.Final
> Reporter: Ivo Studensky
> Assignee: Ivo Studensky
>
> When you have set the object store to be type of hornetq and then you change your mind to set it for jdbc object store the jboss-cli permits this operation but no change is propagated to model and XML file.
> How to reproduce:
> # ./bin/standalone.xml (start eap 6.2.0.GA)
> # ./bin/jboss-cli.sh -c (connect to running eap)
> # /subsystem=transactions:write-attribute(name=use-hornetq-store, value=true)
> # :reload# /subsystem=transactions/log-store=log-store:read-attribute(name=type)# /subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)# :reload
> # /subsystem=transactions/log-store=log-store:read-attribute(name=type)
> The object store stays to be set to hornetq and no change happens in the standalone.xml file.
--
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, 9 months
[JBoss JIRA] (WFLY-3046) Not possible change the object store type from hornetq to jdbc via cli commands
by Ivo Studensky (JIRA)
Ivo Studensky created WFLY-3046:
-----------------------------------
Summary: Not possible change the object store type from hornetq to jdbc via cli commands
Key: WFLY-3046
URL: https://issues.jboss.org/browse/WFLY-3046
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Transactions
Affects Versions: 8.0.0.Final
Reporter: Ivo Studensky
Assignee: Ivo Studensky
When you have set the object store to be type of hornetq and then you change your mind to set it for jdbc object store the jboss-cli permits this operation but no change is propagated to model and XML file.
How to reproduce:
# ./bin/standalone.xml (start eap 6.2.0.GA)
# ./bin/jboss-cli.sh -c (connect to running eap)
# /subsystem=transactions:write-attribute(name=use-hornetq-store, value=true)
# :reload# /subsystem=transactions/log-store=log-store:read-attribute(name=type)# /subsystem=transactions:write-attribute(name=use-jdbc-store, value=true)# :reload
# /subsystem=transactions/log-store=log-store:read-attribute(name=type)
The object store stays to be set to hornetq and no change happens in the standalone.xml file.
--
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, 9 months
[JBoss JIRA] (AS7-5132) Connection timeout to local port 9999 with clustered AS 7.1.1.Final
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-5132?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-5132:
----------------------------------------------
Tomaz Cerar <tcerar(a)redhat.com> changed the Status of [bug 900988|https://bugzilla.redhat.com/show_bug.cgi?id=900988] from ASSIGNED to CLOSED
> Connection timeout to local port 9999 with clustered AS 7.1.1.Final
> -------------------------------------------------------------------
>
> Key: AS7-5132
> URL: https://issues.jboss.org/browse/AS7-5132
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 7.1.1.Final
> Environment: Fedora 17 on Amazon EC2
> Reporter: Jack Lund
> Assignee: Emanuel Muckenhuber
> Labels: as7, cluster, domain
> Fix For: 7.1.3.Final (EAP), EAP 6.1.0.Alpha (7.2.0.Final)
>
>
> A clustered configuration of two AS 7 instances has an issue with the connection to port 9999 timing out when starting up. The instances are configured as per https://docs.jboss.org/author/display/AS71/AS7+Cluster+Howto. On startup, we get the following error randomly for one or more of the server instances:
> {quote}
> [Server:server-two] 16:36:03,492 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC00001: Failed to start service jboss.host.controller.client: org.jboss.msc.service.StartException in service jboss.host.controller.client: java.net.ConnectException: JBAS012144: Could not connect to remote://10.108.25.156:9999. The connection timed out
> [Server:server-two] at org.jboss.as.server.mgmt.domain.HostControllerServerClient.start(HostControllerServerClient.java:161) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
> [Server:server-two] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_05]
> [Server:server-two] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_05]
> [Server:server-two] at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_05]
> [Server:server-two] Caused by: java.net.ConnectException: JBAS012144: Could not connect to remote://nephele-beta-jboss1:9999. The connection timed out
> [Server:server-two] at org.jboss.as.protocol.ProtocolChannelClient.connectSync(ProtocolChannelClient.java:155) [jboss-as-protocol-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two] at org.jboss.as.server.mgmt.domain.HostControllerServerConnection.openChannel(HostControllerServerConnection.java:158) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two] at org.jboss.as.server.mgmt.domain.HostControllerServerConnection.connect(HostControllerServerConnection.java:86) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two] at org.jboss.as.server.mgmt.domain.HostControllerServerClient.start(HostControllerServerClient.java:135) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> [Server:server-two] ... 5 more
> {quote}
> We usually have to restart the master server instance 10-15 times before all server instances start up without this error, which suggests a race condition between the listening and connecting sockets. Note that this is running on the equivalent of a single-core, fairly slow machine currently, which may be exacerbating the effects.
--
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, 9 months