I am developing a project with silex-skeleton in its most recent version. When trying to use the share method shows me the following error:
Code:
$app['login'] = $app->share(function() use($app) {
return new Model\UserModel($app);
});
Error:
Attempted to call method "share" on class "Silex\Application"
Any suggestions or possible cause of this failure
Silex 2.0 is using Pimple 3.0 which has removed the shared method, now all services are shared by default, if you want a new instance you must call the factory method as stated in the changelog for version 2.0.
So if you want a login service you should create it like this:
<?php
$app['login'] = function($app) {
return new Model\UserModel($app);
};
You can take a look at the docs for the 3.0 Pimple version directly on it's GitHub repository
PS: Keep in mind that, at the time of this writing, Silex 2.0 is in development, so be prepared to adapt your code until it gets a 2.0 stable version. 2.0 has reached prod status as of 2016-05-18
Related
Can I use lazy services in typo3 (version 11)?
I have installed the package symfony/proxy-manager-bridge with composer require symfony/proxy-manager-bridge. The documentation says that is enough.
When I debug the problem I find out that ContainerBuilder::proxyInstantiator is null and ContainerBuilder::setProxyInstantiator() is never called. I think it is the same problem as here.
Is there a way to call ContainerBuilder::setProxyInstantiator() in typo3?
UPDATE
I was able to call ContainerBuilder::setProxyInstantiator() in the typo3 context with a Service.php file. But it did not help with the lazy services.
// myext/Configuration/Services.php
// ...
return static function (ContainerConfigurator $container, ContainerBuilder $containerBuilder) {
$containerBuilder->setProxyInstantiator(new MyRuntimeInstantiator());
};
TYPO3 does not support this integration for lazy services out of the box like Symfony does. Especially you cannot use Symfony bundles since these are integrations specifically meant for Symfony apps similar to extensions in TYPO3.
Within Symfony the Kernel::getContainerBuilder() method is responsible for injecting the proxy instantiator. Here you can see how the Symfony-specific bundle is integrated in case it exists / is installed.
So you may need to try if you can achieve something similar with a Configuration/Services.php which receives the ContainerBuilder instance as argument. See the Services.php of EXT:core for an example.
If it works well, you can even consider publishing this as TYPO3 extension package so that others can get this up and running with a simple package installation just like in Symfony.
I am attempting to upgrade from Wicket 9.0.0 to Wicket 9.3.0. When I change the version in a quick-start application, everything is fine.
The problem occurs in my real application, where we were originally using Jakarta Enterprise Beans 8.0.0. At runtime, when a database access was attempted, we got an exception with the following message:
Last cause: net.sf.cglib.proxy.MethodInterceptor not found by org.objectweb.asm [23]
Trying to use Jakarta EE 9.1 instead
I changed my pom.xml as follows:
<jakartaee>9.1.0</jakartaee>
<wicket.version>9.3.0</wicket.version>
I downloaded the jar for Jakarta EE 9.1, changed "javax" to "jakarta" throughout my application, rebuilt it and tried to run again.
The result was still not perfect, but significantly better than before: a plain old null pointer exception instead of any weird errors about cglib.
Here's the section of code that now causes the trouble:
#EJB(name = "AdminNotesFacade")
private AdminNotesFacade adminNotesFacade;
public AdminNotesFacade getAdminNotesFacade() {
return adminNotesFacade; //ACTUALLY RETURNS NULL
}
So now the big question is: what do I need to do/change to make the #EJB work instead of returning null?
Checking the Payara log, I get this error:
java.lang.RuntimeException: Unable to load the EJB module. DeploymentContext does not contain any EJB. Check the archive to ensure correct packaging for D:\Dev\icase2\target\icase2.
If you use EJB component annotations to define the EJB, and an ejb or web deployment descriptor is also used, please make sure that the deployment descriptor references a Java EE 5 or higher version schema, and that the metadata-complete attribute is not set to true, so the component annotations can be processed as expected
at org.glassfish.ejb.startup.EjbDeployer.prepare(EjbDeployer.java:189)
Adding further details, 2022-05-06
I wonder if we were going off on the wrong track when we thought that we could fix this by upgrading our jakartaee version. From Wicket 9.0 to 9.3 is only a change of minor version and you wouldn't expect to have to make such fundamental changes to get a minor upgrade working.
I've tried using Wicket 9.9.1 instead, in case this problem has been fixed in more recent versions, but it's exactly the same.
Anyway, I have created a very small "quick-start" application, based on Wicket's own templates, to reproduce the problem. I have stuck with the original "javax" version, and added just one EJB - a JavaMail bean. I think it's probably interesting to know that it's not a specifically database-related issue. We just can't seem to load any EJBs at all.
In the Wicket 9.0.0 version, a simple form is displayed on the home page, allowing the user to enter their email address. When they submit the form, a test message is sent to that address. It works fine.
Then if I change the Wicket version to 9.3.0 but make no other changes at all, it doesn't even get to the stage of displaying the home page, it immediately crashes with the message "Last cause: net.sf.cglib.proxy.MethodInterceptor not found by org.objectweb.asm [23]"
For what it's worth, here's the code that triggers the error.
public class HomePage extends WebPage {
#EJB(name = "EmailerFacade")
private EmailerFacade emailerFacade;
private static final long serialVersionUID = 1L;
private String sendTo = "";
public HomePage(final PageParameters parameters) {
super(parameters);
add(new Label("version", getApplication()
.getFrameworkSettings().getVersion()));
FeedbackPanel feedback = new FeedbackPanel("feedback");
add(feedback);
final Form emailForm = new Form("emailForm") {
#Override
protected void onSubmit() {
emailerFacade.sendMessage(sendTo, "Test message from quick-start",
"Version is " + getApplication().getFrameworkSettings()
.getVersion());
info("Tried to send message to " + sendTo);
}
};
add(emailForm);
final TextField<String> emailAddress = new TextField<>("emailAddress",
new PropertyModel<>(this, "sendTo"));
emailAddress.setLabel(Model.of("Email address"));
emailAddress.setRequired(true);
emailForm.add(emailAddress);
}
}
Wicket 9.x is based on javax.servlet APIs. To deploy it on jakarta.servlet supporting web container you will need to migrate the bytecode with a tool like https://github.com/apache/tomcat-jakartaee-migration.
I am not sure whether Payara does something smart at runtime to support both javax.** and jakarta.** classes.
Tomcat 10.x supports migration of the classes at application start time by deploying your app in the special $CATALINA_HOME/webapps-javaee folder.
This answer was actually provided by Sven Meier. He commented:
Use the new system property to switch to ByteBuddy in Wicket 9.x:
-Dwicket.ioc.useByteBuddy=true
To expand a bit on this, I found I needed to do three things:
Set the system property "wicket.ioc.useByteBuddy" to true as specified by Sven
Add a dependency on byte buddy
Upgrade to a higher version than I was initially attempting to do: 9.3.0 was not good enough. I see in a comment above by Sven, he says that the migration to byte buddy was actually done in 9.5. So in fact I upgraded to the latest version, which is currently 9.9.1.
Here is the dependency on byte buddy that I added:
<dependency>
<groupId>net.bytebuddy</groupId>
<artifactId>byte-buddy</artifactId>
<version>1.12.10</version>
</dependency>
I am currently working on to upgrade dotnet core framework version from 1.0 to 2.1 of an existing product.
The UI of the same is made in Angular which makes service calls to AWS Lambdas (made using dotnet core) for all the requirements. User data is stored in AWS Cognito and every time a service call is made it first gets verified by fetching data from Cognito. This part stopped working after the framework upgrade.
The following lines of code stopped fetching data:
if (!HttpContext.Items.Keys.Contains("APIGatewayRequest"))
{
//Log error
}
HttpContext.Items["APIGatewayRequest"] as APIGatewayProxyRequest;
Custom api gateway authorizer is used for Cognito and also HttpContext is used inside a controller.
The following image shows the Request.HttpContext structure for me:
Any information around this issue will be great.
Finally, after trying desperately for a couple of days, I got the resolution. In the newer version of DotNet Core the value of the HttpContext key got changed from "APIGatewayRequest" to "LambdaRequestObject" causing all the pain. And the code was using the value directly from a constant declared inside the project and was not using the constant "AbstractAspNetCoreFunction.LAMBDA_REQUEST_OBJECT" provided by the framework.
I have an existing application. I am trying to port some pieces over from .NET 4.x over to .NET Core. I have created a context in my .NET Core app. I have create a db context via scaffold-dbcontext. I can run a basic query (hooray). Life is good. Now, I want to add in some async queries. I get the following error:
System.InvalidOperationException: 'The provider for the source IQueryable doesn't implement IDbAsyncQueryProvider. Only providers that implement IDbAsyncQueryProvider can be used for Entity Framework asynchronous operations. For more details see http://go.microsoft.com/fwlink/?LinkId=287068.'
code:
var ctx = new GolfGameContext();
var userId = await (from u in ctx.AspNetUsers where u.Token == UserToken select u.Id).SingleAsync();
return userId;
This error seems strange. I have created some .NET Core 2.x apps from scratch and everything seems to work properly. I am able to do async queries with them just fine. When I look at the error link, I get taken to information about EF 6.x. I am guessing that there is something that the scaffold-dbcontext puts in the resulting models that cause this problem. I am also guessing that the code I have created in Core 2.x doesn't contain these same limitations. Am I on the right track? Do I need to change something in my context/models to get async to work properly? All thoughts are welcome.
TIA,
Wally
I have a previous project running Ninject 2.0 runtime version 2.0 and now I am using Ninject in a new project and using the new Ninject, ninject web.mvc version 2.2 for runtime version 4.0.
Every single time I get the error no parameterless constructor
Invalid Operation exception
An error occurred when trying to create a controller of type HomeController'. Make sure that the controller has a parameterless public constructor.
What am I missing. All the bindings are registered.
Do I need to now define interfaces for Controllers as well such as HomeController as IHomeController as I have seen in some examples, Or do I get back to using the older version
There is one version that does not show activation exceptions properly but show this exception instead. Most likely the problem is a duplicated binding.
In addition to what Remo Gloor said, you might want to check that MVC is set up to use Ninject correctly. I was doing some things manually on an older version of the MVC plugin and ended up needing to just bite the bullet and make Global extend the NinjectHttpApplication class, which I had previously been avoiding.
The error you're getting is the error you would get if MVC tries using its built-in controller factory to produce controllers. So you may want to create a custom method binding on your controller class and put a breakpoint inside to make sure it's even being invoked.
You may also want to switch to version 2.3. You can pick up the latest builds of Ninject and all its extensions here.
I have seen this issue mentioned couple of times on forums where there is no direct answer, here is the solution to the above problem, i.e., working with latest ninject
Download the latest Ninject from github.
The ninject I got for MVC2 is named as Ninject.Web.Mvc2-2.2.0.0-release-net-4.0 (runtime version 4)
Now during adding reference add Ninject.Web.Mvc.dll(check the version is same as above by right click properties in VS)
Now Add Ninject.dll from the lib folder in same parent folder (check the version as above)
Now Add CommonServiceLocator.NinjectAdapter.dll from the extensions folder in lib parent folder (check the version as above.)
The missing link in all these have been the commonserviceLocator.dll and the correct version should match. This should be tried if you are sure your bindings are correct as mine were and check to see if your project work with older version.
Thanks to everyone, and good luck :)