[JBoss JIRA] (AS7-430) DomainController discovery system
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/AS7-430?page=com.atlassian.jira.plugin.sy... ]
Farah Juma commented on AS7-430:
--------------------------------
Created a pull request: https://github.com/jbossas/jboss-as/pull/3593
This allows a slave host controller to discover a master domain controller via S3. In particular, both the slave and the master can be configured with information needed to access an S3 bucket (sample configuration is shown below). When a master domain controller is started, if it has been configured to allow S3 discovery, it will write its address and port to an S3 file (jboss-domain-master-data) in the given bucket. There are now 2 remote domain controller discovery options for a slave host controller:
1. static discovery, i.e., statically configure the remote domain controller's host and port, exactly as before
2. S3 discovery, i.e., provide the <S3-discovery> configuration shown below
When a slave uses S3 discovery, it gets the remote domain controller's address and port from an S3 file in the given bucket. A slave must be configured with at least one of the two discovery options. Whenever a slave needs to connect to the master, it will now loop through all provided discovery options. (Note that when both discovery options are provided, static discovery will be attempted first. If this fails, then S3 discovery will be attempted next.)
Sample Configuration -
An optional <discovery-options> element can now be added to <remote> for a slave host controller and to <local> for the master domain controller, as follows:
Slave host controller (note: this example configures both static and S3 discovery):
{code:xml}
<remote host="${jboss.domain.master.address}" port="${jboss.domain.master.port:9999}" security-realm="ManagementRealm">
<discovery-options>
<S3-discovery>
<access-key value="s3_access_key"/>
<secret-access-key value="s3_secret_access_key"/>
<location value="s3_bucket_name"/>
</S3-discovery>
</discovery-options>
</remote>
{code}
Master domain controller:
{code:xml}
<local>
<discovery-options>
<S3-discovery>
<access-key value="s3_access_key"/>
<secret-access-key value="s3_secret_access_key"/>
<location value="s3_bucket_name"/>
</S3-discovery>
</discovery-options>
</local>
{code}
Note that right now, the only child the <discovery-options> element can have is <S3-discovery>. However, the way the discovery system has been implemented should allow other discovery options to easily be added in the future as well.
> DomainController discovery system
> ---------------------------------
>
> Key: AS7-430
> URL: https://issues.jboss.org/browse/AS7-430
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Farah Juma
> Fix For: 7.2.0.CR1
>
>
> Mechanism(s) by which a Host Controller finds a Domain Controller so it can begin the process of integrating into the domain.
> Task includes the host.xml schema elements to configure this, the domain object model classes behind those elements, and the actual implementation of discovery from both the ServerManager and DomainController sides.
--
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
12 years, 1 month
[JBoss JIRA] (AS7-4388) Provide clustering management use cases
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/AS7-4388?page=com.atlassian.jira.plugin.s... ]
Richard Achmatowicz commented on AS7-4388:
------------------------------------------
Bela, thanks for the feedback!
Paul also suggested creation of a separate subsystem. It does have its advantages: re-enforces that the JGroups and Infinispan subsystems represent local resources only and to see the global (different) view you need to look in a different place; allows those subsystems to stay relatively uncomplicated; can be optionally included in a profile). This would probably be a more intuitive presentation of cluster information as far as the user is concerned.
As for probe, I did review all of its features (keys). Because it allows destructive operations (e.g. invoke an arbitrary operation on a protocol layer), I think we need to wait until we have some security mechanisms in place (AS8) before using it generally. But that probably does not prevent us from presenting a subset of keys for use. These could be presented as operations under /subsystem=cluster/name=session-cluster/channel=*. Also, it seems to require receiving commands by multicast, so will there not be a problem with TCP stacks? Perhaps make it available if the stack is UDP and mcast-enabled only?
> Provide clustering management use cases
> ---------------------------------------
>
> Key: AS7-4388
> URL: https://issues.jboss.org/browse/AS7-4388
> Project: Application Server 7
> Issue Type: Task
> Components: Console
> Reporter: Heiko Braun
> Assignee: Bela Ban
> Fix For: 7.2.0.CR1
>
>
> In order to prep the UI, we would need a list of typical clustering management use cases.
--
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
12 years, 1 month
[JBoss JIRA] (JBRULES-3701) Add ability to trait a map
by Ming Fang (JIRA)
Ming Fang created JBRULES-3701:
----------------------------------
Summary: Add ability to trait a map
Key: JBRULES-3701
URL: https://issues.jboss.org/browse/JBRULES-3701
Project: Drools
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: drools-core (expert)
Affects Versions: 5.5.0.Final
Reporter: Ming Fang
Assignee: Mark Proctor
Add ability to trait a Map as described by Mark Proctor here
http://drools.46999.n3.nabble.com/rules-users-Maps-as-Object-in-Drools-td...
<quote>
//code below is illustrative of what is possible, if changes where mad for above idea.
// Create interface
Person
@Trait
String : name
int : age
end
// Identify the Map instance, and wrap it with the Person interface.
rule
$m : Map[ this['name'] != null, this['age'] != null )
then
don( $m : Person.class );
end
// Now the map is identified in a type safe manner.
rule
Person( name == "darth", age == 150 )
then
….
end
</quote>
--
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
12 years, 1 month
[JBoss JIRA] (AS7-6098) Error using jndi view operation
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-6098?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-6098:
----------------------------------
Assignee: Eduardo Martins (was: Brian Stansberry)
> Error using jndi view operation
> -------------------------------
>
> Key: AS7-6098
> URL: https://issues.jboss.org/browse/AS7-6098
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, Naming
> Environment: domain mode
> Reporter: Heiko Braun
> Assignee: Eduardo Martins
> Priority: Critical
> Fix For: 7.2.0.CR1
>
>
> {noformat}
> [Server:server-one] 14:42:04,306 ERROR [org.jboss.as.controller.management-operation] (host-controller-connection-threads - 1) JBAS014612: Operation ("jndi-view") failed - address: ([("subsystem" => "naming")]): java.lang.RuntimeException: JBAS014487: Could not load view class for ejb EJB
> [Server:server-one] at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:90)
> [Server:server-one] at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getJndiViewInstanceValue(RemoteViewManagedReferenceFactory.java:79)
> [Server:server-one] at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:144)
> [Server:server-one] at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:138)
> [Server:server-one] at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:138)
> [Server:server-one] at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:48)
> [Server:server-one] at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:65)
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:439) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:321) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:228) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> [Server:server-one] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:223) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> [Server:server-one] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:136) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> [Server:server-one] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:112) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:112) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> [Server:server-one] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.execute(TransactionalProtocolOperationHandler.java:95) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> [Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [jboss-as-protocol-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> [Server:server-one] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [jboss-as-protocol-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_37]
> [Server:server-one] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_37]
> [Server:server-one] at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_37]
> [Server:server-one] at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
> [Server:server-one] Caused by: java.lang.ClassNotFoundException: javax.management.j2ee.ManagementHome from [Module "org.jboss.as.naming:main" from local module loader @353c375 (roots: /Users/hbraun/dev/prj/jboss-as/build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules)]
> [Server:server-one] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) [jboss-modules.jar:1.1.3.GA]
> [Server:server-one] at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) [jboss-modules.jar:1.1.3.GA]
> [Server:server-one] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) [jboss-modules.jar:1.1.3.GA]
> [Server:server-one] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:423) [jboss-modules.jar:1.1.3.GA]
> [Server:server-one] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.1.3.GA]
> [Server:server-one] at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) [jboss-modules.jar:1.1.3.GA]
> [Server:server-one] at java.lang.Class.forName0(Native Method) [classes.jar:1.6.0_37]
> [Server:server-one] at java.lang.Class.forName(Class.java:247) [classes.jar:1.6.0_37]
> [Server:server-one] at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:87)
> [Server:server-one] ... 20 more
> {noformat}
--
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
12 years, 1 month
[JBoss JIRA] (JBWEB-259) NPE at org.apache.catalina.core.StandardWrapper.unload(StandardWrapper.java:1380)
by Ed Roberts (JIRA)
Ed Roberts created JBWEB-259:
--------------------------------
Summary: NPE at org.apache.catalina.core.StandardWrapper.unload(StandardWrapper.java:1380)
Key: JBWEB-259
URL: https://issues.jboss.org/browse/JBWEB-259
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Tomcat
Affects Versions: JBossWeb-7.2.0.Alpha3
Environment: Windows XP Service Pack 2
Oracle JDK 1.6.0_32
JBoss AS 7.2.0.Alpha1 commit id f450cdd2f99baedebf0b36e09e682630e0ffd612
Reporter: Ed Roberts
Assignee: Remy Maucherat
Using the standalone.bat to start up JBoss
When I try to deploy Felix web console 3.1.6.SP1, and Felix Metatype 1.0.4 for the org.osgi.service.metatype.* dependencies I eventually get the following exception
{code}
16:45:43,603 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/system/console]] (CM Configuration Updater (ManagedService Update: pid=org.apache.felix.webconsole.internal.servlet.OsgiManager)) JBWEB000266: Servlet system/console threw unload exception: javax.servlet.ServletException: JBWEB000265: Servlet.destroy() for servlet system/console threw exception
at org.apache.catalina.core.StandardWrapper.unload(StandardWrapper.java:1390)
at org.apache.catalina.core.StandardWrapper.stop(StandardWrapper.java:1669)
at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3906)
at org.jboss.as.osgi.httpservice.HttpServiceImpl.unregisterInternal(HttpServiceImpl.java:215)
at org.jboss.as.osgi.httpservice.HttpServiceImpl.unregister(HttpServiceImpl.java:203)
at org.apache.felix.webconsole.internal.servlet.OsgiManager.unbindHttpService(OsgiManager.java:772) [OsgiManager.class:]
at org.apache.felix.webconsole.internal.servlet.OsgiManager$HttpServiceTracker.removedService(OsgiManager.java:660) [OsgiManager$HttpServiceTracker.class:]
at org.osgi.util.tracker.ServiceTracker$Tracked.untrack(ServiceTracker.java:1126) [ServiceTracker$Tracked.class:]
at org.osgi.util.tracker.ServiceTracker.close(ServiceTracker.java:347) [ServiceTracker.class:]
at org.apache.felix.webconsole.internal.servlet.OsgiManager.updateConfiguration(OsgiManager.java:826) [OsgiManager.class:]
at org.apache.felix.webconsole.internal.servlet.ConfigurationListener.updated(ConfigurationListener.java:66) [ConfigurationListener.class:]
at org.apache.felix.cm.impl.ConfigurationManager$ManagedServiceUpdate.run(ConfigurationManager.java:1160)
at org.apache.felix.cm.impl.UpdateThread.run(UpdateThread.java:104)
at java.lang.Thread.run(Unknown Source) [rt.jar:1.6.0_32]
Caused by: java.lang.NullPointerException
at org.apache.catalina.core.StandardWrapper.unload(StandardWrapper.java:1380)
... 13 more
{code}
The Servlet has deployed successfully
--
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
12 years, 1 month
[JBoss JIRA] (JBWEB-258) DigestAuthenticator generates duplicate nonces
by Aaron Ogburn (JIRA)
Aaron Ogburn created JBWEB-258:
----------------------------------
Summary: DigestAuthenticator generates duplicate nonces
Key: JBWEB-258
URL: https://issues.jboss.org/browse/JBWEB-258
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: JBossWeb-2.1.12.GA, JBossWeb-7.0.16.GA
Reporter: Aaron Ogburn
Assignee: Remy Maucherat
DigestAuthenticator currently generates nonces as a hash of the client's remote ip, the current time at generation time, and an internal server key. With high concurrent load in a scenario where many clients show a single ip (such as behind a loadbalancer/proxy), then it is very easy for DigestAuthenticator to give out duplicate nonces when they are generated at the same time.
This then leads to authentication failues as counts for the duplicate nonces get out of whack.
--
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
12 years, 1 month