I am trying to activate bean validation in TomEE, but on the application level, not on the container level.
According to the documentation, the correct property to set is org.apache.openejb.default.system.interceptors = org.apache.openejb.bval.BeanValidationAppendixInterceptor. Setting this in the system.properties, i.e. on container level, works fine. However, setting this in application.properties does not seem to enable the bean validation.
Is there a specific reason why this should not be allowed? Or is it even a bug in TomEE?
the configuration is only read at container level.
Note this is removed from coming TomEE 7 (class is there but implementation is a noop) cause bean validation 1.1 supports it in a standard manner.
Related
I found that Quarkus Server binds io.quarkus.grpc.runtime.supports.blocking.BlockingServerInterceptor for each gRPC service with the #Blocking annotation before it starts.
If some global interceptors (with #GlobalInterceptor) set the Context value will not work. The Context will still be empty in the actual rpc method handler.
Is it a normal phenomenon because Context should be placed after BlockingServerInterceptor's vert.x executeBlocking? There are some associated issues: https://github.com/quarkusio/quarkus/issues/14665, https://github.com/quarkusio/quarkus/issues/13959.
Finaly I replace the #GlobalInterceptor with #RegisterInterceptor(MyInterceptor.class) , everything is to be ok that seems to prove my point.
I don't particularly understand the technical details of it, and these are what I got from trying and Debug. I've been using Spring and Micronaut before.
When a local client gets a reference to a LocalBean, does the container provide a direct reference to bean instance? If not, what is provided?
Pointers to specs and authentic sources would be highly appreciated.
The spec does not prescribe that explicitly as I see, but injected references to EJBs are normally interface-based proxies. That's necessary for providing container services, like transaction management and timeout control, picking an instance from the pool in case of SLSB, calling user interceptors if any, etc.
While the spec only tells something rather neutral:
The container is responsible for making the business interfaces and/or
home interfaces of its deployed enterprise beans available to the
client through dependency injection and/or through lookup in the JNDI
namespace.
You can easily check that BTW, for example with debugger.
I have a Receive location with both Rcv as well as a Send pipeline.
Both the pipelines have a Custom Pipeline component that has some Design-Time properties.
In the Send pipeline, if I am setting those properties through BizTalk Admin Console, the properties are not being overridden. However, the same thing works completely fine with Rcv pipeline.
I cannot just set the properties at Design time as it is an Environment based value and need to be set at runtime.
After debugging the pipeline component, this is what I have found:
Following is the usual working of a Pipeline component (http://geekswithblogs.net/cyoung/archive/2011/09/14/biztalk-server-2010-loading-properties-in-custom-pipeline-components.aspx)
When a pipeline component is executed, the Load method of Pipeline components is called twice - first time it loads all the design time properties set on the Pipeline and when the Load method is called the second time, it is loading the Property Bag as set in the Pipeline configuration on BizTalk Admin Console.
Note: Only the properties that are changed will be passed in this property bag.
When we use a Request-Response Receive location, the above mentioned process is followed on the Receive Pipeline.However, when the same pipeline component is called from the Send pipeline,the Load method is only called once and hence none of the properties set from the BizTalk Admin Console are being set and the design-time properties do not get overwritten, thus causing the issue.
I have found a similar post witht he similar issue and no answer(https://social.msdn.microsoft.com/Forums/en-US/c69b3af1-b208-4213-884e-a98b8583761c/strange-ipersistpropertybag-load-pattern?forum=biztalkgeneral)
It looks like it is by design and I will be raising a ticket with Microsoft.
Please make sure you have restarted the host after you made the design time change. Also, you can put a break point also to see how it is behaving.
I have been supplied a WAR that contains a servlet. In the source of that servlet there are default initialization parameters ... for example:
#WebInitParam(
name = "proxyHttpsPort",
value = "9445",
description = "EPS Proxy HTTPS port"
),
My puzzle is how to over-ride these defaults in my local WebSphere Liberty environment. Does anyone know how to set the values of the initialization parameters such that when the servlet is loaded/started, my locally supplied values will be used rather than the default values baked into the application?
When we define a Servlet, we can do so through Java annotation. For example:
#WebServlet
We can also define initialization parameters:
#WebInitParam(name="name", value="value")
The notion behind an initialization parameter is to provide run-time configuration parameter that may be distinct by location where the solution is deployed. For example, on one system, an initialization parameter may have:
name="passwordFile", value="/etc/mypasswords.txt"
while on a different system, we may have:
name="passwordFile", value="/tmp/test_passwords.txt"
We don't want to hard-code these values in our applications but, instead, provide a default value that can be over-ridden at run-time.
When we build a Dynamic Web App for deployment on Java EE, we can define the servlet exclusively through annotations in code and this is the preferred style these days. However, before annotations, one defined the characteristics of a dynamic web project (including its servlets) through an XML file called web.xml. Within this file, one could supply a large set of configuration parameters including servlets and, for a servlet, the initialization parameters.
It appears that the web.xml technique is still available to us and can be used in conjunction with the Java annotations. What this means is that we can declare our Servlet and initialization parameters via annotations and at the same time, create a web.xml file. Where a value is found through annotation and there is no corresponding web.xml value, then the annotation will be used. However, if both an annotation and the same web.xml definition are present, then the web.xml definition will be the one actually used. Since the web.xml is an "exposed" configuration file, at deployment, we can edit web.xml to set the desired value for anything we wish to over-ride … including initialization parameters.
I want to make some kind of properties validation in my spring boot aplication. In my application.properties I have something like this:
log.path=
logging.config=${log.path}log4j2.properties
When I start my application I want to find all empty properties and throw Exception in which message there will be information about all missing properties.
Is spring giving that kind of mechanism?
You can create a bean and bind properties from application.properties to bean's fields by adding #ConfigurationProperties annotation. You can even use JSR-303 validators like #NotNull and #NotEmpty for automatic validation.
If you have too many properties and you don't want to create fields for each of these properties then, probably, you should open and parse application.properties file by your own. (But if application uses all these properties, then why not create a bean to validate them in the single place?)