Let's assume that I have deployed 2 cordapps in production: cordapp-a.jar and cordapp-b.jar.
Can I combine those 2 jars in the next release, i.e keep states and contracts of both jars in a single jar without changing structure and the packages of any of the states/contracts?
I am using WhitelistedByZoneAttachmentConstraint.
Yes that is possible. You need to take care of the constraints. You could learn more about constraints here: https://www.corda.net/blog/contract-upgrades-and-constraints-in-corda/
Since you are using WhitelistedByZoneAttachmentConstraint you could perform an implicit upgrade. You need to add the hash of the new jar to the network-parameter.
For HashConstraint, you don't have any option but to perform an explicit upgrade.
Using SignatureConstraint would be even simpler, you just need to make sure that the jars are signed by the same key.
Related
Full Error:
transactions.TransactionBuilder. - The transaction currently built is missing an attachment for class: com/gibtn/corda/printutilities/PrintLedgerTransaction. Attempted to find a suitable attachment but could not find any in the storage.
This has been asked here and here but I hope to get better clarification.
Problem:
I have built a set of libraries to perform common tasks in my Flows that I include in all my CorDapps. For now I just copy the JARs into each project, make some changes to the gradle files and everything works great.
I recently put together a small library for performing common tasks in Contracts and added the JAR the same way.
This works fine with MockNodes. But when I test with real nodes I will get this error in the CRaSH shell and the transaction will fail with a NoClassDefFoundError exception.
Question:
Is what I am doing even possible? Or do I always have to keep my utility classes inside the Contracts module in IntelliJ so they are bundled together with the Contracts into a single JAR? That way when the node starts the JAR (containing the Contracts and any utilities) is added to Attachment storage as a single Attachment.
I found a way to solve this. It's a bit dirty but initial testing seems to work. I just created a blank class in my utilities JAR that implements Contract. It's verify() method is empty. Now when the Corda node starts it sees this Contract and adds the JAR to Attachment storage. So from the CRaSH shell if I run:
attachments trustInfo
...my utility JAR will be listed (it wasn't before). I see when I use one of the utility methods in a Contract the utility JAR will be included as a separate Attachment in the WireTransaction.
I'm not crazy about this solution and will probably stop using a utility JAR for Contracts. I'll go back to copying the classes into each project. Nevertheless there is a way to do it. I would just need a more experienced Corda developer to give it their blessing before I'd go forward into production with it.
Say I'm going to create few microservices: Alpha, Beta, Gamma.
In terms of Application structure using older Symfony version like 2, I'd create a bundle for each service, but bundles are no longer recommended in Symfony 4. So... Should I create separate repositories for every service or still create a bundles in a one App?
If you have different microservices, as in different applications, you will not need bundles. You can keep them in different repositories, but a common practice is to use a so called mono-repository. As the name suggests, with a mono-repository you keep all of the projects in a single repository. This has the benefit that changes spanning all projects can be done more easily and in sync. The drawback is that it requires more effort when managing and might cause additional overhead when building and deploying as it will not be easy to see which service has changed so must likely you rebuild all of them. There are a few books and presentations on mono-repositories you might want to check out. In short, Symfony does not restrict how you manage your services. You can have a single repository for all projects or multiple repositories.
If you want to serve all "services" through the same application, even without bundles, you can do so by using namespaces to separate the logic, e.g. for controllers:
my_app
- src
- Controller
- Alpha
- IndexController
- Beta
- IndexController
This should work out of the Box with the default configuration and even if you deviate you can make things like argument resolvers work by just pointing the configuration to the correct folder. Obviously this will require you to make sure that code is not shared between services should you ever want to extract them into their own application. There are some static code analyis tools that help you with keeping your architecture clean, i.e. make sure Alpha does not use code from Gamma and vice versa.
If you want to separate the apps more clearly by doing something like this:
my_app
- src
- AlphaApp
- ...
- BetaApp
- ...
You can still do that but it will require more manual work and the recipes will not work anymore, requiring you to do manual changes to most configurations and moving around files. How to do it depends on whether you want a shared kernel or a separate kernel for each service, but if you go that route I recommend keeping separate projects in the same repository, as it will probably yield cleaner results and be less work.
You can still create bundles in symfony4 though its not recommended by best practices. see https://symfony.com/doc/current/best_practices/creating-the-project.html
Is there a standard way in symfony + propel to manage changes to the database model in a situation where
the application has a number of separate variants (one for each specific customizations):
core application: code + datamodel
|- variant1: specific code + specific datamodel changes
|- variant2: specific code + specific datamodel changes
...
mulitple developers work at separate parts of the application and therefore also at separate parts of the datamodel
Problems happen e.g. when parts of the datamodel are interdependent (foreign keys) and developers write migrations and oversee these inderdependencies. And since the variants are parallel to each other it becomes increasingly difficult and error prone to keep trak of and write migrations.
I know that this is a what management is all about, but I'm wondering whether there are automatic? ways (- or completely otherways not using propel or using subversion etc. to make checks) that make sure that problems are reduced, ideally to zero.
Basically, I would like to know if there are enterprise grade practices / standards for using symfony and ORM (for symfony 1.4 or 2; propel) that manage multiple developers + multiple variants of the application?
Thanks :)
Propel2 supports parallel migration, means you can have different migration files in different development branches.
So you're just creating migration files based on your changes and new code as usual and commit all that stuff which results basically in having some migration files in branchA and other in branchB. When a branch will be merged to master you can just call the migrate:migrate command at master and are ready to go.
When you switch from branchB to branchA you need to make sure to downgrade the migration in branchB until you have the same base as branchA. Then switch the branch to branchB and do migrate:migrate.
I have a sneaking suspicion that what I'm looking to do can be done more elegantly within Xcode 4 ... but then I've been wrong before. Here's the scoop:
I have an iOS app with the usual debug/release builds and regular, unit-test, and ui-test targets. Nothing unusual there. The app also calls out to a server. Nothing special there either. Except ...
Now I want to be able to build the app for four different server environments: Development, QA, UAT/Beta, and Production. In addition, each build must be able to co-exist on the same device, for developer builds or ad hoc distribution.
So let's see ... how might this pan out? Each app will need its own target identifier for starters. Perhaps detecting the kind of build could help target which server to use:
Debug builds target Development.
(Ad Hoc Distribution) Release builds target QA (... or UAT/Beta?).
(App Store Distribution) Release builds target Production.
As for those Target Identifiers (com.companyname.appname), I suppose I could use different Info.plist files for each build ... but that smells unwieldy (duplicate info). Perhaps it's the only way?
Bottom line: I'm uncertain of a) how to resolve the Ad Hoc vs. App Store Distribution cases, as well as b) the QA/UAT cases, as well as c) how to do this without messing up the (at least to me) more elegant setup Xcode 4 offers with those simple "Press Play" Debug/Release build ops.
Maybe I have to add new Schemes? Perhaps it's simply a matter of adding more Info.plist files ... or builds ... or configurations ... or targets ... or some mixture. Again, I'm trying to keep from duplicating a lot of info (only to change one or two settings) if I can help it. Debug/Release seems very clean as it is, and I want to make sure I change things along the proper axis. Measure twice, cut once, as they say.
Clues welcome/appreciated!
Here's what I ended up doing. Hopefully this is the most sensible way to go about it:
For now, I combined QA and UAT. (This may be split later on.)
I made three Info plists, one for Development (Debug), Beta/QA/UAT (Release), and Production (Release). Each of these has slightly different bundle display names, bundle identifiers, and bundle names, but is otherwise identical. (THIS is where the lion's share of duplicate info will be. Have to change things in all three - for instance, if I add a new font or URL type.)
I created a new configuration, Beta (based on the original Release/Production config), so now there's Dev, Beta, and Production configs as well.
In the Provisioning Portal, I set up App IDs using the previously declared bundle IDs, and generated new certs for Beta, Dev, and Production. (The existing app ID ends up being used for App Store releases.)
In the Build Settings, I used Conditional Settings to specify the appropriate Info plists and code signing identities.
I think this will do the trick! If there's a cleaner way, however, please weigh in. Thanks!
I am starting with a project in Spring-mvc which basically is made up of 3 parts
1) Frontend
2) Backend (admin)
3) Web service
What would be best way to organize these parts so that I can reuse the domain and DAO layer objects wherever I can and at the same time keep the packages separate (so as to avoid class names such as FrontendCategoryController and BackendCategoryController in the same package) ?
Also would it be a good idea to have common config and the pom.xml file for all these parts ?
As of now I have started with the project structure generated by maven as per the webapp archetype
Edit:
One way I am thinking of doing this is -
myapp
-- src
-- main
--java
--resources
-- backend
--java
-- resources
-- webservice
-- java
-- resources
in all java directories, the package names will be same
Would this be a correct approach
Thanks
First of all, depicted approach that misuses Maven directory structure looks really bad.
You say that you want to avoid long class names such as FrontendCategoryController and BackendCategoryController. It looks like your design violates "Package by feature, not layer" rule. You can create separate packages for your subapplications, so that long class names wouldn't be needed. Common classes used by all subapplications can be placed in yet another package.
Alternative approach would be to create separate Maven projects for different subapplications, but it looks like you don't want it.