[dev] Migrate mhus-sop to mhus-rest and mhus-micro

 For reorganisation I split the project mhus-sop to mhus-rest and mhus-micro and parts in the existing mhus-osgi-tools. Now mhus-sop (service orientated platform) is depecated.


The parts to handle rest interfaces is moved to mhus-rest. Why another rest framework? Because this rest is prepared to handle deep rest structures instead of for example jax-rs.

The parts for Operations and Operation providers are moved to mhus-micro. This is the central framework to work with micro services. It's able to combine different micro service frameworks to one interface.

The part AAA and ADB Service is moved into mhus-osgi-tools.

Some interfaces are moved directly in mhus-lib. The tool IdentUtil will return the current ident without big actions.



Before and After - mhus-config:

de.mhus.osgi.sop.jms.operation.JmsRegistryProvider - de.mhus.micro.core.api.JmsApi
de.mhus.lib.core.security.AccountSource - de.mhus.lib.core.security.AccountSource
de.mhus.osgi.sop.api.aaa.TrustSource - de.mhus.lib.core.security.TrustSource
de.mhus.osgi.sop.impl.aaa.util.AccountFromFile - de.mhus.osgi.services.aaa.util.AccountFromFile
de.mhus.osgi.sop.impl.aaa.util.AuthFromFile - de.mhus.osgi.services.aaa.util.AuthFromFile
de.mhus.osgi.sop.impl.aaa.util.TrustFromFile - de.mhus.osgi.services.aaa.util.TrustFromFile
de.mhus.osgi.sop.impl.aaa.AccessApiImpl - de.mhus.osgi.services.aaa.AccessApiImpl
de.mhus.osgi.sop.api.aaa.AccessApi - de.mhus.lib.core.security.AccessApi
de.mhus.osgi.sop.impl.cluster.ClusterApiViaRegistry - de.mhus.osgi.services.cluster.ClusterApiViaRegistry
de.mhus.osgi.sop.api.cluster.ClusterApi - de.mhus.lib.core.base.service.ClusterApi
de.mhus.osgi.sop.impl.adb.SopDbManagerService - de.mhus.osgi.services.adb.SopDbManagerService


And ...

move <karaf>/sop to <karaf>/data

Comments

Post a Comment

Popular posts from this blog

Sonatype Nexus fails with random "peer not authenticated" errors behind ingress

 After installing nexus3 server in a kubernetes environment in the first view everything looks good. Server is running an accessible from the world. Users and roles are defined and working. But already in the first hours of working with the repository there are problems. The trick was retry the failed activity and everything went ok. It turned out that heavy activities failed a lot of times and a lot of retries have to be done to finish the tasks. Annoying if a release deploy failed. You need to increase the version number every time. There were a few support in the internet for the problems most of the time handling SSL problems between maven and nexus. But it did not fix the problem. It looks like maven and the used http library wagon have got problems with pooled connections if using ingress (a test with a standalone installation did not show the problem)  - The 'deep' reason is not really clear for me, need to invest more time for it. The solution is to deny wagon to use po
Read more

Creating a flux sync configuration referring a config map for substitution

 If you configure your k8s cluster with terraform one of the final steps is to install a fluxcd operator. The operator are responsible to manage the resources inside of the cluster. In this way a fully automatic creation process is possible. To install flux a terraform provider is available preparing a install and sync configuration which can be installed in k8s using the kubernetes/kubectl providers. In fluxcd itself it is possible to use substitution . This means you can use variables to prepare the k8s yaml files. This is useful for variable content like different cluster names and domain names for all stages. Or more specialised arn ids of created resources while creating the cluster in aws. To use substitution fluxcd offers to link the configuration to a config map. In the map a set of key values can be defined to replace variable values. The map can also be created with terraform and the kubectl provider. Do not store secrets in the config map. Try to use secrets instead. Applyi
Read more

[mhus lib] Reorg in generation 7 nearly finished

 The generation 7 shows massive reorganisations and reimplementations. After renaming repository names (moved the 'cherry' prefix to 'mhus') the reorg is finished and the sources are ready for a more stable generation 8. Generation 8 will add new features to work with none OSGi services in cloud environments. Actual changes: cherry-reactiive -> mhus-reactive cherry-vault -> mhus-vault cherry-web -> mhus-web mhus-osgi-cluster -> mhus-cluster
Read more