I am looping the components in a folder and searching a component whose one field of type DateTime lies in range current date to next 7 days on the basis of its published status.
But if any of the Components is checked out then IsPublished method throws an exception InvalidUriException. How can I handle this situation if I don't want to skip this checked out component by catching the exception and continue looping?
Edit:
The third line throws InvalidUriException for checked-out components.
componentUri = new TcmUri(node.Attributes[CommonConstants.Id].Value).GetVersionlessUri();
dummyComponent = engine.GetObject(componentUri) as Component;
bool isPublished = PublishEngine.IsPublished(dummyComponent , publicationTarget);
Invalid uri exception means the tcm id (item) doesn't exist. When a component is checked out, it may have a minor version number appended to the uri, e.g. tcm:xx-yy-yy-v1. So you need to grab that.
Try this: open the checked out component's version history and see what the latest version's ID is.
Looking at your code you pass in the component itself, shouldn't it be a TcmUri?
Even throws an exception when you hard-code the URI?
Invalid uri exception is thrown if the method does not support version uri or editable uri. Use the versionless uri then it should work fine i think. U can use TcmUri.GetVersionLess uri method.
Related
val args = Bundle()
args.putString("type", details.type)
navigator.navigate(context!!, findNavController(), Destination.TYPE, args)
I am quite confused as to why in the receiving fragment when I go to access the arguments I have passed through it is responding with...
val type: String = arguments.getString("type")
The arguments.getString is all underlined red and says "Required String Found String?" But how when I called method "putString"?!?
It is resulting in text not being rendered in the new fragment and I assume this is a nullability issue.
It's a matter of knowledge that is available in the receiving Fragment.
The Fragment is not aware of how its arguments were created (or modified) so it has to assume the "type" key you're looking for might not be in the arguments Bundle. That's why it returns a nullable (String?) result (the null value would mean absent in arguments).
Your fragment might be created in many places in your app and its arguments might have been modified in many places. We have no way of tracking that.
There are different solutions for this problem, depending on your approach in other parts of the code and how "confident" you are in creating of your Fragment.
I would usually choose a solution in which I assume setting the type is mandatory. Therefore if the type is absent - I fail fast. That would mean the Fragment was misused.
val type: String = arguments!!.getString("type")!!
The code above will crash if either:
a) arguments weren't set, or
b) String with type wasn't put in the arguments Bundle.
You are right, that is a : null ability issue.
First you should be sure if you are expecting a value, so try adding "?" or "!!", i would recommend "?", or go with the block of if {} else
To read the string safely you can use:
val type: String = arguments?.getString("type").orEmpty()
The orEmpty call at the end ensures that a valid String is returned even if either arguments or getString() returns null.
The method signature for getString() returns a nullable String. This is because at compile time, the compiler can't know if the value exists in the bundle or not. You will have the same issue when retrieving anything from any Map.
If you know for certain that the value in the bundle or map should exist at the time you call getString(), you can use the !! operator. That's what it's there for. When you know something should always be there, it is appropriate to want an exception to be thrown (in this case KNPE) if it's not there so you can easily find any programming error during testing.
isEmpty() or ?.let aren't helpful in this particular case because they would just be masking a programming error and making it harder to discover or debug.
Note:
The point of this question is not to just getting back a value that I ultimately want.
I can do that by simply not using Optional.
I would like an elegant solution so I could start returning Optional.
Explanation of what I tried to do:
I used the QueryGateway with a signature that will query my handler.
I broke out my code so you can see that on my CompletableFuture I will do a blocking get in order to retrieve the Optional that contains the object I really want.
Note that I am not looking for a class that holds my optional.
If this is not elegant then I may as well just do my null check.
The call to the query works, but I get the following error:
org.axonframework.axonserver.connector.query.AxonServerQueryDispatchException: CANCELLED: HTTP/2 error code: CANCEL
Received Rst Stream
AXONIQ-5002
58484#DESKTOP-CK6HLMM
Example of code that initiates the query:
UserProfileOptionByUserQuery q = new UserProfileOptionByUserQuery(userId);
CompletableFuture<Optional<UserProfile>> query =
queryGateway.query(q,ResponseTypes.optionalInstanceOf(UserProfile.class));
Optional<UserProfile> optional = query.get();
Error occurs on the query.get() invocation.
Example of my Query Handler:
#QueryHandler
Optional<UserProfile> handle(UserProfileOptionByUserQuery query, #MetaDataValue(USER_INFO) UserInfo userInfo) {
assertUserCanQuery(query, userInfo);
return userProfileRepository.findById(query.getUserId());
}
The query handler works fine.
Other efforts such as using OptionalResponseType would not initiate my query as desired.
I think the key lies with the exception you are receiving Stephen.
Just to verify for my own good, I've tested the following permutations when it comes to Optional query handling:
Query Handler returns Optional, Query Dispatcher uses OptionalResponeType
Query Handler returns MyType, Query Dispatcher uses OptionalResponeType
Query Handler returns Optional, Query Dispatcher uses InstanceResponeType
Added, I've tried out these permutations both with the SimpleQueryBus and Axon Server. Both buses on all three options worked completely fine for me.
This suggest to me that you should dive in to the AxonServerQueryDispatchException you are receiving.
Hence, I am going to give you a couple of follow up questions to further deduce what the problem is. I'd suggest to update you original question with the response(s) to them.
Do you have a more detailed stack trace per chance?
And, what versions of Axon Framework and Axon Server are you using?
Are you on the Standard Edition? Enterprise edition?
Does this behavior only happen for this exact Optional query handler you've shared with us?
I added a new method to the CustVendPaym class called sendersBankCompanyStatementName of type BankCompanyStatementName.
This is the code of said method:
public BankCompanyStatementName sendersBankCompanyStatementName(BankCompanyStatementName _sendersBankCompanyStatementName = sendersBankCompanyStatementName)
{
sendersBankCompanyStatementName = _sendersBankCompanyStatementName;
return sendersBankCompanyStatementName;
}
I added the definition in the classDeclaration method:
BankCompanyStatementName sendersBankCompanyStatementName;
Then in the method vendPaym in the VendOutPaym class, a new instance of VendPaym (which extends CustVendPaym) is created:
vendPaym = new VendPaym();
//A bunch of properties are set then one I created:
vendPaym.sendersBankCompanyStatementName (bankAccountTable.BankCompanyStatementName);
If I break there, I see the assignment with the value I'm expecting working correctly, but then the debugger (watch) never actually shows the new property I added with the value that's supposed to be in it.
Then if I just continue code execution, the AOS server in which I'm developing just crashes :|
Any ideas, am I doing something obviously wrong ?
Thanks.
EDIT: If I rollback my changes (that is deleting the newly added method and removing any references to it) everything works as it was before.
Have you compiled forward the CustVendPaym class?
Regularly during my application run, I get
TypeError: Error #1009: Cannot access a property or method of a null object reference.
at mx.managers::SystemManager/stageEventHandler()[C:\autobuild\3.4.0\frameworks\projects\framework\src\mx\managers\SystemManager.as:5649]
This is the full stack trace. Obviously, I guess there is something wrong, but I can't understand what.
Is there any way for me to find the origin of that bad behaviour ?
EDIT
Having added my SDK sources to my debugger, I can now say precisely which line it is :
private function stageEventHandler(event:Event):void
{
if (event.target is Stage)
mouseCatcher.dispatchEvent(event); // This is line 5649
}
mouseCatcher is indeed null. The current event target is indeed a Stage object, and event type contains the "deactivate" String. As event occurs at application startup (before I try to do any kind of user interaction), I guess it's a kind of initialization bug, but where ? and why ?
Look at the source code, this is always your best option. The 3.4 SDK is open source (datavisualization and the flash player itself aside) and you probably already have the source for it in your FlashBuilder/FlexBuilder install/sdks folder. Use grep or windows grep to find the file in question (or find, whatever floats your boat). Open the SystemManager file and check what's happening at that line, check for calls to the method (if it's public use grep again, if it's private you just need to look within the SystemManager). Try to understand why it gets to this point, as pointed out by some others it's likely a timing related issue where you're trying to access something before it has been assigned, in this case the SystemManager, you probably need to defer whatever action you're taking that is causing the error to a later part of the life-cycle (if you're using initialize event or pre-initialize try on creationComplete instead since that will be dispatched after the createChildren method is called).
Note: Mine is located here
C:\CleanFS\SDKs\flex\3.4.0.9271\frameworks\projects\framework\src\mx\managers
In my copy of SystemManager with the version of the SDK I have that line number doesn't make any sense since it's a block closure not an executable line so you'll have to look at your specific version.
It looks like you are using the Flex 3.4 SDK. Are you listening for the ADDED_TO_STAGE event when the application loads? Or doing anything with the Stage object on load? If so, you might be hitting a bug specific to the 3.4 SDK:
http://bugs.adobe.com/jira/browse/SDK-23332
The most obvious solution is to swap out the 3.4 SDK for a later version (3.4A, 3.5 or 3.6). You can do that here: http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+3
All of your code should be backwards compatable with the newer Flex 3 SDKs.
I've installed collective.quickupload on a blank Plone 4.1 site,
and noticed that when you add a quickupload portlet, kss calls for field validation (plone.app.form.kss), getSite function will return a FormlibValidation object, which cause the quickupload vocabularies crash.
The traceback is here: http://pastebin.com/nvwChpZd
My question is:
Is that (getSite function returns a FormlibValidation object) a bug or intended behaviour ?
Solution to fix/work around/make collective.quickupload work ?
getSite() returns the nearest component site (where local utilities can be stored), which really just means whatever was last set with setSite(), which usually happens on traversal.
Most of the time, the only traversal hook that calls setSite() is the one that's triggered when you traverse over the Plone site. But I think the old KSS inline form validation machinery used (uses?) a hack that creates a local component site on the fly (in a view) and sets that as the local site during the remainder of the request so that it can override certain things.
You can disable validation (e.g. disable the relevant KSS file in portal_kss) or fix c.quickupload to check whether the result of getSite() is an ISiteRoot. If it isn't, it should be acquisition-wrapped, so you can do aq_parent(site) (or maybe site.parent) to get the parent in a loop until you find an ISiteRoot.