[JBoss JIRA] (AS7-5411) adding JSSE to a security domain with the CLI does not persist
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-5411?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar resolved AS7-5411.
------------------------------
Fix Version/s: 7.2.0.Alpha1
Resolution: Rejected
Problem is in CLI command and not in subsystem itself.
in provided command there is keystore set in {noformat}[{"url" => ...}]{noformat}
which means it is a list of objects and not a object.
proper command is:
{noformat}
/subsystem=security/security-domain=mydomain/jsse=classic:add(keystore={"url" => "${jboss.server.config.dir}/jboss.keystore","password" => "secret"})
{noformat}
> adding JSSE to a security domain with the CLI does not persist
> --------------------------------------------------------------
>
> Key: AS7-5411
> URL: https://issues.jboss.org/browse/AS7-5411
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Tom Fonteyne
> Assignee: Tomaz Cerar
> Fix For: 7.2.0.Alpha1
>
>
> Adding JSSE setting to a security domain works in-memory, but they are not written to the 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
13 years, 4 months
[JBoss JIRA] (AS7-5879) Eliminate imports of jboss-as-controller classes from arquillian modules
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/AS7-5879?page=com.atlassian.jira.plugin.s... ]
Bartosz Baranowski reassigned AS7-5879:
---------------------------------------
Assignee: Bartosz Baranowski
> Eliminate imports of jboss-as-controller classes from arquillian modules
> ------------------------------------------------------------------------
>
> Key: AS7-5879
> URL: https://issues.jboss.org/browse/AS7-5879
> Project: Application Server 7
> Issue Type: Task
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Brian Stansberry
> Assignee: Bartosz Baranowski
> Fix For: 7.2.0.CR1
>
>
> The arquillian modules have some imports of classes in the jboss-as-controller module in client-side classes. I've seen them in the ManagementClient classes; there may be others. Basically imports of string constants and some static utility methods.
> The controller module is a server side module and its classes should not leak out to client-side code.
--
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, 4 months
[JBoss JIRA] (AS7-6031) deploy directories not cleaned up
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/AS7-6031?page=com.atlassian.jira.plugin.s... ]
Bartosz Baranowski reassigned AS7-6031:
---------------------------------------
Assignee: Bartosz Baranowski
> deploy directories not cleaned up
> ---------------------------------
>
> Key: AS7-6031
> URL: https://issues.jboss.org/browse/AS7-6031
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Shaun Appleton
> Assignee: Bartosz Baranowski
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.
--
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, 4 months
[JBoss JIRA] (JGRP-1553) TimeScheduler3
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1553?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1553:
--------------------------------
I actually ended up implementing TimeScheduler3. It uses a DelayQueue with tasks sorted according to execution time. TimeScheduler is much smaller (300 LOC) than TimeScheduler2 (650 LOC), much more elegant (no awkward referencing of runnables and wrapping done anymore) and much simpler.
I also added more tests to TimeSchedulerTest and TimeScheduler3 passes all.
I changed the default to use the new class (timer_type=new3 in TP).
> TimeScheduler3
> --------------
>
> Key: JGRP-1553
> URL: https://issues.jboss.org/browse/JGRP-1553
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> The current TimeScheduler2 class has a few deficiencies:
> - taskReady() should only set next-execution-time if its argument is less than next-execution-time
> - no_tasks: when setting this CAS, the result is only checked in 1 location, but not the other
> - Potential loss of task: when calling schedule() on an existing Entry (same execution time), and - before adding the task to Entry - Entry is removed by _run() as it was executed, then the newly added task will never get to run !
> - Simplification: instead of headMap(), just use firstEntry(), removeFirstEntry(). See pseudo code below.
> As a workaround, timer_type="old" will switch back to the previous default timer. The reason for TimeScheduler3 (versus changing TimeScheduler2) is that we can simply switch to the new impl by setting (a new) timer_type="new2". Should this have a bug, we can simply switch back to "new" or "old" (or "wheel".
> Over time, TimeScheduler2 will get removed.
> Pseudo code:
> * loop while has tasks
> ** get the first task
> ** if its time is less than the current time: execute it and remove it
> ** else block (on the next task or 10s) until an element is added
--
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, 4 months
[JBoss JIRA] (JGRP-1553) TimeScheduler3
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1553?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1553.
----------------------------
Resolution: Done
> TimeScheduler3
> --------------
>
> Key: JGRP-1553
> URL: https://issues.jboss.org/browse/JGRP-1553
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> The current TimeScheduler2 class has a few deficiencies:
> - taskReady() should only set next-execution-time if its argument is less than next-execution-time
> - no_tasks: when setting this CAS, the result is only checked in 1 location, but not the other
> - Potential loss of task: when calling schedule() on an existing Entry (same execution time), and - before adding the task to Entry - Entry is removed by _run() as it was executed, then the newly added task will never get to run !
> - Simplification: instead of headMap(), just use firstEntry(), removeFirstEntry(). See pseudo code below.
> As a workaround, timer_type="old" will switch back to the previous default timer. The reason for TimeScheduler3 (versus changing TimeScheduler2) is that we can simply switch to the new impl by setting (a new) timer_type="new2". Should this have a bug, we can simply switch back to "new" or "old" (or "wheel".
> Over time, TimeScheduler2 will get removed.
> Pseudo code:
> * loop while has tasks
> ** get the first task
> ** if its time is less than the current time: execute it and remove it
> ** else block (on the next task or 10s) until an element is added
--
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, 4 months
[JBoss JIRA] (AS7-6060) naming's :jndi-view operation failing with standalone-full.xml configuration
by Heiko Braun (JIRA)
[ https://issues.jboss.org/browse/AS7-6060?page=com.atlassian.jira.plugin.s... ]
Heiko Braun commented on AS7-6060:
----------------------------------
yes, works.
> naming's :jndi-view operation failing with standalone-full.xml configuration
> ----------------------------------------------------------------------------
>
> Key: AS7-6060
> URL: https://issues.jboss.org/browse/AS7-6060
> Project: Application Server 7
> Issue Type: Bug
> Components: Naming
> Reporter: Jeff Mesnil
> Assignee: Eduardo Martins
> Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
>
>
> I noticed this on AS7 master branch.
> If I run the server with the standalone.xml configuration, the /subsystem=naming:jndi-view runs fine.
> However with standalone-full.xml or standalone-full-ha.xml, the operation fails:
> {noformat}
> [standalone@localhost:9999 /] /subsystem=naming:jndi-view
> {
> "outcome" => "failed",
> "result" => {"java: contexts" => {"java:" => {
> "ConnectionFactory" => {
> "class-name" => "org.hornetq.jms.client.HornetQJMSConnectionFactory",
> "value" => "HornetQConnectionFactory [serverLocator=ServerLocatorImpl [initialConnectors=[TransportConfiguration(name=in-vm, factory=org-hornetq-core-remoting-impl-invm-InVMConnectorFactory) ?server-id=0], discoveryGroupConfiguration=null], clientID=null, dupsOKBatchSize=1048576, transactionBatchSize=1048576, readOnly=false]"
> },
> "JmsXA" => {
> "class-name" => "java.lang.Object",
> "value" => "?"
> },
> "TransactionManager" => {
> "class-name" => "com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate",
> "value" => "com.arjuna.ats.jbossatx.jta.TransactionManagerDelegate@36bbb8c4"
> },
> "ejb" => {
> "class-name" => "javax.naming.Context",
> "children" => {"mgmt" => {
> "class-name" => "javax.naming.Context",
> "children" => {"MEJB" => {"class-name" => "javax.management.j2ee.ManagementHome"}}
> }}
> }
> }}},
> "failure-description" => "JBAS014749: Operation handler failed: JBAS014487: Could not load view class for ejb EJB",
> "rolled-back" => true
> }
> {noformat}
> with the stack trace on the server-side:
> {noformat}
> 18:16:17,682 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("jndi-view") failed - address: ([("subsystem" => "naming")]): java.lang.RuntimeException: JBAS014487: Could not load view class for ejb EJB
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:90)
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getJndiViewInstanceValue(RemoteViewManagedReferenceFactory.java:79)
> at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:144)
> at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:138)
> at org.jboss.as.naming.management.JndiViewOperation.addEntries(JndiViewOperation.java:138)
> at org.jboss.as.naming.management.JndiViewOperation.access$000(JndiViewOperation.java:48)
> at org.jboss.as.naming.management.JndiViewOperation$1.execute(JndiViewOperation.java:65)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:439) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:321) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:228) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:223) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:135) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:111) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> 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]
> 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]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.7.0_09-icedtea]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09-icedtea]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
> Caused by: java.lang.ClassNotFoundException: javax.management.j2ee.ManagementHome from [Module "org.jboss.as.naming:main" from local module loader @5cbe930a (roots: /home/jmesnil/Developer/jboss-as/build/target/jboss-as-7.2.0.Alpha1-SNAPSHOT/modules)]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:190) [jboss-modules.jar:1.1.3.GA]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:468) [jboss-modules.jar:1.1.3.GA]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:456) [jboss-modules.jar:1.1.3.GA]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398) [jboss-modules.jar:1.1.3.GA]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:120) [jboss-modules.jar:1.1.3.GA]
> at java.lang.Class.forName0(Native Method) [rt.jar:1.7.0_09-icedtea]
> at java.lang.Class.forName(Class.java:264) [rt.jar:1.7.0_09-icedtea]
> at org.jboss.as.ejb3.remote.RemoteViewManagedReferenceFactory.getReference(RemoteViewManagedReferenceFactory.java:87)
> ... 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
13 years, 4 months
[JBoss JIRA] (AS7-6098) Error using jndi view operation
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/AS7-6098?page=com.atlassian.jira.plugin.s... ]
Eduardo Martins resolved AS7-6098.
----------------------------------
Resolution: Duplicate Issue
solved by AS7-6060
> 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
13 years, 4 months
[JBoss JIRA] (AS7-6143) HiloKeygenerator not registered in JNDI
by Manuel Fehlhammer (JIRA)
[ https://issues.jboss.org/browse/AS7-6143?page=com.atlassian.jira.plugin.s... ]
Manuel Fehlhammer updated AS7-6143:
-----------------------------------
Git Pull Request: https://github.com/jbossas/jboss-as/pull/3706
> HiloKeygenerator not registered in JNDI
> ---------------------------------------
>
> Key: AS7-6143
> URL: https://issues.jboss.org/browse/AS7-6143
> Project: Application Server 7
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 7.1.1.Final
> Reporter: Manuel Fehlhammer
> Labels: cmp
> Fix For: Open To Community
>
>
> The HiLoKeygenerator from subsystem cmp is not registered in JNDI.
> Therefore it is not really usable.
> I managed to get the service successfully started up with the following subsystem confiuration in standalone.xml:
> {code:xml}
> <subsystem xmlns="urn:jboss:domain:cmp:1.0">
> <key-generators>
> <hilo name="itemidgenerator">
> <block-size>
> 10
> </block-size>
> <data-source>
> java:jboss/datasources/MySqlDS
> </data-source>
> <id-column>
> highvalue
> </id-column>
> <sequence-column>
> sequencename
> </sequence-column>
> <sequence-name>
> itemid
> </sequence-name>
> <table-name>
> HiLoSequences
> </table-name>
> </hilo>
> </key-generators>
> </subsystem>
> {code}
>
> But I do not find any JNDI registration related to this HiLoKeygenerator.
> From JBOSS 5.x times I know that the generator was bound as "KeyGeneratorFactory" or something.
--
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, 4 months