[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
11 years, 9 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
11 years, 9 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
11 years, 9 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
11 years, 9 months
[JBoss JIRA] (AS7-6216) Some javax.* bundles show version 0.0.0 in AS7
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6216?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-6216:
--------------------------------
Description:
Some javax bundles that we configure by default do not show valid bundle version info
javax.jws.api:0.0.0
javax.ws.rs.api:0.0.0
The javax.persistence.api has its metadata defined in jbosgi-xservice.properties like this
{code}
Bundle-SymbolicName: hibernate-jpa-2.0-api
Bundle-Version: 1.0.1.Final
Export-Package: javax.persistence.spi;version="2.0.0",javax.persistence.criteria;version="2.0.0",javax.persistence;version="2.0.0",javax.persistence.metamodel;version="2.0.0"
{code}
This should be replaced by metadata coming from the artefacts manifest.
Generally, all javax api artefacts should have valid OSGi metadata
was:
Some javax bundles that we configure by default do not show valid bundle version info
javax.jws.api:0.0.0
javax.ws.rs.api:0.0.0
The javax.persistence.api has its metadata defined in jbosgi-xservice.properties like this
{code}
Bundle-SymbolicName: hibernate-jpa-2.0-api
Bundle-Version: 1.0.1.Final
Export-Package: javax.persistence.spi;version="2.0.0",javax.persistence.criteria;version="2.0.0",javax.persistence;version="2.0.0",javax.persistence.metamodel;version="2.0.0"
{code}
This should be replaced by metadata coming from the artefacts manifest.
Generally, all javax api artefacts should valid OSGi metadata
> Some javax.* bundles show version 0.0.0 in AS7
> ----------------------------------------------
>
> Key: AS7-6216
> URL: https://issues.jboss.org/browse/AS7-6216
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.2.0.Alpha1
> Reporter: Thomas Diesler
> Assignee: Paul Gier
>
> Some javax bundles that we configure by default do not show valid bundle version info
> javax.jws.api:0.0.0
> javax.ws.rs.api:0.0.0
> The javax.persistence.api has its metadata defined in jbosgi-xservice.properties like this
> {code}
> Bundle-SymbolicName: hibernate-jpa-2.0-api
> Bundle-Version: 1.0.1.Final
> Export-Package: javax.persistence.spi;version="2.0.0",javax.persistence.criteria;version="2.0.0",javax.persistence;version="2.0.0",javax.persistence.metamodel;version="2.0.0"
> {code}
> This should be replaced by metadata coming from the artefacts manifest.
> Generally, all javax api artefacts should have valid OSGi metadata
--
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-6216) Some javax.* bundles show version 0.0.0 in AS7
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6216?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-6216:
--------------------------------
Fix Version/s: (was: 7.2.0.Alpha1)
Reporter: Thomas Diesler (was: jarkko rantavuori)
Steps to Reproduce: (was: - download and unzip 7.2 snapshot from https://ci.jboss.org/jenkins/job/JBoss-AS-7.x-latest/lastSuccessfulBuild/...
- add an admin user with bin\add-user
- start the server with bin\standalone
- view the admin console at http://localhost:9990/console/App.html#osgi-runtime, logging in with admin user)
Assignee: Paul Gier (was: Thomas Diesler)
Environment: (was: Windows 7)
> Some javax.* bundles show version 0.0.0 in AS7
> ----------------------------------------------
>
> Key: AS7-6216
> URL: https://issues.jboss.org/browse/AS7-6216
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.2.0.Alpha1
> Reporter: Thomas Diesler
> Assignee: Paul Gier
>
> Some javax bundles that we configure by default do not show valid bundle version info
> javax.jws.api:0.0.0
> javax.ws.rs.api:0.0.0
> The javax.persistence.api has its metadata defined in jbosgi-xservice.properties like this
> {code}
> Bundle-SymbolicName: hibernate-jpa-2.0-api
> Bundle-Version: 1.0.1.Final
> Export-Package: javax.persistence.spi;version="2.0.0",javax.persistence.criteria;version="2.0.0",javax.persistence;version="2.0.0",javax.persistence.metamodel;version="2.0.0"
> {code}
> This should be replaced by metadata coming from the artefacts manifest.
> Generally, all javax api artefacts should valid OSGi metadata
--
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-6216) Some javax.* bundles show version 0.0.0 in AS7
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6216?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-6216:
--------------------------------
Description:
Some javax bundles that we configure by default do not show valid bundle version info
javax.jws.api:0.0.0
javax.ws.rs.api:0.0.0
The javax.persistence.api has its metadata defined in jbosgi-xservice.properties like this
{code}
Bundle-SymbolicName: hibernate-jpa-2.0-api
Bundle-Version: 1.0.1.Final
Export-Package: javax.persistence.spi;version="2.0.0",javax.persistence.criteria;version="2.0.0",javax.persistence;version="2.0.0",javax.persistence.metamodel;version="2.0.0"
{code}
This should be replaced by metadata coming from the artefacts manifest.
Generally, all javax api artefacts should valid OSGi metadata
was:
JBoss internal OSGi bundles seem to always report bundle version as 0.0.0. Examples from the admin console:
javax.annotation.api:0.0.0
javax.ejb.api:0.0.0
javax.interceptor.api:0.0.0
javax.jms.api:0.0.0
javax.jws.api:0.0.0
javax.management.j2ee.api:0.0.0
javax.persistence.api:0.0.0
javax.servlet.api:0.0.0
javax.transaction.api:0.0.0
javax.ws.rs.api:0.0.0
javax.xml.bind.api:0.0.0
javax.xml.ws.api:0.0.0
org.jboss.as.osgi.http:0.0.0
> Some javax.* bundles show version 0.0.0 in AS7
> ----------------------------------------------
>
> Key: AS7-6216
> URL: https://issues.jboss.org/browse/AS7-6216
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows 7
> Reporter: jarkko rantavuori
> Assignee: Thomas Diesler
> Fix For: 7.2.0.Alpha1
>
>
> Some javax bundles that we configure by default do not show valid bundle version info
> javax.jws.api:0.0.0
> javax.ws.rs.api:0.0.0
> The javax.persistence.api has its metadata defined in jbosgi-xservice.properties like this
> {code}
> Bundle-SymbolicName: hibernate-jpa-2.0-api
> Bundle-Version: 1.0.1.Final
> Export-Package: javax.persistence.spi;version="2.0.0",javax.persistence.criteria;version="2.0.0",javax.persistence;version="2.0.0",javax.persistence.metamodel;version="2.0.0"
> {code}
> This should be replaced by metadata coming from the artefacts manifest.
> Generally, all javax api artefacts should valid OSGi metadata
--
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-6216) Some javax.* bundles show version 0.0.0 in AS7
by Thomas Diesler (JIRA)
Thomas Diesler created AS7-6216:
-----------------------------------
Summary: Some javax.* bundles show version 0.0.0 in AS7
Key: AS7-6216
URL: https://issues.jboss.org/browse/AS7-6216
Project: Application Server 7
Issue Type: Bug
Components: OSGi
Affects Versions: 7.2.0.Alpha1
Environment: Windows 7
Reporter: jarkko rantavuori
Assignee: Thomas Diesler
Fix For: 7.2.0.Alpha1
JBoss internal OSGi bundles seem to always report bundle version as 0.0.0. Examples from the admin console:
javax.annotation.api:0.0.0
javax.ejb.api:0.0.0
javax.interceptor.api:0.0.0
javax.jms.api:0.0.0
javax.jws.api:0.0.0
javax.management.j2ee.api:0.0.0
javax.persistence.api:0.0.0
javax.servlet.api:0.0.0
javax.transaction.api:0.0.0
javax.ws.rs.api:0.0.0
javax.xml.bind.api:0.0.0
javax.xml.ws.api:0.0.0
org.jboss.as.osgi.http:0.0.0
--
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-6211) OSGi bundles show version 0.0.0 in AS7
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6211?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-6211:
--------------------------------
Summary: OSGi bundles show version 0.0.0 in AS7 (was: JBoss OSGi bundles show version 0.0.0 in AS 7.2.0.Alpha1)
> OSGi bundles show version 0.0.0 in AS7
> --------------------------------------
>
> Key: AS7-6211
> URL: https://issues.jboss.org/browse/AS7-6211
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows 7
> Reporter: jarkko rantavuori
> Assignee: Thomas Diesler
> Fix For: 7.2.0.Alpha1
>
>
> JBoss internal OSGi bundles seem to always report bundle version as 0.0.0. Examples from the admin console:
> javax.annotation.api:0.0.0
> javax.ejb.api:0.0.0
> javax.interceptor.api:0.0.0
> javax.jms.api:0.0.0
> javax.jws.api:0.0.0
> javax.management.j2ee.api:0.0.0
> javax.persistence.api:0.0.0
> javax.servlet.api:0.0.0
> javax.transaction.api:0.0.0
> javax.ws.rs.api:0.0.0
> javax.xml.bind.api:0.0.0
> javax.xml.ws.api:0.0.0
> org.jboss.as.osgi.http:0.0.0
--
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-6211) JBoss OSGi bundles show version 0.0.0 in AS 7.2.0.Alpha1
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6211?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler commented on AS7-6211:
-------------------------------------
Yes this is a bug. Most of these actually contain valid Bundle-Version information
> JBoss OSGi bundles show version 0.0.0 in AS 7.2.0.Alpha1
> --------------------------------------------------------
>
> Key: AS7-6211
> URL: https://issues.jboss.org/browse/AS7-6211
> Project: Application Server 7
> Issue Type: Bug
> Components: OSGi
> Affects Versions: 7.2.0.Alpha1
> Environment: Windows 7
> Reporter: jarkko rantavuori
> Assignee: Thomas Diesler
> Fix For: 7.2.0.Alpha1
>
>
> JBoss internal OSGi bundles seem to always report bundle version as 0.0.0. Examples from the admin console:
> javax.annotation.api:0.0.0
> javax.ejb.api:0.0.0
> javax.interceptor.api:0.0.0
> javax.jms.api:0.0.0
> javax.jws.api:0.0.0
> javax.management.j2ee.api:0.0.0
> javax.persistence.api:0.0.0
> javax.servlet.api:0.0.0
> javax.transaction.api:0.0.0
> javax.ws.rs.api:0.0.0
> javax.xml.bind.api:0.0.0
> javax.xml.ws.api:0.0.0
> org.jboss.as.osgi.http:0.0.0
--
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