July 2013 - jboss-osgi-issues - Jboss List Archives

[JBoss JIRA] (JBOSGI-700) Karaf configuration through ConfigAdmin

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-700?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1125 to JBOSGI-700: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-700 (was: WFLY-1125) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) > Karaf configuration through ConfigAdmin > --------------------------------------- > > Key: JBOSGI-700 > URL: https://issues.jboss.org/browse/JBOSGI-700 > Project: JBoss OSGi > Issue Type: Feature Request > Reporter: Thomas Diesler > > Currently we add these props to standalone.conf > {code} > -Dkaraf.home=.../jboss-as-karaf-7.2.0.Alpha1-SNAPSHOT/standalone/data/karaf -Dkaraf.base=.../jboss-as-karaf-7.2.0.Alpha1-SNAPSHOT/standalone/data/karaf -Dkaraf.startRemoteShell=true -Dkaraf.startLocalConsole=false > {code} > For this we should have sensible defaults as well as make the SSH port (and possibly other options) configurable through ConfigAdmin -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-702) Add support for Enterprise Subsystem Archives

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-702?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-345 to JBOSGI-702: -------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-702 (was: WFLY-345) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) > Add support for Enterprise Subsystem Archives > --------------------------------------------- > > Key: JBOSGI-702 > URL: https://issues.jboss.org/browse/JBOSGI-702 > Project: JBoss OSGi > Issue Type: Feature Request > Reporter: Thomas Diesler > > Add support for *.esa deployments as specified by R5 Subsystem Service Specification > -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-710) 128.3.1 WAB Definition

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-710?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-659 to JBOSGI-710: -------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-710 (was: WFLY-659) Workflow: jira (was: GIT Pull Request workflow ) > 128.3.1 WAB Definition > ---------------------- > > Key: JBOSGI-710 > URL: https://issues.jboss.org/browse/JBOSGI-710 > Project: JBoss OSGi > Issue Type: Sub-task > Reporter: David Bosschaert > Assignee: Thomas Diesler > -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-699) Initial OSGi / CDI Integration

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-699?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1153 to JBOSGI-699: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-699 (was: WFLY-1153) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: CDI / Weld) (was: OSGi) > Initial OSGi / CDI Integration > ------------------------------- > > Key: JBOSGI-699 > URL: https://issues.jboss.org/browse/JBOSGI-699 > Project: JBoss OSGi > Issue Type: Feature Request > Reporter: Thomas Diesler > Labels: roadmap > > Provide an example test that shows CDI integration -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-698) Provide access to OSGiMetaData for server, web, etc

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-698?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1104 to JBOSGI-698: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-698 (was: WFLY-1104) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) (was: Server) > Provide access to OSGiMetaData for server, web, etc > --------------------------------------------------- > > Key: JBOSGI-698 > URL: https://issues.jboss.org/browse/JBOSGI-698 > Project: JBoss OSGi > Issue Type: Feature Request > Reporter: Thomas Diesler > > 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

12 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-697) Complete support for OSGi JPA

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-697?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1055 to JBOSGI-697: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-697 (was: WFLY-1055) Workflow: jira (was: GIT Pull Request workflow ) Component/s: JPA/JDBC (was: JPA / Hibernate) (was: OSGi) > Complete support for OSGi JPA > ----------------------------- > > Key: JBOSGI-697 > URL: https://issues.jboss.org/browse/JBOSGI-697 > Project: JBoss OSGi > Issue Type: Feature Request > Components: JPA/JDBC > Reporter: Thomas Diesler > Labels: roadmap > > h6. 127.3.1 Services > _Entity Manager Factory Builder service_ - The Entity Manager Factory Builder service provides the capability of creating an EntityManagerFactory object with additional configuration properties > Add EntityManagerFactory service properties > * osgi.unit.name - The name of the Persistence Unit (done) > * osgi.unit.version - The version of the associated Persistence Bundle > * osgi.unit.provider - The implementation class name of the JPA Provider > h6. 127.3.4 Custom Configured Entity Manager > If a Client Bundle needs to provide configuration properties for the creation of an Entity Manager Factory it should use the Entity Manager Factory Builder service. This can for example be used to provide the database selection properties when the Persistence Unit is incomplete or if the database selection needs to be overridden. > Once an Entity Manager Factory is created the specified Data Source becomes associated with the Entity Manager Factory. It is therefore not possible to re-associate an Entity Manager Factory with another Data Source by providing different properties. A JPA Provider must throw an Exception when an attempt is made to re-specify the database properties. > h6. 127.4.2 Meta Persistence Header > Support non-default persistence descriptors through the Meta-Persistence header > For example: _Meta-Persistence: META-INF/jpa.xml, persistence/jpa.xml_ > h6. 127.4.3 Processing > The JPA Provider must validate the Persistence Bundle. A valid Persistence Bundle must: > * Have no parsing errors of the Persistence Descriptors > * Validate all Persistence Descriptors against their schemas > * Have at least one assigned Persistence Unit > * Have all entity classes mentioned in the assigned Persistence Units on the Persistence Bundles JAR. > If any validation fails, then this is an error and should be logged. Such a bundle is ignored completely even if it also contains valid assigned Persistence Units. Only a bundle update can recover from this > state. > h6. 127.4.8 Stopping > If a Persistence Bundle is being stopped, then the JPA Provider must ensure that any resources allocated on behalf of the Persistence Bundle are cleaned up and all open connections are closed. This cleanup must happen synchronously with the STOPPING event. Any Exceptions being thrown while cleaning up should be logged but must not stop any further clean up. > If the JPA Provider is being stopped, the JPA Provider must unregister all JPA Services that it registered through the Persistence Bundles and clean up as if those bundles were stopped. > h6. 127.5.3 Data Source Factory Service Matching > Providers must use the javax.persistence.jdbc.driver property, as defined in JDBC Access in JPA on page 406, to obtain a Data Source Factory service. The Data Source Factory is specified in JDBC Service Specification on page 375. The javax.persistence.jdbc.driver property must be matched with the value of the Data Source Factory service property named osgi.jdbc.driver.class. > h6. 127.5.4 Rebinding > In this specification, the Entity Manager Factory service is only registered when the Persistence Unit is complete and a matching Data Source Factory service is available. However, the API of the Entity > Manager Factory allows the creation of an Entity Manager with configuration properties. Those configuration properties could contain the JDBC properties to bind to another Data Source Factory service than it had already selected. > This case must not be supported by a JPA Provider, an Illegal Argument Exception must be thrown. > h6. 127.6 Static Access > A Static Persistence Bundle must provide static access from the Persistence class to the JPA Services. > This issue is complete when the TCK passes -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-694) Complete support for OSGi Blueprint

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-694?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1096 to JBOSGI-694: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-694 (was: WFLY-1096) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) > Complete support for OSGi Blueprint > ----------------------------------- > > Key: JBOSGI-694 > URL: https://issues.jboss.org/browse/JBOSGI-694 > Project: JBoss OSGi > Issue Type: Feature Request > Reporter: Thomas Diesler > Labels: roadmap > > R5 TCK compliance for Blueprint -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-692) Complete support for OSGi JTA

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-692?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1178 to JBOSGI-692: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-692 (was: WFLY-1178) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) (was: Transactions) > Complete support for OSGi JTA > ----------------------------- > > Key: JBOSGI-692 > URL: https://issues.jboss.org/browse/JBOSGI-692 > Project: JBoss OSGi > Issue Type: Feature Request > Reporter: Thomas Diesler > Labels: roadmap > > R5 TCK compliance for JTA -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-696) Complete support for OSGi webapps in JBossWeb

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-696?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-658 to JBOSGI-696: -------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-696 (was: WFLY-658) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) > Complete support for OSGi webapps in JBossWeb > --------------------------------------------- > > Key: JBOSGI-696 > URL: https://issues.jboss.org/browse/JBOSGI-696 > Project: JBoss OSGi > Issue Type: Feature Request > Reporter: Thomas Diesler > Labels: roadmap > Attachments: webapp-1.0.pdf > > > Following initial support for WAB please review the spec and implement missing functionality. > h5. 128.3.1 WAB Definition > The web.xml must be found with the Bundle findEntries method. The findEntries method includes fragments, allowing the web.xml to be provided by a fragment. > h5. 128.3.2 Starting the Web Application Bundle > The Web Extender should ensure that serving static content from the WAB does not activate the WAB when it has a lazy activation policy. > Validate that the Web-ContextPath manifest header does not match the Context Path of any other currently deployed web application. > h5. 128.3.4 Publishing the Servlet Context > The Web Extender must register the Servlet Context of the WAB as a service, using the Bundle Context of the WAB. > h5. 128.3.5 Static Content > For confidentiality reasons, a Web Runtime must not return any static content for paths that start with one of the following prefixes: > WEB-INF/ > OSGI-INF/ > META-INF/ > OSGI-OPT/ > h5. 128.3.8 Stopping the Web Application Bundle > It is possible that there are one or more colliding WABs because they had the same Context Path as this stopped WAB. If such colliding WABs exists then the Web Extender must attempt to deploy the colliding WAB with the lowest bundle id. > h5. 128.5 Events > * org/osgi/service/web/DEPLOYING The Web Extender has accepted a WAB and started the process of deploying a Web Application. > * org/osgi/service/web/DEPLOYED The Web Extender has finished deploying a Web Application, and the Web Application is now available for web requests on its Context Path. > * org/osgi/service/web/UNDEPLOYING The web extender started undeploying the Web Application in response to its corresponding WAB being stopped or the Web Extender is stopped. > * org/osgi/service/web/UNDEPLOYED The Web Extender has undeployed the Web Application. The application is no longer available for web requests. > * org/osgi/service/web/FAILED The Web Extender has failed to deploy the Web Application, this event can be fired after the DEPLOYING event has fired and indicates that no DEPLOYED event will be fired. > h5. 128.6.1 Bundle Context Access > A Servlet can obtain a Bundle Context as follows: > {code} > BundleContext ctxt = (BundleContext) > servletContext.getAttribute(osgi-bundlecontext); > {code} > h5. 128.6.3 Resource Lookup > The getResource and getResourceAsStream methods of the ServletContext interface are used to access resources in the web application. For a WAB, these resources must be found according to the findEntries method, this method includes fragments. > The getResourcePaths method must map to the Bundle getEntryPaths method, its return type is a Set and can not handle multiples. However, the paths from the getEntryPaths method are relative while the methods of the getResourcePaths must be absolute. > h5. 128.6.5 JavaServer Pages Support > The Web Runtime can construct a special class loader to load generated JSP > classes such that classes from the bundle class path are visible to newly compiled JSP classes. > This issue is complete when the TCK passes -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (JBOSGI-693) Allow OSGi configuration to get modified before subsystem start

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/JBOSGI-693?page=com.atlassian.jira.plugin... ] Thomas Diesler moved WFLY-1187 to JBOSGI-693: --------------------------------------------- Project: JBoss OSGi (was: WildFly) Key: JBOSGI-693 (was: WFLY-1187) Workflow: jira (was: GIT Pull Request workflow ) Component/s: (was: OSGi) > Allow OSGi configuration to get modified before subsystem start > --------------------------------------------------------------- > > Key: JBOSGI-693 > URL: https://issues.jboss.org/browse/JBOSGI-693 > Project: JBoss OSGi > Issue Type: Feature Request > Reporter: Thomas Diesler > > It should be possible to > * start the server > * modify framework properties > * start the osgi subsystem with the updated properties -- 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, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

jboss-osgi-issues July 2013