I'm using the JAXB-2 Maven Plugin to generate classes from an XSD. One element has a maxOccurs of 50000 so the secure processing feature causes an exception for violating the 5000 limit.
Changing the XSD is not an option so as a workaround I added the "-nv" parameter to turn off strict validation. So I got my classes but it doesn't feel like a real solution.
Is there a way to set the MAX_OCCUR_NODE_LIMIT?
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
What are some common best practices one needs to consider while developing Apps in MuleSoft for clients, focusing Anypoint Studio 7.x.x and Mule 4.
List down your recommendations, which you have followed with any clients.
Please Note: I asked this general question to have a dedicated section of MuleSoft Development Best Practices on SO, rather than having similar titles where users having their personal agendas\user driven case scenario.
Mule Developers must considered this to be a critical topic.
Given below are the wide range of MuleSoft best practices which are involved during App development phase.
Development best practices are commonly divided into three categories:
Mule General Best Practices
Mule Munits Best Practices
Mule Error Handling and Exception Scenario Best Practices
Mule General Best Practices
Note: Suggestions are placed in <>. These are just best practices, not a compulsion.
Naming Conventions
Flow and SubFlow Names. <Must use camelCase>
XML files and properties files <Must be all lower case with '-' in between words>
Other common files (Examples, JSON files, Scripts) <Must use camelCase>
All the rest (Components, Transformers, Scopes, Flow Controls). <First letters of each word must be capitalized. Spaces must be used between words>
Property Parameterization
Configuration Properties. <All configurations must be declared as *key=value* in the property files>
Environment Based Properties. <Configuration properties must be segregated into files based on the *Environment* we deploy the app. Example "config-dev.properties", "config-qa.properties", "config-prod.properties">
Runtime Property Variables. <Should be used to fetch appropriate ".properties" files needed for the environment we deploy. Example, name your environment files as "/config-${env}.properties" using Configuration properties in global elements and pass 'env=dev' or 'env=qa' as a Runtime variables in Run Configurations. We can also pass global arguments like 'crypto.key=w4ref$%wrfw3', used to decrypt encrypted values>
Externalizing Transform Message Code to dw Script files. <A common rule of thumb is to use script files when the lines of code is greater than 10>
RAML and Project Files Folder Structuring
Place all the .properties files in src/main/resources/properties
Place all dw script files in src/main/resources/scripts.
Place the RAML examples, libraries, dataTypes, securitySchemes and Traits in dedicated folders while designing in Design Center.
Keep a separate file for API Kit Router and all its generated flow.
Error handling must have its own separate file. Error flows must not be seen anywhere else apart from this file.
Move all Connector Configurations/Global Elements into a separate 'global-config.xml' file. <This keep the rest of mule xml files clean and tidy>
Hard coded values
Must be aware of which code values you must 'Hard code' and which ones not.
Most Global elemental configurations must be property parameterized rather hardcoded. Example, 'Reconnection Strategy, 'Connection Idle Timeouts', 'Max Idle Timeouts', 'host', 'port', 'usernames', 'passwords' and more.
Property Value Encryption. Critical Information must be encrypted. <Using secure-properties-tools.jar or Mule property editor>
Autohide sensitive Property Values passed in Runtime Manager Tab of cloud hub. <Achieved using 'mule-artifact.json'>
Using functions, local/global variables in Transform messages to enforce DRY
Add detailed inline XML comments for flows, choice, etc.
Add descriptive multiline code comments for any complex transformations in Transform messages.
Replace long repeating 'if/else' statements 'with match/case' in data weave.
If flows are getting big using more choice routers. Refactor each choice scope into its own subflow.
A good rule of thumb is that if you have to scroll the Mule canvas back and forth to see the whole flow, it's too complex and should be rewritten.
Avoid Mule Async Scope Calls as much as you can. It caused data integrity issue, based on several developer complaints.
Do not use mule-objectstores for fast-long repeated operations. Know your TPS. Always clear your object stores in your mule cyclic execution in relevance to the requirement from time to time.
Keep a track of each 'variable' initialized in the flow executions. Always make sure to clear or remove variables once finished using them. <Helps you to have a clean process, removing unnecessary code manipulation and heap limitations>
Change your mule loggers from 'INFO' to 'DEBUG' after done development. <Helps you by not over-burdening the Mule APP when deployed in cloudhub. Keeps the mule health monitor in check, so that the APP does not auto restart>
Make sure to never cross an App's 70 percentage CPU usage shown in dashboards. Create Apps accordingly.
18. Be always aware of Data losses caused by Fatal Errors\Application Restarts. <Always use a backup data centers like AWS, Database, Object stores, Mule Load Balancers etc>
Mule Munits Best Practices
Never forget to use Spy and Asserts.
Scenarios based test cases.
Success Scenarios. <Have one major test case to run through the entire API once>
Failure Scenarios. <Have multiple test cases for each flow or subflows, testing for all possible failure situations, like testing mapping, choice routing etc>
Always mock all external service calls, like HTTP, DB, SQS Connectors. <Never call your actual endpoints in Munits>
Consider to put your test payloads in 'src/test/resources/testExample.json' but not directly in the Mocks or Events. <use #[MunitTools::getResourceAsString('testExample.json')]>
Include the files needed under 'src/test/resources' for Munit Test Runs, similar to having 'src/main/resources'.
Mule Error Handling and Exception Scenario Best Practices
All Error status codes must be included appropriately as per the requirement.
Errors must be separately specified in a 'global-error-handling.xml' file.
All Exceptions\Errors must be properly branched as given below
System Exceptions <Source related data exceptions>
Business Exceptions <Target\End System exceptions (Not to be bothered by the Mule APP, but must be handled)>
System\Application Errors
Admiring the usage of object stores and Data Queues for failed messages and record reprocessing.
Having a Retry mechanism for all HTTP based errors.
Can you imagine all the hours of pain we can avoid by following some simple recommendations.
Hope you this helps !
I'm trying to update a software system to JDK-11 using modules, and everything was going just fine right up until I slammed head-on into the aforementioned issue.
I have a legacy signed JAR that I need to incorporate for interaction with legacy systems. There's no way to update the JAR and no way to get a new version. The JAR must be signed in order to be usable (the whole "trusted code" deal and whatnot). The problem is that the JAR contains classes in the unnamed (root) package. Yeah. Stupid. Bad practice. Blablabla. It's still there, and I still need to use it.
I've not found any documentation or answers anywhere that would remotely suggest that what I need is possible. In fact, the opposite is true: everyone is adamant that in the "new"(ish) module system, no class may reside in the unnamed package.
Needless to say I'm unable to both modify the contents of the JAR, or get at the sources to render a new one - that's without even considering the issue of the signature...
That said: I refuse to believe the folks at Oracle would leave such a glaring oversight with regards to legacy code. As we all know, a lot of the time we have no choice but to use it for legitimate reasons, and we can't do anything to fix/update/refactor/etc... I would have hoped there was a mechanism added to the module system to support this, albeit for extreme cases only, etc...etc...
Disclaimer: I do fully understand why this isn't meant to be supported. What I'm having a hard time with is the lack of a workaround...
Thanks!
I've already tried:
creating a facade module that transitively adds the offending module (obviously no dice, same problem)
unpacking-and-repacking the module while temporarily disabling signature validation in a test env (fails because the class is apparently referenced within many other, properly-organized classes)
finding an updated module (no luck here, either)
beheading a chicken and roasting it over a pentagram while invoking the aid of ancient pagan gods (tasty, but didn't fix it)
curling up in a ball under my desk and weeping until execution succeeds (that's where I'm typing this from)...
I am attempting to use jsonix to unmarshal xml response from an SOS DescribeSensor request. In the broader scope I am going to be using jsonix to unmarshal all responses from SOS, particularly 2.0. I noticed that the response uses SML or SensorML namespace and so I added the extra module dependencies and sub-dependencies (namely GML_3_1_1, SWE_1_0_1, IC_2_0, SMIL_2_0, SMIL_2_0_Language, and of course SensorML_1_0_1). Before I added these I noticed the return was a generic json (see first screenshot, particularly near sml:physicalsystem). After I added the dependencies I got an error in my console during part of the unmarshaling process which I do not understand (see second screenshot). Here is a link to the xml response from the server for reference. https://drive.google.com/file/d/0B8LdnPVJpHz7M3VGb0FZc2lQcjQ/view?usp=sharing. I would really like to understand if this has anything to do with the ordering of the modules when I create the context though I believe it is fine. Once the solution to this is discovered I have two follow up questions.
Is it reasonable to expect (in general) that using the modules built from the ogc-schemas on the highsource github page should allow me to handle all responses via jsonix? i.e. every element will always be mapped to a defined type. I know these schemas/mappings are very complicated.
Are there any other tools I can use to verify the modules or validate them against schemas to make life easier rather than tracking down elements on an individual basis or tracing through various module files when jsonix seems to parse incorrectly?
Thanks in advance - Richard3d
var context = new Jsonix.Context([XLink_1_0, GML_3_2_1, IC_2_0, SMIL_2_0, SMIL_2_0_Language, GML_3_1_1, SWE_1_0_1, SensorML_1_0_1, OWS_1_1_0, SWE_2_0, SWES_2_0, WSN_T_1, WS_Addr_1_0_Core, OM_2_0, ISO19139_GMD_20070417, ISO19139_GCO_20070417, ISO19139_GSS_20070417, ISO19139_GTS_20070417, ISO19139_GSR_20070417, Filter_2_0, SOS_2_0]);
Disclaimer: I am the author of jsonix and main dev of ogc-schemas.
First of all, you're on the right track, stay on it.
Yes, if you have all the required mappings then you should get a "nice" JSON with all the properties with specific types, cardinatilities etc.
The goal of Jsonix is to provide bi-directional XML<->JSON conversion with deterministic structure, types and cardinalities.
The goal of OGC Schemas is to provide JAXB and Jsonix mappings for all of the OGC Schemas.
So togethere these two should allow to transform any OGC XMLs from/to JSON.
"Generic JSON" was actually just DOM. If a property allows DOM and Jsonix does not have mapping for certain element, it is just taken as DOM. You were just missing SensorML mappings.
You're right the structure of schema dependencies is very complex. But this is something we should take to OGC. :) It's a bit crazy that you need, like, a dozen of schemas to read sensor data. I was actually intending to build automatic loading of dependencies but did not yet implement this feature.
The next GML_3_1_1.AbstractFeatureType problem is probably this issue. Try changing the order of mappings (move GML_3_1_1 to the earlier places). Actually the order of mappings should not be significant, but, well, there's a bug.
Tools to cross-check - no, probably not. My approach is to do roundtrip tests (unmarshal-marshal-unmarshal-check equality). From experience, there are normally a couple of caveats at the start, but then it works by design. Of course there are bugs in Jsonix and there may be problems with mappings, but this gets sorted out.
Also feel to create a support project here:
https://github.com/highsource/jsonix-support
For instance https://github.com/highsource/jsonix-support/s/sos.
Here's an example of such a support project:
https://github.com/highsource/jsonix-support/tree/master/l/lightstalker89
I need this because just downloading XML from Google Drive (a) takes me effort to set up the support project (b) legally dangerous as I have not idea where this XML comes from and if I have rights/license to add these files to my test suites.
In our project we use parse on declarative syntax to instantiate our modules. We have a build process that builds our dojo, generic and functional layers for us. In one of our functions, the parser is complaining that some of the modules aren't defined (What's also odd is that the modules aren't being auto required either). I've confirmed that the layer is included in the page and that the module(s) are included in the layer. I can "require" the modules after the parse and they return the proper constructors. No errors are being reported (the attempt to retrieve the module is in a try/catch).
I feel like something silly is happening, but I can't find it. Any suggestions on how to troubleshoot would be helpful.
I've tried both parseOnLoad (our default) and calling parse seperately, even after a 10 second timeout.
Ugh, I knew it was something silly. We had lang="en" instead of lang="en-US".
Maybe it is a stupid question, but I cannot find out where can I config the minimal lines of code for duplication check in SONAR. In project settings there is only a switch to turn on cross project check. Any ideas?
B.R.
We have an open ticket on this: http://jira.codehaus.org/browse/SONARJAVA-91
As a background: Sonar has been using its own duplication detection mechanism since end of 2011 (from Sonar 2.11 IIRC). At that time, a decision was made that the number of lines or the number of tokens should not be configurable, in order to prevent the possibility to fool the engine. However, as the detection mechanism has not reached perfection yet ;-), we will allow to set "sonar.cpd.java.minimumLines" property in the mean time.
this feature is only available for languages other than Java ( http://docs.codehaus.org/display/SONAR/Analysis+Parameters#AnalysisParameters-Duplications )