we are busy upgrading from v2 to v4.3 and have run into some issues with Transalations and switching to Facades. We have followed the upgrade docs 2-3 then 3-4.
The first issue we are facing is that we need to include all the individual translations files (order, checkout, etc) whereas before we just needed the single translations and translationsChunks config as per (https://sap.github.io/spartacus-docs/i18n/#getting-started), and having our custom overrides in the translationOverwrites and provided it in the config was sufficient. This does not work anymore, are we perhaps missing a step and is providing each individual translation file the correct approach?
The second issue is changing our existing calls from Service to its Facade counterpart/replacement as per the upgrade docs, the facade methods are abstract and the implementation (the Service) is not executed. Changing back to the Service class executed the correct code. Again, are we missing an upgrade step or should we ignore the upgrade doc and continue using the Service?
Related
I have created a WCF service using Workflow. It works just fine. I created another Workflow application to consume it. I added the service reference to the application project and rebuilt the project. I added the component from the service to the app, but it's expecting an argument that I never specified.
I've tried rebuilding both the service and the app, generating an entirely new solution and starting from scratch - same problem. I've looked at others' code and they've structured this project the same as mine but this issue does not show up on theirs. Googling this problem seems to bring up not results.
My workflow service is defined as such: https://i.imgur.com/E8mEfs6.png
The parameters of the receive component are: https://i.imgur.com/TaNRw2y.png
But when I add it to my app, the parameters are defined as: https://i.imgur.com/tqgEwNr.png
Which is not what I had defined in my service. I can't even figure out what it wants me to pass in for _GetCityStateFromZip. It says the type is InArgument.
I was expecting it to be expecting the zipcode parameter as I specified in the service. I think I might be adding the service reference incorrectly, but I don't know how. I went to Add Service Reference in Visual Studio, then copy/pasted the path to the .xamlx file of the service on localhost.
Thank you.
I found a solution to this problem here:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/5279fc5f-8a53-43e7-8ef2-3073808dc90f/configuring-workflow-services-how-to-configure-workflow-control-endpoint?forum=wfprerelease
I re-made my service using the steps listed and it works as originally intended.
I am attempting to host a Saga from one project in another project using NServiceBus 6 with SqlPersistence and SqlDialect.MsSqlServer. In most examples I have found, the Saga is contained in the same assembly as the hosting app, and perhaps this is why I am struggling.
When hosting everything in the same app, the NServiceBus.Persistence.Sql.MsBuild package correctly outputs Saga .sql files during the build and then picks these up and executes them on run. Using a separate app, only the Outbox, Subscription and Timeout .sql files are generated, not the Saga ones. The following entry is then logged on run:
INFO NServiceBus.Persistence.Sql.Installer Directory '[PATH]\SagaPersistence\Service\bin\Debug\NServiceBus.Persistence.Sql\MsSqlServer\Sagas' not found so no saga creation scripts will be executed.
A full VS 2017 repro may be found at https://github.com/WolfyUK/NServiceBusSagaSqlPersistence.
Firstly, is it a bad idea to host a Sagas from another service, rather than being self-hosted? If not, can someone advise the best way to resolve the SQL Persistence issue?
Can you add NServiceBus.Persistence.Sql.MsBuild to the Saga project? The scripts should then be found there. Unfortunately they're not copied to the host its folder, so you'll have to take them from there into production. Or have them generated by using EnableInstallers, like you're already doing.
I am using Apache Jackrabbit Webdav library for svn checkin operation.
I am using MAKActivity method to start the transaction.
But I dont know how to add commit message. Following is the code
RandomStringGenerator rsg = new RandomStringGenerator(32);
String random = rsg.nextString();
String url = getRepoAddress() + "!svn/act/" + random;
MkActivityMethod activityMethod = null;
try
{
activityMethod = new MkActivityMethod(url);
client.executeMethod(activityMethod);
}
catch(Exception e)
{
e.printStackTrace();
}
This code executes successfully but I dont unserstand how to write log message in this.
Any help will be appreciable.
First of all I'd suggest that you not reinvent the wheel that's already been done twice now and instead using a library that knows Subversion's DAV based protocol. Note that while Subversion is mostly WebDAV and DeltaV compatible, it does have non-standard extensions.
To that end I'd point you to JavaHL or SVNKit. JavaHL comes with Subversion and uses JNI to access the Subversion libraries. SVNKit is an independent Java only implementation and includes a couple different interfaces, including one that is JavaHL compatible. If the use of the native libraries by JavaHL doesn't present a problem for you I'd recommend this since you'll have the benefit of using the same libraries as nearly every Subversion client.
If however your goal is to understand how Subversion implements the protocol on top of WebDAV and DeltaV then perhaps you want to just use a generic WebDAV and DeltaV client library to help. I'd recommend that you refer to these documents that describe how WebDAV and DeltaV are implemented within Subversion.
One thing you might want to understand is that as of Subversion 1.7 we support what we refer to as HTTPv2. HTTPv2 varies somewhat from the DeltaV standard in particular. Instead of using MKACTIVITY to start a transaction on the server we use a POST. Which has a body with a syntax something like this:
(create-txn)
or
( create-txn-with-props (PROPNAME PROPVAL [PROPNAME PROPVAL ...])
The older style which you must use with MKACTIVITY (and can use with the POST if you use create-txn instead of create-txn-with-props) is to use a PROPPATCH on the transaction or the working baseline URL.
The working baseline URL is used with MKACTIVITY and the transaction URL is used with the POST.
When using MKACTIVITY you have to use a PROPFIND on the root URL to get the version-controlled-configuration. Then do a CHECKOUT against the URL you received in response to that PROPFIND providing the activity-set href as the URL you used with MKACTIVITY. You'll get the working baseline URL back as the Location header from the CHECKOUT request. Which you can then use to issue a PROPPATCH to apply the revision properties.
When using POST, you get the transaction stub from the headers in the OPTIONS request response, the transaction name from the SVN-Txn-Name header in the response to the POST, and execute a PROPPATCH against the $transaction_stub/$transaction_name URL.
Probably the best ways to figure all this out is to setup a Subversion server and do some commits while running Subversion through a debugging proxy server such as Charles. You can force the traffic through the proxy on the svn command line with these options --config-option servers:global:http-proxy-port=8888 --config-option servers:global:http-proxy-host=127.0.0.1. If you want to see the old protocol you can include SVNAdvertiseV2Protocol off in your http configuration.
In order to support the broadest range of Subversion servers you need to implement the HTTPv1 protocol, which has more round trips and is more difficult to implement. If you want to only implement HTTPv2 you'll be limited to supporting Subversion servers newer than 1.7. In order to use HTTPv2 with maximum compatibility you'll have to detect the presence from the OPTIONS response.
As you can see it gets rather complicated so it's really not worth trying to write your own client if all you want to do is implement some basic functionality.
So you are trying to do a SVN commit using WebDAV via the SVNAutoversioning on directive?
http://svnbook.red-bean.com/en/1.7/svn.webdav.autoversioning.html
AFAIK, the spec does not allow you to provide a commit message and the server will always create one for you. Perhaps you want to look at the SVNKit library if you are trying to create SVN transactions via Java.
http://svnkit.com
I am testing the tomcat7 clickstack for our application which has some config parameters set using the built in Config features of Cloudbees. The tomcat7 clickstack does not find them, but the standard tomcat6 container does. I have double checked them and reset them through the cloudbees sdk and they are there and correct, but are coming back as null for tomcat7.
The switch to clickstacks requires us to refactor how the servlet container gets configured so that the injection points such as cloudbees-web.xml and jvm system properties behave consistently across all the servlet container clickstacks.
Some of that refactoring has been committed but some of the work is still in my backlog... Assuming none of the other bees steal that task from my backlog before I get to it ;-)
IF I recall correctly, the parameters should be available as environment variables (sub optimal I know, but all containers should be giving this as a consistent UX for all clickstacks, eg both non-java based and java-based) and may be already available as system properties (again sub optimal, but the java container refactoring should be giving this as a consistent UX for all java based clickstacks). The consistent java servlet UX has not been committed yet but should be available soon.
I have a problem running a Java (using Metro) client against a .NET STS and secured web service. However, when I run my .NET based client, it always works.
As you probably already know, when a JAX-WS client is ran, it requests metadata from the service during runtime (even though it already has ran wsimport during design time). However, it seems that this runtime metadata request is where my problem is.
The problem that I'm facing is that during the runtime requests of metadata, some WSDL's exported by my WCF service caused the Java client to just 'hang' during the mex requests. When it hangs, it doesn't even get to the point of issuing the RST request.
For example, I can get to a spot where I have 9 [OperationContract] attributes and it works. But when I add a 10th service method, it doesn't work. However, if I remove one of the 9, then it works. I know there isn't a problem with a particular method because I can mix and match and the same pattern holds.
I can't seem to deduce a pattern or reason for why some WSDL's work and some don't. I strongly doubt there is a limit to the number of service methods. However, could this be a problem with "overall complexity" with the exported WSDL?
Does anyone have any ideas? Have anyone run into this issue before?
If more information is needed, I can glady post it. I'm just trying to keep the initial post a manageable length.
I will also add that I'm running the STS and secured web serivce in .NET 4, and they are based on WIF (so I don't have to worry about security settings). My .NET client is also .NET 4. On the Java side, I'm using Netbeans 6.9.1 with Metro 2.1 running Glassfish 3. I've verified that I receive the same issue running on Metro 2.0.
Please see WSDL Requests with Metro/JAX-WS/WSIT During Runtime for a detailed answer.
Following the example given, there're chances that MaxMessageReceivedSize or MaxStringContentLength limit is reached. Have you tried increasing the values of MaxMessageReceivedSize and MaxStringContentLength for binding? You can try enabling WCF traces, there'd be a warning logged if any such limit is reached.