[JBoss JIRA] (AS7-1338) Remote JNDI support for AS7
by jaikiran pai (JIRA)
[ https://issues.jboss.org/browse/AS7-1338?page=com.atlassian.jira.plugin.s... ]
jaikiran pai commented on AS7-1338:
-----------------------------------
Ed what does your code look like? And when you say after each "message" what kind of message do you mean?
Also is this an Windows OS? And do those log messages affect any functionality? Just trying to understand what the problem might be.
> Remote JNDI support for AS7
> ---------------------------
>
> Key: AS7-1338
> URL: https://issues.jboss.org/browse/AS7-1338
> Project: Application Server 7
> Issue Type: Task
> Components: Naming
> Reporter: Richard Opalka
> Assignee: John Bailey
> Priority: Critical
> Labels: eap6_prd_req
> Fix For: 7.1.0.Final
>
>
> Add support for remote JNDI after all. It was agreed that:
> * Remote JNDI would run over Remoting
> * Remote JNDI for EJB is strictly a legacy access protocol, deprecated in favor of "ejb:"
> * The Remote JNDI service would proxy to a specific Context of the server JNDI tree - maybe "java:jboss/shared", maybe something else
> * Server-side services would opt-in to Remote JNDI; initially we'd only support:
> ** Remote EJB interfaces
> ** HornetQ connection factories
> * In the future we may support:
> ** User bindings, so long as they're serializable
> * In the future we will never support:
> ** Proxied DataSources
> ** Proxied JMS invocations
> Initial project tree is at https://github.com/dmlloyd/jboss-remote-jndi for now.
--
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
14 years, 2 months
[JBoss JIRA] Created: (AS7-1883) CLI domain deploy reports error on missing server-groups adds content anyway
by Thomas Diesler (JIRA)
CLI domain deploy reports error on missing server-groups adds content anyway
-----------------------------------------------------------------------------
Key: AS7-1883
URL: https://issues.jboss.org/browse/AS7-1883
Project: Application Server 7
Issue Type: Bug
Components: CLI
Reporter: Thomas Diesler
Assignee: Alexey Loubyansky
{code}
$ bin/jboss-admin.sh --connect
Connected to domain controller at localhost:9999
[domain@localhost:9999 /] deploy ./bundles/org/apache/aries/util/main/org.apache.aries.util-0.3.jar
Either --all-server-groups or --server-groups must be specified.
{code}
On the server side the content is added. A subsequent deploy fails
{code}
[domain@localhost:9999 /] deploy ./bundles/org/apache/aries/util/main/org.apache.aries.util-0.3.jar --all-server-groups
'org.apache.aries.util-0.3.jar' is already deployed (use --force to force re-deploy).
{code}
I suggest not to add the content on missing server-group argument
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-1338) Remote JNDI support for AS7
by Ed Keen (JIRA)
[ https://issues.jboss.org/browse/AS7-1338?page=com.atlassian.jira.plugin.s... ]
Ed Keen commented on AS7-1338:
------------------------------
I have followed these instructions and have successfully sent a remote message. However, after each message, I see the following logs on the server. Is there something else I need to do?
ERROR [org.jboss.remoting.remote] JBREM000200: Remote connection failed: java.io.IOException: An existing connection was forcibly closed by the remote host
INFO [org.jboss.as.naming] JBAS011806: Channel end notification received, closing channel Channel ID 58ff39c8 (inbound) of Remoting connection 01889fce to null
> Remote JNDI support for AS7
> ---------------------------
>
> Key: AS7-1338
> URL: https://issues.jboss.org/browse/AS7-1338
> Project: Application Server 7
> Issue Type: Task
> Components: Naming
> Reporter: Richard Opalka
> Assignee: John Bailey
> Priority: Critical
> Labels: eap6_prd_req
> Fix For: 7.1.0.Final
>
>
> Add support for remote JNDI after all. It was agreed that:
> * Remote JNDI would run over Remoting
> * Remote JNDI for EJB is strictly a legacy access protocol, deprecated in favor of "ejb:"
> * The Remote JNDI service would proxy to a specific Context of the server JNDI tree - maybe "java:jboss/shared", maybe something else
> * Server-side services would opt-in to Remote JNDI; initially we'd only support:
> ** Remote EJB interfaces
> ** HornetQ connection factories
> * In the future we may support:
> ** User bindings, so long as they're serializable
> * In the future we will never support:
> ** Proxied DataSources
> ** Proxied JMS invocations
> Initial project tree is at https://github.com/dmlloyd/jboss-remote-jndi for now.
--
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
14 years, 2 months
[JBoss JIRA] (AS7-3651) Console Server list does not refresh when I change Hosts
by Rich Raposa (JIRA)
Rich Raposa created AS7-3651:
--------------------------------
Summary: Console Server list does not refresh when I change Hosts
Key: AS7-3651
URL: https://issues.jboss.org/browse/AS7-3651
Project: Application Server 7
Issue Type: Bug
Components: Console
Environment: Three separate machines: one Domain Controller plus two Host Controllers. Host1 has 2 servers and Host2 has 3 servers.
Reporter: Rich Raposa
Assignee: Heiko Braun
>From the Runtime page, if I select a Host from the drop-down list of Hosts, it seems like the Servers on that Host should automatically appear in the Server Instances list, but it still shows the Servers from the previously-selected Host. If you click on "Server Instances" it refreshes the list and shows the correct Servers, but it seems like this list should Refresh automatically.
The issues occurs with both Chrome and Firefox.
--
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
14 years, 2 months
[JBoss JIRA] Created: (AS7-1840) Usability: modifing configuration significantly changes the xml
by Radoslav Husar (JIRA)
Usability: modifing configuration significantly changes the xml
---------------------------------------------------------------
Key: AS7-1840
URL: https://issues.jboss.org/browse/AS7-1840
Project: Application Server 7
Issue Type: Enhancement
Components: Server
Affects Versions: 7.0.1.Final, 7.0.0.Final
Reporter: Radoslav Husar
Assignee: Jason Greene
Related to AS7-442, there are multiple things that rapidly change from the standard shipped XML.
This is major usability issue for people who try to figure out what are the changes in the original XML and the current one. Here is a diff after adding just a sample DS:
The items are:
* indentation
* comments AS7-442
* whitespaces (" />" VS "/>")
* defaults implicit Vs explicit (i.e. autoflush="true")
* No newline at end of file
* attribute ordering (ie interface="management" port="8090" VS port="8090" interface="management")
{code}
1c1,23
< <?xml version='1.0' encoding='UTF-8'?>
---
> <!--
> ~ JBoss, Home of Professional Open Source.
> ~ Copyright 2011, Red Hat, Inc., and individual contributors
> ~ as indicated by the @author tags. See the copyright.txt file in the
> ~ distribution for a full listing of individual contributors.
> ~
> ~ This is free software; you can redistribute it and/or modify it
> ~ under the terms of the GNU Lesser General Public License as
> ~ published by the Free Software Foundation; either version 2.1 of
> ~ the License, or (at your option) any later version.
> ~
> ~ This software is distributed in the hope that it will be useful,
> ~ but WITHOUT ANY WARRANTY; without even the implied warranty of
> ~ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> ~ Lesser General Public License for more details.
> ~
> ~ You should have received a copy of the GNU Lesser General Public
> ~ License along with this software; if not, write to the Free
> ~ Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
> ~ 02110-1301 USA, or see the FSF site: http://www.fsf.org.
> -->
>
> <server xmlns="urn:jboss:domain:1.0">
3d24
< <server name="rhusar.brq.redhat.com" xmlns="urn:jboss:domain:1.0">
22,23c43,44
< <extension module="org.jboss.as.web"/>
< <extension module="org.jboss.as.weld"/>
---
> <extension module="org.jboss.as.web" />
> <extension module="org.jboss.as.weld" />
24a46
>
26,32c48,54
< <security-realms>
< <security-realm name="PropertiesMgmtSecurityRealm">
< <authentication>
< <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir"/>
< </authentication>
< </security-realm>
< </security-realms>
---
> <security-realms>
> <security-realm name="PropertiesMgmtSecurityRealm">
> <authentication>
> <properties path="mgmt-users.properties" relative-to="jboss.server.config.dir" />
> </authentication>
> </security-realm>
> </security-realms>
34,35c56,57
< <native-interface interface="management" port="9999"/>
< <http-interface interface="management" port="9990"/>
---
> <native-interface interface="management" port="9999" />
> <http-interface interface="management" port="9990"/>
37a60
>
40c63
< <console-handler name="CONSOLE" autoflush="true">
---
> <console-handler name="CONSOLE">
46c69,70
< <periodic-rotating-file-handler name="FILE" autoflush="true">
---
>
> <periodic-rotating-file-handler name="FILE">
53d76
< <append value="true"/>
54a78
>
63a88
>
74,80c99,102
< <datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="H2DS">
< <connection-url>
< jdbc:h2:mem:test;DB_CLOSE_DELAY=-1
< </connection-url>
< <driver>
< h2
< </driver>
---
> <datasource jndi-name="java:jboss/datasources/ExampleDS" enabled="true" use-java-context="true" pool-name="H2DS">
> <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1</connection-url>
> <driver>h2</driver>
> <pool></pool>
82,103c104,105
< <user-name>
< sa
< </user-name>
< <password>
< sa
< </password>
< </security>
< </datasource>
< <datasource jndi-name="asdsadasd" pool-name="asdasdasd_Pool">
< <connection-url>
< asda
< </connection-url>
< <driver>
< h2
< </driver>
< <security>
< <user-name>
< sdas
< </user-name>
< <password>
< dasd
< </password>
---
> <user-name>sa</user-name>
> <password>sa</password>
108,110c110
< <xa-datasource-class>
< org.h2.jdbcx.JdbcDataSource
< </xa-datasource-class>
---
> <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
116c116
< <deployment-scanner name="default" path="deployments" scan-enabled="true" scan-interval="5000" relative-to="jboss.server.base.dir" deployment-timeout="60"/>
---
> <deployment-scanner scan-interval="5000" relative-to="jboss.server.base.dir" path="deployments" />
118c118
< <subsystem xmlns="urn:jboss:domain:ee:1.0"/>
---
> <subsystem xmlns="urn:jboss:domain:ee:1.0" />
119a120,128
> <!-- EJB3 pools -->
> <pools>
> <bean-instance-pools>
> <strict-max-pool name="slsb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5"
> instance-acquisition-timeout-unit="MINUTES"/>
> </bean-instance-pools>
> </pools>
>
> <!-- Session bean configurations -->
125,129c134
< <pools>
< <bean-instance-pools>
< <strict-max-pool name="slsb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>
< </bean-instance-pools>
< </pools>
---
>
148,149c153,154
< <archive-validation enabled="false"/>
< <bean-validation enabled="false"/>
---
> <archive-validation enabled="false" />
> <bean-validation enabled="false" />
151,155c156,160
< <short-running-threads blocking="true" allow-core-timeout="false">
< <core-threads count="10" per-cpu="20"/>
< <queue-length count="10" per-cpu="20"/>
< <max-threads count="10" per-cpu="20"/>
< <keepalive-time time="10" unit="SECONDS"/>
---
> <short-running-threads blocking="true">
> <core-threads count="10" per-cpu="20"/>
> <queue-length count="10" per-cpu="20"/>
> <max-threads count="10" per-cpu="20"/>
> <keepalive-time time="10" unit="seconds"/>
157,161c162,166
< <long-running-threads blocking="true" allow-core-timeout="false">
< <core-threads count="10" per-cpu="20"/>
< <queue-length count="10" per-cpu="20"/>
< <max-threads count="10" per-cpu="20"/>
< <keepalive-time time="10" unit="SECONDS"/>
---
> <long-running-threads blocking="true">
> <core-threads count="10" per-cpu="20"/>
> <queue-length count="10" per-cpu="20"/>
> <max-threads count="10" per-cpu="20"/>
> <keepalive-time time="10" unit="seconds"/>
166c171
< <jmx-connector server-binding="jmx-connector-server" registry-binding="jmx-connector-registry"/>
---
> <jmx-connector registry-binding="jmx-connector-registry" server-binding="jmx-connector-server" />
171,172c176,177
< <subsystem xmlns="urn:jboss:domain:naming:1.0"/>
< <subsystem xmlns="urn:jboss:domain:pojo:1.0"/>
---
> <subsystem xmlns="urn:jboss:domain:naming:1.0" />
> <subsystem xmlns="urn:jboss:domain:pojo:1.0" />
175,177c180
< <property name="manager.root">
< jboss-osgi
< </property>
---
> <property name="manager.root">jboss-osgi</property>
179a183,188
> <!--
> A comma seperated list of module identifiers. Each system module
> is added as a dependency to the OSGi framework module. The packages
> from these system modules can be made visible as framework system packages.
> http://www.osgi.org/javadoc/r4v42/org/osgi/framework/Constants.html#FRAME...
> -->
181,187c190,193
< org.apache.commons.logging,
< org.apache.log4j,
< org.jboss.as.osgi,
< org.slf4j,
< </property>
< <property name="org.osgi.framework.startlevel.beginning">
< 1
---
> org.apache.commons.logging,
> org.apache.log4j,
> org.jboss.as.osgi,
> org.slf4j,
188a195,198
> <!--
> Framework environment property identifying extra packages which the system bundle
> must export from the current execution environment
> -->
190,198c200,208
< org.apache.commons.logging;version=1.1.1,
< org.apache.log4j;version=1.2,
< org.jboss.as.osgi.service;version=7.0,
< org.jboss.osgi.deployment.interceptor;version=1.0,
< org.jboss.osgi.spi.capability;version=1.0,
< org.jboss.osgi.spi.util;version=1.0,
< org.jboss.osgi.testing;version=1.0,
< org.jboss.osgi.vfs;version=1.0,
< org.slf4j;version=1.5.10,
---
> org.apache.commons.logging;version=1.1.1,
> org.apache.log4j;version=1.2,
> org.jboss.as.osgi.service;version=7.0,
> org.jboss.osgi.deployment.interceptor;version=1.0,
> org.jboss.osgi.spi.capability;version=1.0,
> org.jboss.osgi.spi.util;version=1.0,
> org.jboss.osgi.testing;version=1.0,
> org.jboss.osgi.vfs;version=1.0,
> org.slf4j;version=1.5.10,
199a210,211
> <!-- Specifies the beginning start level of the framework -->
> <property name="org.osgi.framework.startlevel.beginning">1</property>
201a214
> <!-- modules registered with the OSGi layer on startup -->
203a217
> <!-- bundles installed on startup -->
206a221
> <!-- bundles started in startlevel 1 -->
210a226
> <!-- bundles started in startlevel 2 -->
217a234
> <!-- bundles started in startlevel 3 -->
226c243
< <subsystem xmlns="urn:jboss:domain:security:1.1">
---
> <subsystem xmlns="urn:jboss:domain:security:1.0">
236a254
> <recovery-environment socket-binding="txn-recovery-environment" status-socket-binding="txn-status-manager"/>
239c257
< <uuid/>
---
> <uuid />
242d259
< <recovery-environment socket-binding="txn-recovery-environment" status-socket-binding="txn-status-manager"/>
244d260
< <object-store/>
247c263
< <connector name="http" protocol="HTTP/1.1" socket-binding="http" scheme="http"/>
---
> <connector name="http" scheme="http" protocol="HTTP/1.1" socket-binding="http"/>
249,250c265,266
< <alias name="localhost"/>
< <alias name="example.com"/>
---
> <alias name="localhost" />
> <alias name="example.com" />
253c269
< <subsystem xmlns="urn:jboss:domain:weld:1.0"/>
---
> <subsystem xmlns="urn:jboss:domain:weld:1.0" />
254a271
>
260c277
< <inet-address value="${jboss.bind.address:127.0.0.1}"/>
---
> <inet-address value="${jboss.bind.address:127.0.0.1}"/>
262a280
>
266,267c284,285
< <socket-binding name="jmx-connector-registry" port="1090" interface="management"/>
< <socket-binding name="jmx-connector-server" port="1091" interface="management"/>
---
> <socket-binding name="jmx-connector-registry" interface="management" port="1090"/>
> <socket-binding name="jmx-connector-server" interface="management" port="1091"/>
269c287
< <socket-binding name="osgi-http" port="8090" interface="management"/>
---
> <socket-binding name="osgi-http" interface="management" port="8090"/>
274c292,293
< </server>
\ No newline at end of file
---
>
> </server>
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (JBRULES-3381) Drools cache is flushed in jboss cloud provisioned environment
by Balaji R (JIRA)
Balaji R created JBRULES-3381:
---------------------------------
Summary: Drools cache is flushed in jboss cloud provisioned environment
Key: JBRULES-3381
URL: https://issues.jboss.org/browse/JBRULES-3381
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core
Affects Versions: 5.0.1.FINAL
Environment: jboss AS 5.1.0 on linux OS, drools version 5.0.1, Apache http Server 2.0.2
Reporter: Balaji R
Assignee: Mark Proctor
Priority: Critical
We have a strange issue, occurring infrequently on a cloud provisioned jboss environment. We have a cluster of jboss servers, provisioned in a private cloud environment. We have Jboss MBean implementations packaged in an ear and deployed on all the provisioned servers.
All the MBeans initialize rules (mvel) configured as drl on a remote http Apache host and are configured to poll (ResourceChangeScanner, ResourceChangeNotifier) and load new set of rules on each server using a KnowledgeAgent (private static KnowledgeAgent kagent).
Each subsequent request will create a new statefulSession (getKagent().getKnowledgeBase().newStatefulKnowledgeSession();) and execute the rules and are doing a session.dispose in the end.
Everything works fine, except that on one of the jboss installations, it looks like the cached drools are flushed from memory without errors or exceptions and all subsequent executions on rules (fireAllRules()) through the stateful sessions, yield no results. Basically because there are no rules to execute.
The polling continues at a frequency of 1 hour for new rules, but there is no action, because there are no new, or modified rules (drls), but unfortunately, it looks like the cache is empty.
I don't understand how comparison happens between the cached set of rules and the ones on the resource server (http Apache server), but it neither reloads nor executes anything or throws errors or exceptions.
knowledgepackages.isEmpty() check happens and it's returns false. So no exceptions either. We are able to see that a couple of packages are present, as some rules in those are executing. I am not sure whether this packages are complete in cache, or just is not empty. We are trying to put more checks to see if each of the knowledgePackages are empty (.rules.isEmpty()), as that's what it seems to be. But not sure where the problem is.
Remember, this issue occurs INFREQUENTLY on only one of the servers the cluster. Not sure whether an upgrade will help, as I didn't see any jira related to this.
--
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
14 years, 2 months