[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
13 years, 4 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
13 years, 4 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
13 years, 4 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
13 years, 4 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
13 years, 4 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
13 years, 4 months
[JBoss JIRA] (JBJCA-951) The pool statistics "Available" shows wrong value after fill pool
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-951?page=com.atlassian.jira.plugin.... ]
Jesper Pedersen resolved JBJCA-951.
-----------------------------------
Resolution: Done
> The pool statistics "Available" shows wrong value after fill pool
> -----------------------------------------------------------------
>
> Key: JBJCA-951
> URL: https://issues.jboss.org/browse/JBJCA-951
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.14.Final, 1.1.0.Beta3
> Reporter: Masafumi Miura
> Assignee: Jesper Pedersen
> Fix For: 1.0.15.Final, 1.1.0.Beta4
>
>
> The pool statistics' "Available" shows wrong value (one less than "max-pool-size") after fill pool.
> For example, min-pool-size=5, max-pool-size=10 and prefill=true are set to datasource configuration:
> {code:xml}
> <pool>
> <min-pool-size>5</min-pool-size>
> <max-pool-size>10</max-pool-size>
> <prefill>true</prefill>
> </pool>
> {code}
> Then, when checking pool stats via CLI after JBoss start-up, the results shows the following:
> {code}
> [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS/statistics=pool/:read-resource(recursive=false,proxies=false,include-runtime=true,include-defaults=true)
> {
> "outcome" => "success",
> "result" => {
> "ActiveCount" => "5",
> "AvailableCount" => "9",
> "AverageBlockingTime" => "0",
> "AverageCreationTime" => "3",
> "CreatedCount" => "5",
> "DestroyedCount" => "0",
> "MaxCreationTime" => "4",
> "MaxUsedCount" => "1",
> "MaxWaitTime" => "0",
> "TimedOut" => "0",
> "TotalBlockingTime" => "0",
> "TotalCreationTime" => "17"
> }
> }
> {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] (JBJCA-951) The pool statistics "Available" shows wrong value after fill pool
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-951?page=com.atlassian.jira.plugin.... ]
Jesper Pedersen moved JBPAPP6-1737 to JBJCA-951:
------------------------------------------------
Project: IronJacamar (was: JBoss Enterprise Application Platform 6)
Key: JBJCA-951 (was: JBPAPP6-1737)
Affects Version/s: 1.1.0.Beta3
1.0.14.Final
(was: EAP 6.0.0)
Component/s: Core
(was: JCA)
Security: (was: Public)
Fix Version/s: 1.0.15.Final
1.1.0.Beta4
(was: TBD EAP 6)
Docs QE Status: (was: NEW)
> The pool statistics "Available" shows wrong value after fill pool
> -----------------------------------------------------------------
>
> Key: JBJCA-951
> URL: https://issues.jboss.org/browse/JBJCA-951
> Project: IronJacamar
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.0.Beta3, 1.0.14.Final
> Reporter: Masafumi Miura
> Assignee: Jesper Pedersen
> Fix For: 1.0.15.Final, 1.1.0.Beta4
>
>
> The pool statistics' "Available" shows wrong value (one less than "max-pool-size") after fill pool.
> For example, min-pool-size=5, max-pool-size=10 and prefill=true are set to datasource configuration:
> {code:xml}
> <pool>
> <min-pool-size>5</min-pool-size>
> <max-pool-size>10</max-pool-size>
> <prefill>true</prefill>
> </pool>
> {code}
> Then, when checking pool stats via CLI after JBoss start-up, the results shows the following:
> {code}
> [standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS/statistics=pool/:read-resource(recursive=false,proxies=false,include-runtime=true,include-defaults=true)
> {
> "outcome" => "success",
> "result" => {
> "ActiveCount" => "5",
> "AvailableCount" => "9",
> "AverageBlockingTime" => "0",
> "AverageCreationTime" => "3",
> "CreatedCount" => "5",
> "DestroyedCount" => "0",
> "MaxCreationTime" => "4",
> "MaxUsedCount" => "1",
> "MaxWaitTime" => "0",
> "TimedOut" => "0",
> "TotalBlockingTime" => "0",
> "TotalCreationTime" => "17"
> }
> }
> {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-5482) Improve regularity of CLI syntax to add connection-definition in resource-adapter subsystem
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/AS7-5482?page=com.atlassian.jira.plugin.s... ]
Jesper Pedersen closed AS7-5482.
--------------------------------
Resolution: Won't Fix
The DMR model can't be changed, so rejected
> Improve regularity of CLI syntax to add connection-definition in resource-adapter subsystem
> -------------------------------------------------------------------------------------------
>
> Key: AS7-5482
> URL: https://issues.jboss.org/browse/AS7-5482
> Project: Application Server 7
> Issue Type: Enhancement
> Components: Domain Management, JCA
> Affects Versions: 7.1.2.Final (EAP)
> Reporter: Akram Ben Aissi
> Assignee: Jesper Pedersen
>
> The syntax to add a pool in a connection-definition in resource-adapter subsystem is not as regular as expected in comparison with the other CLI commands.
> e.g: To set the min-pool-size
> {code}/subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/connection-definitions=MQConnectionFactory:write-attribute(name=min-pool-size,value=10)
> {code}
> Where the XML is:
> {code}
> <connection-definitions>
> <connection-definition class-name="com.ibm.mq.connector.outbound.ManagedQueueConnectionFactoryImpl"
> jndi-name="java:/jboss/jms/wmqcf"
> use-java-context="true" pool-name="MQConnectionFactory">
> <pool>
> <min-pool-size>1</min-pool-size>
> <max-pool-size>10</max-pool-size>
> </pool>
> </connection-definition>
> {code}
> One would expect the syntax to be more:
> {code}/subsystem=resource-adapters/resource-adapter=wmq.jmsra.rar/connection-definitions=MQConnectionFactory/pool:write-attribute(name=min-pool-size,value=10)
> {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-6075) Provide access to OSGiMetaData for server, web, etc
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/AS7-6075?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler updated AS7-6075:
--------------------------------
Fix Version/s: 7.2.0.CR1
> Provide access to OSGiMetaData for server, web, etc
> ---------------------------------------------------
>
> Key: AS7-6075
> URL: https://issues.jboss.org/browse/AS7-6075
> Project: Application Server 7
> Issue Type: Feature Request
> Components: OSGi, Server
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Fix For: 7.2.0.CR1
>
>
> Currently we have a policy that server does not have a dependency on OSGi API and as a result to OSGiMetaData.
> In several places we do a check like this
> {code}
> if (depUnit.hasAttachment(Attachments.OSGI_MANIFEST)) {
> ...
> }
> {code}
> This however implies that the Manifest is the only possible source of valid OSGi metadata. The OSGi webapp spec allows for metadata to be specified as part of a "webbundle://" URI (see AS7-6006)
> To make this work, the integration code currently generates a Manifest and later OSGiMetaData from it. The above code still works even if the deployment content does not have a Manifest.
> I propose to move the OSGiMetaData one level down so that
> {code}
> if (depUnit.hasAttachment(Attachments.OSGI_METADATA)) {
> ...
> }
> {code}
> is the deciding criteria. As a additional benefit web would no longer need to produce/consume the raw Manifest headers and OSGi metadata would be treated like all other metadata structures.
--
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