I'm beginner in OSGi, My project consists of developping and executing, within an OSGi container (apache felix; the distribuable jar), a persistence bundle (using jpa) and then communicating with the database (MySql) through a jpa provider (Hibernate).
I read about the jpa specification for OSGi, so, if I have correctly understood, I must use a JPA provider for OSGi implementing the OSGI jpa enterprise specification. this jpa provider will track for a registered persistence bundle to make an EntityManagerFactory for it ?
So what is the difference between using a jpa provider directly to create the EntityManagerFactory (Persistence.createEntityManagerFactory("xx")) or retrieving it from the registry :
serviceReferences = context.getServiceReferences(
EntityManagerFactory.class.getName(),
String.format("(%s=%s)",
EntityManagerFactoryBuilder.JPA_UNIT_NAME,
persistenceUnit));
I wouldn't like to use any container (apache karaf, geronimo, spring dm, ..) so, is it sufficient that I will instal and start in the OSGi container for example the "org.apache.aries.jpa.api" as an implementation of the OGSi enterprise jpa spec and then only retrieve an "EntityManagerFactory" service from the registry associated to my persistence unit name, or I should also register by myself a PersistenceProvider like HibernatePersistence to can declare it as "provider" in my persistence.xml file ?
I found many discussion in this topic here. I still having trouble, though
Thanks
OSGi is about services and services are extremely easy to consume in OSGi with the proper setup. You show a very old style example with service references and I do agree, in that model it is a lot easier to just use the old fashioned JPA way.
However, if you use Declarative Services, using services becomes very lightweight. You get injected with an EntityManagerFactory service that is completely prepared for you. The deployer could have tuned all kinds of settings with Config Admin, connection pools, another JPA provider, etc. It is a clear separation of concerns.
By not really knowing where this thing comes from and who implements it you get less assumptions in your code and your code will therefore be less error prone and more reusable. I principle, the fact that use Hibernate and MYSQL is completely irrelevant to most of your code. Yes, I do know that neither JPA nor SQL is very portable in practice but there are many aspects that are ignorant of the differences. It is the deployer that is then in the end responsible to put together the parts that work.
Now Declarative Services (DS) is of course an extra bundle but after using OSGi for 15 years now I declare any OSGi developer NOT using DS, well, let me not go too deep into that to keep it civil :-) If I would be back in the beginning of OSGi, DS would have been built into the framework, it is for the lowest level to program with.
Related
Recently I began working with Teiid and Wildfly. I have a user defined function (UDF) that adds custom functionality to Teiid, and it works as expected. However, I need to modify it further and would like to use CDI to inject a bean from the Wildfly app server. I know that the UDF isn't managed by the container (it is a Wildfly module with an associated module.xml file deployed as a jar), so I've added (what seemed to be) necessary dependencies to module.xml but it doesn't work.
Is it possible to use CDI in a UDF with Teiid / Wildfly, and if so, how?
No, it is not possible. although Teiid is a resident of WildFly it is using the infrastructure of WildFly for a variety of features like transactions, security, data sources, administration etc. It is not part of JEE or anything, so there is no direct way to do this. If you want to explain what you are trying to accomplish, maybe we can offer any further guidance on alternatives.
We have a webapp that is currently running on one instance of Apache Tomcat with one database instance, but the increase in traffic will soon (probably) force us to resort to load-balancing several webapp instances, and we've run into a problem that seems to have no easy answer.
Currently our JDBC DataSource is configured as Resource-local, rather than Transactional, and after some searching, everyone recommends to use Transactional, which requires the use of a JTA provider. No real justification is used for why I don't just stick with the current scenario where we have a servlet filter catch any unhandled exceptions and rollback the active transaction. Besides that the only one I've found that is just a JTA provider (not with 5 more JEE technologies combined) and is still maintained is Bitronix. The other alternative is to move out of Tomcat and use Glassfish, since it is a full Java EE platform, and we also use JavaMail, JPA and JAX-RS.
Only one transaction scenario uses Serializable isolation level.
As for the database, we may be looking too far ahead to think of distributed storage like Postgres-XL or pgpool, but if we make the wrong choice now it will be harder to fix later.
My questions are as follows:
Do synchronous database replication tools and JTA complete each-other, hinder each-other or just perform the same consistency checks twice?
Do we need JTA if we only have one database, but multiple webapp instances?
Do we need JTA if we have multiple database and multiple webapp instances?
Should we just switch to Glassfish or something like TomEE?
Supposedly there are ways we can keep using Hibernate as our JPA under both. It would be tedious to have to rewrite all our native queries to use positional parameters because EclipseLink and OpenJPA don't support them. That little extra feature makes Hibernate worth choosing above all other JPAs for me.
Pardon if I can't give more pointers, but I'm really a noob at wildfly. I'm using version 9.0.2.
I have deployed jbpm-console, drools, and dashboard - no problems here. I restart wildfly using the jboss CLI, and when I login again, the repositories won't appear in the web interface or on disk (atleast nothing that grepping or find will show).
I'm using the H2 database. I'm not even sure where to look, does anyone have any idea?
Thanks in advance!
After enough reading through the docs, it would seem that it's necessary to configure jBPM to persist. From the docs:
"By default, the engine does not save runtime data persistently. This means you can use the engine completely without persistence (so not even requiring an in memory database) if necessary, for example for performance reasons, or when you would like to manage persistence yourself. It is, however, possible to configure the engine to do use persistence by configuring it to do so. This usually requires adding the necessary dependencies, configuring a datasource and creating the engine with persistence configured."
https://docs.jboss.org/jbpm/v5.3/userguide/ch.core-persistence.html
i have osgi services service-1.0.0.jar and service-1.1.0.jar they are implementation of service-api-1.0.0.jar
both these service-1.0.0.jar and service-1.1.0.jar have same service name and packages.
service are registered by bundle-activator
lets assume bundle activator is com.abc.xyz.MyActivator - 1.0.0 and 1.1.0
issue I am facing is when I deploy these services and lookup using service tracker and filter on version I want, I always get same implementation regardless of what version chosen.
this makes me believe that what i am trying to achieve is not doable.
I need multiple implementation of service packaged in separate bundles with difference of version and be able to choose dynamically at runtime.
I am trying this in jboss-6.1.1 eap
if i keep different package name in versions looks like it is able to understand that these are 2 different services but when package names are same i get same service implementation.
am i doing something wrong? has anybody tried this?
is it correct that OSGI allow you to deploy multiple versions of service?
UPDATE After using unique package names for MyActivator in 1.0.0 and 1.1.0 looks like the services are able to maintain the uniqueness.
Does that mean Activators has to unique across bundles?
I assume that service-api-1.0.0.jar exports the package which defines the service interface. In that case, it sounds like you have two implementations of the same version of the service. Not different implementations of different versions of the service. So from a service user point of view, the services are that same: they are from the same service api package version.
I think you are using the OSGi services in a strange way. As a client you should not look into the implemention bundles to determine versions or other informations.
Instead you should use the service interface and service properties to distinguish between services.
So for example you can have a property version and publish the first service with version=1 and the second with version=2. Then you can filter for this property to get a specific service.
Using reflection is also a rather unusual thing. Better try to provide classes in the interface package that you use to exchange data between client and service. This will make the client less dependent on the service impl.
If you have multiple implementations of the same service API, and a client queries for an implementation of the service API, it could get any of the implementations. And that's good because the client shouldn't care.
Say for example you have a Greeting interface with multiple implementations registered as services, possibly by multiple bundles. If a client asks OSGi for a Greeting service then OSGi will simply pick one. After all, if you just ask for a Greeting without specifying anything else then you should accept any implementation. Clients certainly shouldn't care which particular bundle the service comes from: this is the nature of decoupling.
Incidentally, when this happens OSGi normally chooses the implementation that was registered first (actually the one with the lowest service.id, which is an ever-incrementing number, so it's effectively the same thing). This is probably why you see OSGi consistently choosing one particular service.
If your client needs to distinguish between service implementations then you can add properties to the published services and filter on those services. For example one bundle could publish a Greeting service with property language=en_US (i.e. US English) and another could publish a Greeting service with language=de. If your client only wants greetings in English then it can use a filter like (language=en*).
I have a scenario where during the system install time, a few services were deployed on to the OSGi container and these services will be listening for other bundles that provide data and are dynamically installed and uninstalled at runtime.
These data providers do not expose any services and should not even invoke services; my idea is to enable the pre-deployed services to listen for the event of installation of these data provider bundles and if the pattern matches, then process and persist the data into the data store.
For example I have a WidgetService which will listen for installation or uninstallation event of Widget data provider bundles, ShppingCartService that will listen for the installation/uninstallation events from ShoppableItem data provider bundles, etc.
This helps me to keep the processing and persisting logic be centralized and my data providers need not write any code to make their data processed. All that is expected from the data provider bundles is the Service Name/id, Service Version,PreRequisites, and the data that they need to publish.
I have read several articles on OSGi that explain dynamic pluggability of services and the clients able to discover or discard services based on their availabity; however, those are all talking about scenarios where clients are to be intelligent to discover and execute the services they are interested in.
My intention is to make client completely unaware of any service discovery, for that matter any code. All that the client passes is the info about the service the client is interseted in, the dependencies, and the data; the client should be completely dumb.
Is this possible in OSGi? I'm ready to consider this architecture even at the cost of extending a few of the OSGi core framework classes!
I have found some what, may be, remotely related question on stack overflow at :
Discovering Bundle MetaData with out installing the bundle
However, I want a hook or an event that will call my respective service when one or more data provider bundles have been installed. These data provider bundles can be interested in any of the services that are installed in the system. I'm even ready to write a central bunle repository manager/listener kind of stuff that will listen to any bundle installation and invoke my Service facade that will decide which service to execute based on the meta data provided by the data provider bundle.
I'm just starting OSGi, so need a little direction on how to move forward...
I'll be really thankful to you guys/girls :) if you can help me achieve this!
I have a doubt deep in my mind that this may not be readily available in OSGi, and even if that is true I'm ready to spend time and extend the framework to achieve this. All I need is a few guidelines and a clear direction. Who knows, if OSGi is really lacking this functionality, then it would be a very useful add-on to a future OSGi spec.
You might have a look at section 4.7 (Events) of the OSGi Core spec. The Framework raises BundleEvents when there is a change in the lifecycle of a bundle, e.g. when it is installed or uninstalled. What you need to do is to implement a BundleListener, which then will receive the events, so your service can react on the changes.
I have described a design pattern that I call "OSGi Mediator", which may be a solution to your problem.
The items you want to mediate would only require to register with the service registry; all the dependencies could be managed by your mediator implementation.