[JBoss JIRA] (WFLY-1055) Complete support for OSGi JPA
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-1055?page=com.atlassian.jira.plugin.... ]
Thomas Diesler resolved WFLY-1055.
----------------------------------
Resolution: Won't Fix
Won't Fix - OSGi is going to get removed
> Complete support for OSGi JPA
> -----------------------------
>
> Key: WFLY-1055
> URL: https://issues.jboss.org/browse/WFLY-1055
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate, OSGi
> Reporter: Thomas Diesler
> Assignee: Scott Marlow
> 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
10 years, 10 months
[JBoss JIRA] (WFLY-1199) Provide management view for bundle wiring
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-1199?page=com.atlassian.jira.plugin.... ]
Thomas Diesler resolved WFLY-1199.
----------------------------------
Resolution: Won't Fix
Won't Fix - OSGi is going to get removed
> Provide management view for bundle wiring
> -----------------------------------------
>
> Key: WFLY-1199
> URL: https://issues.jboss.org/browse/WFLY-1199
> Project: WildFly
> Issue Type: Feature Request
> Components: OSGi
> Environment: Mac OS X 10.7.3
> Reporter: Tim Diekmann
> Labels: Console
>
> The OSGi management console for AS 7 needs a viewer of the current wiring. The console log showed the following error on start of the bundle and there is no way to inspect the wiring to see where the problem lies and how to solve it. There is some inconsistency in the deployment, but how to find out what?
> {code}
> 00:09:14,480 ERROR [org.mortbay.log] (HttpManagementService-threads - 3) Error starting handlers: java.lang.IncompatibleClassChangeError: Class org.eclipse.equinox.http.servlet.HttpServiceServlet does not implement the requested interface javax.servlet.Servlet
> at org.eclipse.equinox.http.jetty.internal.HttpServerManager$InternalHttpServiceServlet.init(HttpServerManager.java:294)
> at org.mortbay.jetty.servlet.ServletHolder.initServlet(ServletHolder.java:431)
> at org.mortbay.jetty.servlet.ServletHolder.doStart(ServletHolder.java:263)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:681)
> at org.mortbay.jetty.servlet.Context.startContext(Context.java:140)
> at org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:517)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:130)
> at org.mortbay.jetty.Server.doStart(Server.java:224)
> at org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
> at org.eclipse.equinox.http.jetty.internal.HttpServerManager.updated(HttpServerManager.java:109)
> at org.eclipse.equinox.http.jetty.internal.Activator.start(Activator.java:60)
> at org.jboss.osgi.framework.internal.HostBundleState.transitionToActive(HostBundleState.java:300)
> at org.jboss.osgi.framework.internal.HostBundleState.startInternal(HostBundleState.java:223)
> at org.jboss.osgi.framework.internal.AbstractBundleState.start(AbstractBundleState.java:488)
> at org.jboss.as.osgi.parser.BundleRuntimeHandler.handleOperation(BundleRuntimeHandler.java:132)
> at org.jboss.as.osgi.parser.BundleRuntimeHandler.executeRuntimeStep(BundleRuntimeHandler.java:89)
> at org.jboss.as.controller.AbstractRuntimeOnlyHandler$1.execute(AbstractRuntimeOnlyHandler.java:90)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:387)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:274)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:202)
> at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:461)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:387)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:274)
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:202)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:121)
> at org.jboss.as.controller.ModelControllerImpl$1.execute(ModelControllerImpl.java:304)
> at org.jboss.as.controller.ModelControllerImpl$1.execute(ModelControllerImpl.java:294)
> at org.jboss.as.domain.http.server.DomainApiHandler.processRequest(DomainApiHandler.java:294)
> at org.jboss.as.domain.http.server.DomainApiHandler.doHandle(DomainApiHandler.java:201)
> at org.jboss.as.domain.http.server.DomainApiHandler.handle(DomainApiHandler.java:208)
> at org.jboss.as.domain.http.server.security.SubjectAssociationHandler.handle(SubjectAssociationHandler.java:51)
> at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
> at org.jboss.sun.net.httpserver.AuthFilter.doFilter(AuthFilter.java:69)
> at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
> at org.jboss.sun.net.httpserver.ServerImpl$Exchange$LinkHandler.handle(ServerImpl.java:710)
> at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:78)
> at org.jboss.as.domain.http.server.RealmReadinessFilter.doFilter(RealmReadinessFilter.java:54)
> at org.jboss.com.sun.net.httpserver.Filter$Chain.doFilter(Filter.java:81)
> at org.jboss.sun.net.httpserver.ServerImpl$Exchange.run(ServerImpl.java:682)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_29]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_29]
> at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_29]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122)
> {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
10 years, 10 months
[JBoss JIRA] (WFLY-558) Allow management client to associate metadata with DeploymentUnit
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-558?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler resolved WFLY-558.
---------------------------------
Resolution: Won't Fix
Won't Fix - OSGi is going to get removed
> Allow management client to associate metadata with DeploymentUnit
> -----------------------------------------------------------------
>
> Key: WFLY-558
> URL: https://issues.jboss.org/browse/WFLY-558
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management, OSGi, Server
> Reporter: Thomas Diesler
> Assignee: Brian Stansberry
> Fix For: 9.0.0.CR1
>
>
> Currently there is no way to pass some metadata through the deployment API such that they could show up with the DU.
> As a client I'd like to say autostart=false and in my DUP I'd like to pick that up and not start a deployment (i.e. a bundle) automatically
> Generally it should be possible for the client to set some properties for the deployment in a generic way such that they get associated with the DeploymentUnit
> For an OSGi deployment it would be necessary to be able to define that start behaviour and the start level.
--
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
10 years, 10 months
[JBoss JIRA] (WFLY-555) Complete support for Bundle start/stop
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-555?page=com.atlassian.jira.plugin.s... ]
Thomas Diesler resolved WFLY-555.
---------------------------------
Resolution: Won't Fix
Won't Fix - OSGi is going to get removed
> Complete support for Bundle start/stop
> ---------------------------------------
>
> Key: WFLY-555
> URL: https://issues.jboss.org/browse/WFLY-555
> Project: WildFly
> Issue Type: Sub-task
> Components: OSGi, Server
> Reporter: Thomas Diesler
> Assignee: Thomas Diesler
> Labels: roadmap
> Fix For: 9.0.0.CR1
>
>
> A Bundle start/stop operation activates/deactivates the bundle services. The associated class loader and wiring is unaffected.
> Approach #1 - start/stop is not mapped to deployment operations
> Bundle deploy installs the Bundle to the Framework
> Bundle is not resolved/started as part of the deploy operation
> No module/classloader is created during deployment
> All deployment processing that needs load classes/resources is skipped
> No service provided by the bundle deployment is created
> Bundle needs to be started/stopped explicitly
> Bundle start/stop management operations are specific to bundle deployments
> The POST_MODULE processing for OSGi enabled deployments (e.g. webapp) would need to be executed in an OSGi specific processor chain
> OSGi enabled POST_MODULE DUPs have their functionality externalised such that it can get reused for start/stop operations
> The start/stop processing chain must be traversable in both directions repeatedly
> Approach #2 - start/stop is mapped to deployment operations
> Bundle deploy installs the Bundle to the Framework and attempts to resolve/start the Bundle
> If the Bundle can get resolved, a module/classloader is created as part of the DU processing
> In case the Bundle cannot get resolved, DUP processing is deferred and MODULE phase processing is reattempted later based on an external trigger
> Has the benefit that any deployment type can also be a Bundle
> Bundle stop must reverse work that is done in POST_MODULE DUPs
> POST_MODULE DUPs must be traversable in both direction multiple times
> Currently, we use approach #2 with limited support from POST_MODULE DUPs (i.e. they are not designed to be executed multiple times for the same deployment). There is also the cleanup phase which breaks multiple executions of POST_MODULE DUPs.
--
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
10 years, 10 months
[JBoss JIRA] (WFLY-1100) Complete support for OSGi JNDI
by Thomas Diesler (JIRA)
[ https://issues.jboss.org/browse/WFLY-1100?page=com.atlassian.jira.plugin.... ]
Thomas Diesler resolved WFLY-1100.
----------------------------------
Resolution: Won't Fix
Won't Fix - OSGi is going to get removed
> Complete support for OSGi JNDI
> ------------------------------
>
> Key: WFLY-1100
> URL: https://issues.jboss.org/browse/WFLY-1100
> Project: WildFly
> Issue Type: Feature Request
> Components: Naming, OSGi
> Reporter: Thomas Diesler
> Labels: roadmap
>
> As expected because of the missing integration with the NamingManger singletons, all tests that go through NamingManager to obtain the InitialContextFactory or the ObjectFactory fail.
> {code}
> Running org.jboss.test.osgi.example.jndi.JNDITestCase
> Tests run: 12, Failures: 1, Errors: 2, Skipped: 2, Time elapsed: 15.574 sec <<< FAILURE!
> Results :
> Failed tests: testContextManagerReferenceBinding(org.jboss.test.osgi.example.jndi.JNDITestCase): expected:<bar> but was:<Reference Class Name: java.lang.String(..)
> Tests in error:
> testTraditionalAPIValueBinding(org.jboss.test.osgi.example.jndi.JNDITestCase): JBAS011843: Failed instantiate InitialContextFactory org.jboss.test.osgi.example.jndi.bundle.JNDITestActivator$SimpleInitalContextFactory from classloader ModuleClassLoader for Module "deployment.arquillian-service:main" from Service Module Loader
> testTraditionalAPIReferenceBinding(org.jboss.test.osgi.example.jndi.JNDITestCase): JBAS011843: Failed instantiate InitialContextFactory org.jboss.test.osgi.example.jndi.bundle.JNDITestActivator$SimpleInitalContextFactory from classloader ModuleClassLoader for Module "deployment.arquillian-service:main" from Service Module Loader
> {code}
> In reality it means that OSGi Bundles cannot use JNDI with object References and cannot expect the traditional JNDI API to work. These findings generally raise the question how a spec compliant OSGI JNDI Implementation is supposed to work in a container environment. Specifically, in an environment that has already set the NamingManager singletons.
> IMHO there is a layer of abstraction missing. Perhaps the container should register a NamingManger service that the JNDI Implementation can use to register its InitialContextFactoryBuilder and ObjectFactoryBuilder.
--
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
10 years, 10 months