When deploying a dynamic web project with JSF facet to Eclipse+GlassFish, the following error occurs:
The message says:
WELD-001437: Normal scoped bean class javax.faces.component.UIViewRoot is not proxyable because the type is final or it contains a final method public final void javax.faces.component.UIComponent.popComponentFromEL(javax.faces.context.FacesContext) - com.sun.faces.cdi.ViewProducer#1ccfebd3
How is this caused and how can I solve it? The same codebase and server works fine in Netbeans.
Because your NetBeans project has been worked successful. In this case, You should import exist NetBeans project to Eclipse IDE, don't create new Eclipse project. This make avoid errors or mistakes.
Turn off all other web application servers, avoid port number collision.
Related
I've created a Blazor Component within a full Blazor project and all works well.
However, when I move this component to it's own Razor Class Library project, I am now getting an error that I cannot use JSInterop until a connection with the server is made. I am running my code in the OnAfterRenderAsync() method.
I had to alter the code a little when I made the change.
In a full Blazor project, JSInterop is provided for you with DI in the Startup class. But this is not the case with a calss library.
So instead of "#inject JSInterop js" in the page, I had to set it up like this -
private IJSRuntime js { get; set; }
protected override void OnInitialized()
{
js = ScopedServices.GetRequiredService<IJSRuntime>();
}
From the sketchy details available on the web, I'm assuming this gets the service from the Parent project.
Using debugging, I can see that js is NOT null. It does seem to have been set to a valid object.
Can anyone point me in the right direction?
The server pre-renders, so your code will run before there is a client connection to the server. When rendering in OnAfterRenderAsync you should only use IJSRuntime when the firstRender parameter is true, or any point after that, but never before.
Found the solution to my problem and it has rendered my initial question irrelevant.
When I copied my component to it's own class library project, it would not compile. It gave me an error on the line #inject JSInterop js.
This led me to believe that it didn't know how to inject this as it is not set during the Startup of the project, as it is in a Blazor app.
So I cobbled together the code to get a reference via ScopedServices.GetRequiredService().
This did create an object but did not have _clientProxy set which contains the connection to the server.
So digging round I managed to find a complete component library example project at BlazorHelp Website
This did have the JSInterop injected in the Blazor file. So I reverted my code back to the original code that worked in the full project and tried to compile. It gave me the same error. So I deleted the #inject JSInterop js line and typed it in again.
IT RECOGNIZED IT!!!
It still failed to compile, not recognizing a custom type (Pivot) and asking whether I had included a reference to it.
[CascadingParameter] public Pivot OwnerPivot { get; set; }
I deleted the word Pivot and retyped it and, voila, it compiled.
So it looks like there some sort of error in VS2019 or the razor compiler, where deleting code in the source file and re-entering caused it to recognize and compile.
The following code from Hibernate Validator Reference Guide does not work in Java SE when RESTEasy is calling the validation:
public class ValidLicensePlateValidator implements ConstraintValidator<ValidLicensePlate, String> {
#Inject
private VehicleRegistry vehicleRegistry;
//rest of the class
The field vehicleRegistry is never injected.
Note that I have hibernate-validator-cdi.jar on the classpath.
Any idea what could be wrong with my setup? Or is this a bug in RESTEasy?
Here are (possibly misleading) outcomes of my investigation:
During application start RESTEasy shows the info log:
RESTEASY008550: Unable to find CDI supporting ValidatorFactory. Using default ValidatorFactory
From RESTEasy source code it seems that CDI enabled ValidationFactory is being looked up in AbstractValidatorContextResolver calling context.lookup("java:comp/ValidatorFactory") but it fails and non-CDI enabled ValidationFactory is used instead.
I'm currently writing a library where I want the user of my library to implement an interface. From within my library I'm calling this implementation.
I'm using ServiceLoader to instantiate the implementation provided by the integrator and it works just fine. The integrator calls a start() method in my library and in the end he gets something in return. The implementation is used to give me some things along the way that I need in order to get to the final result.
(I'm deliberately not using CDI or any other DI container 'cause I want to create a library that can be used anywhere. In a desktop application, a spring application an application using guice...)
Now I'm facing a problem. I'm creating a showcase in which I'm using my own library. It's a webapplication where I'm using jsf and CDI. When I instantiate the implementation provided in said webapp from within my library, I'm dealing with a non-container managed object. But since this implementation needs to use container managed objects I'm kinda screwed since this can never work.
Example:
Interface in lib:
public interface Example{
public abstract String getInfo();
}
Implementation in war:
public class ExampleImpl implements Example{
#Inject
private ManagedBean bean;
public String getInfo(){
return bean.getSomethingThatReturnsString();
}
}
As you can see this is a huge problem in the way my library is build since the bean will always be null... This means no one using a DI container can use my library. I know I can get the managedbean by doing a FacesContext lookup and get the managedbean but more importantly, my library isn't very well designed if you think about it.
So to conclude my question(s):
Is there any way I can make the serviceloader use a DI container to instantiate the class?
Anyone who knows a better way to fix my problem?
Anyone who knows a better way to get the things I need without making the integrator implement an interface but I can get information from the integrator?
I know this is a quite abstract question but I'm kinda stuck on this one.
Thanks in advance
As the implementation of Example is not performed within the CDI container the injection doesn't happen. What you can do is to lookup the bean manually using the BeanManager. According to the docs, the BeanManager is bound to the jndi name java:comp/BeanManager. Using the following code you can get the BeanManager within your implementation class and lookup the dependencies manually:
InitialContext context = new InitialContext();
BeanManager beanManager = (BeanManager) context.lookup("java:comp/BeanManager");
Set<Bean<?>> beans = beanManager.getBeans(YourBean.class, new AnnotationLiteral<Default>() {});
Bean<YourBean> provider = (Bean<YourBean>) beans.iterator().next();
CreationalContext<YourBean> cc = beanManager.createCreationalContext(provider);
YourBean yourBean = (YourBean) beanManager.getReference(provider, YourBean.class, cc);
where YourBean is the dependency you are looking for.
I have a web application with few spring portlets. Every portlet has an xml with its declared controller, but the services used by the controllers are placed in applicationContext.xml. I know that for every portlet is created one spring application context (from own xml file), and every that context has as root context the spring application context created from applicationContext.xml. That is all beans declared in applicationContext.xml are common for all portlets.
So let's have an example:
xml file for portlet example-portlet.xml:
...
...
controller ExampleController.java:
package example.controller;
#Controller
#RequestMapping(value = "VIEW")
public class NavigareController {
#Autowired
private ExampleService es;
...
}
applicationContext.xml:
...
<context:component-scan base-package="example.service />
...
service ExampleServiceImpl.java:
package example.service;
#Service
public class ExampleServiceImpl implements ExampleService {
...
}
When server starts with the application inside it, the application starts and everything works fine. When the application is redeployed then I have an error:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'exampleController'...
Caused by: org.springframework.beans.factory.BeanCreationException: Could not autowire field: private example.service.ExampleService...
Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No matching bean of type [example.service.ExampleService]...
In result the portlet is not starting.
I have debugged the lifery's sources and I have found the following code:
package org.springframework.web.portlet
...
public abstract class FrameworkPortlet extends GenericPortletBean
implements ApplicationListener<ContextRefreshedEvent> {
...
protected ApplicationContext initPortletApplicationContext() {
ApplicationContext parent = PortletApplicationContextUtils.getWebApplicationContext(getPortletContext());
ApplicationContext pac = createPortletApplicationContext(parent);
...
The code above, in first case (when server starts with application inside) returns not null parent, but in second case (when application is redeployed) it retuns a null parent. Inside PortletApplicationContextUtils.getWebApplicationContext(getPortletContext()) there is the following code:
Object attr = pc.getAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE);
So in first case this attribute is in portlet context, but in the second case it is not in portlet context. The problem is clear, the exampleService bean is not found in null parent.
The question is: Is there any bug in hot deployment process?. Please help me!!!
What is your version of Liferay? If it is 6.1.1 then this is a known issue
http://issues.liferay.com/browse/LPS-29103
If you just need to deploy the portlets once - change order of listeners in web.xml manually as suggested in the ticket.
If you need to redeploy the portlets alot (for development) then the previous solution is very time consuming and the easiest way is to backport the fix from 6.2.0 branch.
How do I configure my application so AutoMapper can map to internal types and/or properties in Silverlight 5? For example, I have the following type:
internal class SomeInfo
{
public String Value { get; set; }
}
I try to call Mapper.DynamicMap with this type as the destination and I receive the following error at runtime:
Attempt by security transparent method
'DynamicClass.SetValue(System.Object, System.Object)' to access
security critical type 'Acme.SomeInfo' failed.
I've tried instantiating the class first, then passing the instance to DynamicMap as well as changing the class scope to public with an internal setter for the property. I've also marked the class with the [SecuritySafeCritical] attribute. All of these tests resulted in the same error message.
The only way I've been able to get past this is to completely expose the class with public scope and public setters. This is, of course, a problem as I am developing a class library that will be used by other developers and using "internal" scope is a deliberate strategy to hide implementations details as well as make sure code is used only as intended (following the no public setters concept from DDD and CQRS).
That said, what can I do to make it so AutoMapper can work with internal types and/or properties?
(Note: The class library is built for SL5 and used in client apps configured to run out-of-browser with elevated trust.)
This is more of a Silverlight limitation - it does not allow reflection on private/protected/internal members from outside assemblies, see:
http://msdn.microsoft.com/en-us/library/stfy7tfc(VS.95).aspx
Simply put - AutoMapper can't access internal members of your assembly.