We have defined properties in several resource bundles, which are configured in the faces-config.xml
<resource-bundle>
<base-name>webMessages</base-name>
<var>feBundle</var>
</resource-bundle>
We then try to access a property which is not defined.
<tag infoText="#{feBundle['insurance.comparison.household.details.aicraftCrash.tooltip']}"
/>
If the property is not available a javax.el.PropertyNotFoundException is thrown and causes the faces servlet to render a blank page. From the documentation of the ResourceBundleELResolver this should not happen, as it does not throw this exception. I can see it is part of the resolvers of the DemuxCompositeELResolver.But it seems it is never called. Instead the MapELResolver (which is placed after the RBELResolver in the list of resolvers) is called and throws an exception. I can't really make something of that behaviour and debugging is tedious. There must be some way to get around this. A missing property can not break my whole page rendering process. Any ideas?
Note: This is an issue only with the javax.el library as provided with tomcat > 6 distributions
I investigated the issue a bit further and found that it is caused by the implementation of javax.el package in the tomcat distribution. So the described behaviuor only occurs when using tomcat > 6. I filed a bug report in their bug tracking tool already although one can argue that it is not a real bug but a sort of wanted (but, IMHO, ugly) behaviour. I also found a solution for jsf.
Subclass the
ResourceBundleELResolver and override its getValue(...) method. Change it such
that it sets the PropertyResolved attribute to true before any exception might
occur.
if (base instanceof ResourceBundle) {
if (property != null) {
try {
context.setPropertyResolved(true);
Object result = ((ResourceBundle) base).getObject(property
.toString());
return result;
} catch (MissingResourceException mre) {
System.out.println("Missing property: " + property);
return "?" + property.toString() + "?";
}
}
}
Register this custom resolver in the faces-config.xml with
<el-resolver>your.package.TheResolverImplementation</el-resolver>
And the link to the bug report https://issues.apache.org/bugzilla/show_bug.cgi?id=53001
Related
I'm working with a large, multi-module Android application, and I'm trying to define a Gradle task that collects the jars of all runtime dependencies. I'm trying something like this in app/build.gradle:
task collectDeps {
doLast {
configurations.releaseRuntimeClasspath.resolvedConfiguration.resolvedArtifacts.each {
// do stuff
}
}
}
I've used this snippet in the past on other Java projects, so I know that it conceptually works; this is just my first time trying it on a project with multiple build types and/or variants.
When run on the Android project, executing this task throws a variant resolution error:
Execution failed for task ':app:collectDeps'.
> Could not resolve all dependencies for configuration ':app:releaseRuntimeClasspath'.
> The consumer was configured to find a runtime of a component, preferably optimized for Android, as well as attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'release', attribute 'com.android.build.api.attributes.AgpVersionAttr' with value '7.1.1', attribute 'org.jetbrains.kotlin.platform.type' with value 'androidJvm'. However we cannot choose between the following variants of project :myModule:
- Configuration ':myModule:releaseRuntimeElements' variant android-aar-metadata declares a runtime of a component, preferably optimized for Android, as well as attribute 'com.android.build.api.attributes.AgpVersionAttr' with value '7.1.1', attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'release', attribute 'org.jetbrains.kotlin.platform.type' with value 'androidJvm':
- Unmatched attributes:
- Provides attribute 'artifactType' with value 'android-aar-metadata' but the consumer didn't ask for it
- Provides attribute 'com.android.build.gradle.internal.attributes.VariantAttr' with value 'release' but the consumer didn't ask for it
- Provides a library but the consumer didn't ask for it
- Configuration ':myModule:releaseRuntimeElements' variant android-art-profile declares a runtime of a component, preferably optimized for Android, as well as attribute 'com.android.build.api.attributes.AgpVersionAttr' with value '7.1.1', attribute 'com.android.build.api.attributes.BuildTypeAttr' with value 'release', attribute 'org.jetbrains.kotlin.platform.type' with value 'androidJvm':
- Unmatched attributes:
- Provides attribute 'artifactType' with value 'android-art-profile' but the consumer didn't ask for it
- Provides attribute 'com.android.build.gradle.internal.attributes.VariantAttr' with value 'release' but the consumer didn't ask for it
- Provides a library but the consumer didn't ask for it
I've trimmed the error for brevity; there are ~20 variants in total. Note that myModule is a project dependency of the top-level app; if I remove that dependency, the error is the same but comes from a different module.
I should also note here that every other build target works fine; the application is quite mature, and the only change I've made is to add this new task to app/build.gradle. So I assume there's something about the way I'm resolving the dependencies that Gradle doesn't like, but I'm struggling to figure out what, or how to resolve it.
Googling this error is not very helpful; the Gradle documentation is quite vague about exactly how to resolve variants, and the solutions that are provided seem to focus on changing how dependencies are added to the project; but I don't necessarily want to do that, because the build works fine for every other use case.
Ideally, I'd like to be able to force a variant for the resolution specifically within my collectDeps task (in fact, ideally collectDeps would be defined in a plugin). Is this possible to do?
In case it matters, the build is using Gradle 7.2 and v7.1.1 of the Android Gradle Plugin
There may be a better way to handle this, but I ultimately managed to resolve my problem by taking inspiration from Sonatype's open source Nexus scanning plugin. The code looks like (this is in Kotlin, but can be modified to Groovy without much difficulty):
project.allprojects.forEach { project ->
val cfg = project.configurations.releaseRuntimeClasspath
try {
cfg.resolvedConfiguration.resolvedArtifacts.forEach {
// do stuff
}
} catch(e: Exception) {
when(e) {
is ResolveException, is AmbiguousVariantSelectionException -> {
val copyConfiguration = createCopyConfiguration(project)
cfg.allDependencies.forEach {
if(it is ProjectDependency) {
project.evaluationDependsOn(it.dependencyProject.path)
} else {
copyConfiguration.dependencies.add(it)
}
}
copyConfiguration.resolvedConfiguration.resolvedArtifacts.forEach {
// do stuff
}
}
else -> throw(e)
}
}
}
private fun createCopyConfiguration(project: Project): Configuration {
var configurationName = "myCopyConfiguration"
var i = 0
while(project.configurations.findByName(configurationName) != null) {
configurationName += i
i++
}
val copyConfiguration = project.configurations.create(configurationName)
copyConfiguration.attributes {
val factory = project.objects
this.attribute(Usage.USAGE_ATTRIBUTE, factory.named(Usage::class.java, Usage.JAVA_RUNTIME))
}
return copyConfiguration
}
The basic idea is that, if a configuration can't be resolved because of ambiguous variant selection, I create and inject a new parent configuration that specifies the attribute org.gradle.usage='java-runtime'; this is sufficient to disambiguate the variants.
Note that I didn't test this with any other attributes, so it's possible that it could work by setting, for example, the artifactType attribute instead; but my use case is more specifically related to the runtime classpath, so this worked for me
That's not really an issue, beacause I found a workaround, but it conflicts with the documentation, so I wanted to share and document about it.
FYI Spring Boot 2.1.10 + SCSt 2.1.4 + RabbitMQ binder
I first implemented an application local error handler as given into official docs :
#StreamListener(Sink.INPUT)
public void handle(Person value) {
throw new RuntimeException("BOOM!");
}
#ServiceActivator(inputChannel = Sink.INPUT + ".my-group.errors") // won't work
public void error(ErrorMessage message) {
log.error("Handling ERROR: " + message.getPayload().getMessage());
}
spring.cloud.stream.bindings.input.destination=persons.inputs
spring.cloud.stream.bindings.input.group=my-group
But that didn't go well, to say the least. This is what I eventually had to keep:
#ServiceActivator(inputChannel = "persons.inputs.my-group.errors")
As you can see, what's happening is that I had to stick to the actual destination definition instead of the channel's; which I think is very uncomfortable! And I want to underline, again, that this is contradictory to the official docs here: https://docs.spring.io/spring-cloud-stream/docs/current/reference/htmlsingle/#_application_error_handling (plus there are noticeable typos, IMHO: they even write that the destinationName is actually required)
Can anyone share thoughts about the situation with me? Have I done it right and am I right to think that this is wrong?
It's a bug in the documentation; it is, indeed, unfortunate the binding name was not used in the error channel name instead of the destination and group, but it's too late to change it now. We could possibly do something in a future release.
Please open 2 GitHub issues to
fix the documentation
consider adding an option to name the error channel using the binding name instead.
I am porting some code to ASP.NET 5, and want to target DNX Core 5.0. However, I am having trouble locating the types that are required to validate an XML document against an XSD document.
Here is the code:
var xsdStream = this.GetType().GetTypeInfo().Assembly.GetManifestResourceStream(xsdPath);
using (XmlReader xsd = XmlReader.Create(xsdStream))
{
XmlSchemaSet schema = new XmlSchemaSet();
schema.Add(null, xsd);
XmlReaderSettings xmlReaderSettings = new XmlReaderSettings();
xmlReaderSettings.ValidationType = ValidationType.Schema;
xmlReaderSettings.Schemas.Add(schema);
using (XmlReader xmlReader = XmlReader.Create(xmlPath, xmlReaderSettings))
{
try
{
while (xmlReader.Read());
}
catch (Exception ex)
{
throw new Exception(string.Format(Resources.Messages.XmlValidationFailed, xmlPath), ex);
}
}
}
As you can see, all I want is to stop on the first error and throw an exception indicating what the error is.
The problems are:
The XmlSchemaSet class doesn't exist in the System.Xml.Schema namespace (or anywhere else I have found).
The XmlReaderSettings.ValidationType and XmlReaderSettings.Schemas properties do not exist.
I checked the MSDN Documentation which has a slightly different approach. However, as before XmlSchemaSet doesn't exist, and neither does XDocument.Validate(). I have also searched several of the ASP.NET projects for an example but can't seem to find any.
What facilities (if any) exist in DNX Core 5.0 to validate XML against an XSD? I would prefer to do this using streams if possible, but if absolutely necessary I will accept an approach that reads the entire documents into memory at once.
There is no support for XSD in the first release. When I heard right in one of the tweets, posts, bugs or community standups they do, it is considered for a later release.
ps: Pawel should answer this and get the credits ... but we should close this question.
I'm using Spring MVC portlets I need to implement one display tag with external pagination. In order to do this, I've defined my table in the JSP like this:
<portlet:actionURL var="viewListURL">
<portlet:param name='action' value='${ServletContextKeys.MY_ACTION_METHOD}'/>
</portlet:actionURL>
<display:table name="${whateverList}"
requestURI="${viewListURL}"
class="displayTagTable"
export="true"
uid="item"
pagesize="10"
partialList="true"
sort="external"
defaultsort="1"
size="${ServletContextKeys.SC_LIST_SIZE}">
...
The problem is that, when I click any button to paginate, the displaytag redirects me to the render phase instead the action phase as I want to. What am I doing wrong? Any ideas..?
Thanks a lot
EDIT: I can see in the URL that the parameter p_p_url_type=0 (render phase). it makes no sense to me, as I'm calling an action url, but maybe would be enough just change this parameter to p_p_url_type=1. But, I'm just don't know how... Any ideas?
http://localhost:8080/wsdes/user/sifo3/home?p_p_id=SifoIIIweb_WAR_sifo3economicoweb_INSTANCE_s8jH&p_p_lifecycle=1&p_p_url_type=0&p_p_state=maximized&p_p_mode=view&_SifoIIIweb_WAR_sifo3economicoweb_INSTANCE_s8jH_action=consultaJustificantes&_SifoIIIweb_WAR_sifo3economicoweb_INSTANCE_s8jH_implicitModel=true&_SifoIIIweb_WAR_sifo3economicoweb_INSTANCE_s8jH_d-49489-p=2
Been there before. I solved the problem in a different way, but while looking in DisplayTag source code I found some interesting things. For example, in PortletHref you can find this in the addParameter method:
if (PARAM_TYPE.equals(name))
{
if (TYPE_RENDER.equals(value))
{
this.setAction(false);
}
else if (TYPE_ACTION.equals(value))
{
this.setAction(true);
}
And also:
private static final String PARAM_PREFIX = "portlet:";
public static final String PARAM_TYPE = PARAM_PREFIX + "type";
public static final String TYPE_ACTION = "action";
Apparently, if you need a parameter named portlet:type with value action to make DisplayTag generate an Action URL. I haven't tested myself, so let me know if it works.
I still don't know the reason, but I fixed this issue changing the display tag for Portlets (displaytag-portlet.jar), to the standard displaytag, and deleting from the displaytag.properties file the factory.requestHelper property:
factory.requestHelper=org.displaytag.portlet.PortletRequestHelperFactory
Using the normal displaytag library, instead of the portlet one, fixed my problems.
I'm looking to integrate the Barcode2 class in the EDMK 2.6 library into our existing Barcode scanning interface.
I've wired the example code up to our interface method StartScan() and always get E_SCN_READTIMEOUT as the result even though the code seems to be responding to the scan. (the breakpoint at if (scan.Result == Results.SUCCESS) is hit in response to the scan
public void StartScan()
{
if (!barcode.IsScanPending)
{
ScanData scan = barcode.ScanWait(2000); // 2 second timeout
if (scan.Result == Results.SUCCESS)
{
if (scan.IsText)
{
textbox1.Text = scan.Text;
}
}
}
}
The result is always E_SCN_READTIMEOUT, I suspect this may be a conflict with DataWedge 3.4 running on the device, but the functionality of the scanner and triggers seem to be dependent on it.
Getting barcode scans to the clipboard using DataWedge is not an option for us, is there a way to get the library to function despite DataWedge(assuming that is causing the read timeouts)?
The DataWedge application did need to be disabled, (this can be done programmatically via the datawedge API from Motorola, Thanks Abdel for the hint here!).
https://docs.symbol.com/ReleaseNotes/Release%20Notes%20-%20DataWedge_3.3.htm
A little background on our Windows Mobile application for reference, we have a hardware singleton that contains interfaces for all hardware components and loads related types and assemblies via reflection. If we referenced types directly the code above worked.
The end solution ended up being to use the Symbol.Barcode library instead of Symbol.Barcode2.