I have updated these libraries for messaging in a project to the latest versions:
Rebus
Rebus.RabbitMQ
Rebus.Castle.Windsor
Rebus.Log4Net
Castle.Windsor
I was very confused when found that some of very convenient old methods are missing in this versions.
I have the following rebus configuration api:
Configure.With(new WindsorContainerAdapter(container))
.Logging(l => l.Log4Net())
.Transport(t => t.UseRabbitMqAndGetInputQueueNameFromAppConfig(connectionString)
.ManageSubscriptions().SetPrefetchCount(5))
.MessageOwnership(d => d.FromRebusConfigurationSection())
.Serialization(s => s.Use(new MySerializer()))
.CreateBus()
.Start();
These methods are absent in the new version:
UseRabbitMqAndGetInputQueueNameFromAppConfig
ManageSubscriptions in RabbitMqOptionsBuilder
MessageOwnership in RebusConfigurer
Log4Net extension methods is present in library not even recognized by VS
The Rebus documentation though still has references on old methods and scenarios in many places.
What has been done with old convenient methods? Has anybody had the same problem and could give me a hint what apis to use in the current version (0.99.67) for existing way of configuring a client.
Rebus versions up to and including 0.84.0 are "Rebus 1" - Rebus received a pretty big update (a rewrite of the core, followed by porting most libs forwards) in version 0.90.0 - "Rebus 2"
So your best bet is probably to Update-Package Rebus -Version 0.84.0 (and do the same to the RabbitMQ, Windsor, and Log4net integration packages)
Rebus 2 is not compatible with Rebus 1, so if you decide to update to 2, you should be aware of that.
Moreover (as you have discovered) it has seen a couple of API changes, where the most significant change is that most methods on IBus are now async and thus requires that you e.g await bus.Send(...) (or bus.Send(...).Wait() if you are not in an async method)
Related
While building the code getting package sun.security.action is not visible
Package sun.security.action is declared on module java.base, which does not export it to the unnamed module.
What should I do.
Kindly advice, Thanks in advance
Java 8 had no module system - everything is visible or just needs to get imported by archives in jdk (f.e. tools.jar).
Java 9 brought JMS and encapsulated some jdk classes.
In your case, see <JAVA_HOME>/lib/src.zip!/java.base/module-info.class:
exports sun.security.action to
java.desktop,
java.security.jgss,
jdk.crypto.ec,
jdk.incubator.foreign;
Your package isn't public but restricted to some other internal packages/modules.
There was a workaround by adding compiler option --add-exports=java.base/sun.security.action=ALL-UNNAMED at compile time to fix this limitation until version 16.
With version 17 and JEP 403 forget all hope:
It is not a goal to define new standard APIs to replace internal elements for which standard replacements do not yet exist, though such APIs could be suggested in response to this JEP.
Backwards compatibility and important frameworks have lower priority than jdk security - JCP makes strange decisions and works against the community sometimes -.-
I have created an OSGi bundle (written in Kotlin) containing a very basic component, which I have annotated as #Component(immediate = true). This bundle behaves as expected using Felix 6.0.3.
#Component(immediate = true)
class Bongo #Activate constructor(
#Reference(service = LoggerFactory::class)
private val logger: Logger
) {
init {
System.err.println("-------------- BONGO!")
logger.info("Started {}", this::class.java)
}
#Activate
fun doIt() {
throw InternalError("BOOM!")
}
}
I then zip this bundle up (with some others) and feed it into Apache Aries as a trivial application subsystem. I haven't created an explicit SUBSYSTEM.MF here because the default values appear to be what I want. Aries installs and starts my subsystem, and then reports that it is ACTIVE. I have even confirmed that a BundleActivator has been invoked correctly. However, I see no evidence that my #Component has been started. It looks like SCR has ignored it, which seems odd because I would have thought that I'd need SCR to run an application subsystem. (I have heard that Declarative Services have replaced BundleActivator...)
I have scoured the OSGi documentation and found no mention of needing to do anything with an OSGi subsystem other than "start" it, so I am baffled at how to proceed from here. Can anyone suggest anything I might have missed please?
For reference, these are the Felix / Aries bundles from my bndrun file:
org.apache.aries.subsystem.api;version='[2.0.10,2.0.11)',\
org.apache.aries.subsystem.core;version='[2.0.10,2.0.11)',\
org.apache.aries.util;version='[1.1.1,1.1.2)',\
org.apache.felix.bundlerepository;version='[2.0.10,2.0.11)',\
org.apache.felix.configadmin;version='[1.9.18,1.9.19)',\
org.apache.felix.coordinator;version='[1.0.2,1.0.3)',\
org.apache.felix.log;version='[1.2.2,1.2.3)',\
org.apache.felix.logback;version='[1.0.2,1.0.3)',\
org.apache.felix.scr;version='[2.1.20,2.1.21)',\
org.eclipse.equinox.region;version='[1.2.101,1.2.102)',\
Thanks,
Chris
Thanks to Neil Bartlett, I now understand that each application subsystem would need to contain its own SCR bundle before Felix could find its components. Specifically:
SCR is not just a dependency, it scans bundles for the Service-Component header. The Declarative Services specification does not describe any way for SCR to discover bundles inside a subsystem of the running framework, therefore your bundles will be invisible to it.
David Jencks has also elaborated specifically about the Felix SCR:
IIRC you need to configure SCR with the ds.global.extender
flag set to true, then the single SCR will find components everywhere.
I get this error trying to use a github repository as a dependency using elm-install
Problem in dependency repo_name/package_name 1.0.0
The elm-package.json constraints of 'repo_name/package_name' are probably
letting too much stuff through.
What does this exactly mean?
(This answer courtesy of #ilias at Elm Slack channel)
It means that Elm couldn't compile the sources for that package in the context of your package.
Imagine for a minute I'm making a package my-fancy-package, and I have a dependency on a package foo/bar. So in my-fancy-package/elm-package.json, I could have a dependency like "foo/bar": "1.0.0 <= v < 2.0.0". Now, perhaps the most recent version of foo/bar while I'm developing my-fancy-package is 1.5.0. And in version 1.5.0, a new function was added that does exactly what I need in my-fancy-package, so I start using that function. The core issue is that there currently is no automated way to test that a package actually works with all the allowed versions of its dependencies. So now my-fancy-package says it depends on foo/bar at any version between 1.0.0 and 2.0.0, while in reality, it really needs to be at least 1.5.0 because I'm using a function from that package.
Now, imagine you're developing an application, and you're using foo/bar at version 1.2.3. According to the semver ranges of my-fancy-package, that means you should be able to use it, but if you were to actually try it, you'd receive this error: my-fancy-package is stating it is compatible with foo/bar#1.2.3 while it really needs 1.5.0.
The reason the error message doesn't simply say "it failed to compile" is because all the published packages are compiled before publishing. The most common reason for a package failing to compile in some context is that its dependencies aren't "accurate": they're letting too much stuff through.
In case of elm-install and packages from github, it's harder to say - it could actually be broken package.
Another common cause for this error is a rather silly one - conflicting definitions of infix operators. The associativity and precedence of infix ops can only be defined "globally", so if there are 2 packages that define the same infix operator, that could become a problem
I am working on a WebApplication which uses MVC5 and WebApi 2 with Owin. I recently updated Microsoft Asp.Net NuGet packages (Microsoft.AspNet.Mvc, etc.) from version 5.2.2 to 5.2.3, and the Owin NuGet packages (Microsoft.Owin, etc.) from 3.0.0 to 3.0.1. I also updated Microsoft.AspNet.Identity.Owin from version 2.1.0 to version 2.2.0
I then updated the corresponding Ninject WebApi packages (Ninject.Web.WebApi, etc.) from 3.2.3 to version 3.2.4 in order to get it to compile, but did not update Ninject.Web.Common.OwinHost, since this was at the latest version (3.2.3).
When I try to run the application, I get the following error:
Error loading Ninject component ICache
No such component has been registered in the kernel's component container.
Suggestions:
1) If you have created a custom subclass for KernelBase, ensure that you have properly implemented the AddComponents() method.
2) Ensure that you have not removed the component from the container via a call to RemoveAll().
3) Ensure you have not accidentally created more than one kernel.
The Kernel that I am creating in the OwinStartup class using is being disposed from the Owin.AppBuilderExtensions.CreateOwinContext() method, which is indirectly from OwinBootstrapper.Execute().
This has only started happening since updating the Asp.Net NuGet packages to 5.2.3. Before updating the packages, OwinBootstrapper.Execute() is still called, but does not cause Owin.AppBuilderExtensions.CreateOwinContext() or KernelBase.Dispose() to be called.
I have not changed any of the code in OwinStartup, and my Ninject Kernel is still being created using:
public virtual void Configuration(IAppBuilder app)
{
app.UseNinjectMiddleware(CreateKernel);
app.CreatePerOwinContext(CreateKernel);
}
I have tried updating the NuGet packages one at a time, and the specific update that causes the issue is Microsoft.AspNet.Identity.Owin to 2.2.0 Are there any known compatibility issues with Ninject and AspNet.Identity.Owin 2.2.0?
This from Hao: I think that should be fine, so long as ninject takes care of disposing the per request objects somehow
By looking at the previous source code and current source code, it looks like they are expecting a IDisposable object and calls it immediately at the end of its life cycle (aka request).
I also noticed that other CreatePerOwinContext they provide when installing OWIN such as app.CreatePerOwinContext(ApplicationDbContext.Create); was never disposed (in 2.1.0)? This seems like a big memory leak as they instantiate some classes every time there is a request.
To go around the problem when using CreatePerOwinContext with Ninject StandardKernel, I tried with the following code:
app.CreatePerOwinContext(
(Microsoft.AspNet.Identity.Owin.IdentityFactoryOptions<IKernel> options, IOwinContext context) => kernel,
(Microsoft.AspNet.Identity.Owin.IdentityFactoryOptions<IKernel> options, IKernel instance) => {}
);
Basically, I do nothing in the dispose callback.
I do not know if this will lead to some memory leak but it definitely makes the app work again.
Validation framework which has been rolled up as part of the JEE6 spec (WL12). Both the WL10 and WL12 versions of our application were deployed with the following open source libraries:
JSR-303 / validation-api.jar (version 1.0)
Hibernate Validator (version 4.2.0)
However, the libraries are also bundled with WL 12 (modules directory). Note that the Hibernate Validator version is slightly different.
modules.javax.validation_1.0.0.jar
hibernate.validator_4.1.0.jar
With our WL12 run we are getting below exception:
javax.validation.ValidationException: Unable to get available provider
Attempted Solutions
Our next attempt was to use the WebLogic FilteringClassLoader to prefer the libraries from our application (APP-INF/lib directory) by specifying them in the weblogic-application.xml file (i.e. choose our versions over WebLogic’s). We were already doing this for several other open source libraries in WL10:
<prefer-application-packages>
<package-name>com.google.common.*</package-name>
<package-name>org.apache.commons.lang.*</package-name>
<package-name>org.apache.commons.logging.*</package-name>
<package-name>org.apache.commons.beanutils.*</package-name>
<package-name>org.apache.commons.collections.*</package-name>
<package-name>antlr.*</package-name>
<package-name>javax.validation.*</package-name>
<package-name>org.hibernate.validator.*</package-name>
</prefer-application-packages>
After making that change, our application experienced the following run-time error trying to process any request that makes use of the validation framework:
javax.validation.ValidationException: Unable to get available provider resolvers.
at javax.validation.Validation$GenericBootstrapImpl.configure(Validation.java:259)
at web20.hibernate.validation.ValidatorFactoryConfigurator.getValidatorFactory(ValidatorFactoryConfigurator.java:39)
at web20.hibernate.validation.ValidationHandlerImpl.handleHibernateValidations(ValidationHandlerImpl.java:180)
at web20.hibernate.validation.ValidationHandlerImpl.performValidation(ValidationHandlerImpl.java:255)
at web20.hibernate.validation.ValidationHandlerImpl.validateAndFormatMessages(ValidationHandlerImpl.java:302)
at web20.hibernate.validation.ValidationHandlerImpl.validateUsingHibernateGroups(ValidationHandlerImpl.java:113)
at service.serviceapp.performValidations(serviceapp.java:392)
at service.serviceapp.performValidations(serviceapp.java:379)
at service.TransactionalServiceImpl.search(TransactionalServiceImpl.java:300)
Given that Bean Validation is part of the EE standard, I assume there is some code Bean Validation integration code which causes the problem. I see two potential solutions:
Patch the WL instance and upgrade to the Validator version you want to use
Try writing your own ValidationProvider. Internally it could just delegate to the Hibernate Validator classes. If you then add a validation.xml to your application, specifying your custom provider, WL should bootstrap this one. TBH, I don't know whether this will work. There are many unknowns and I don't know enough about the integration of WL and Bean Validation.
Personally, I think I would just try to upgrade the Validator version used in WL.