When I try to launch my SeedStack application, I get the following error:
org.seedstack.seed.SeedException: [CORE] Multiple seedstack launchers
Description
-----------
There are multiple SeedStack entry points in the classpath.
Fix
---
Exactly one class implementing 'org.seedstack.seed.spi.SeedLauncher' should be present in the classpath and registered in
META-INF/services. Remove all but one launcher.
What is the cause of this and how can I fix it ?
A SeedLauncher is used to launch a particular kind of application (Web app, CLI app, ...). A SeedStack module can only be of one kind at a time.
The error above occurs when you have multiple active implementation of the SeedLauncher interface in your classpath. By active I mean present and registered as a service in META-INF/service.
The most common cause is when you have the seed-web-undertow and the seed-cli dependencies in the classpath at the same time, as both provide their own implementation of SeedLauncher.
You have to choose if your module should be a CLI application or a Web application and remove the useless dependency. If you want to build both kinds, you'll have to separate them in different modules.
Some add-ons can also provide launcher which can interfere in the same way. If the quick solution above doesn't resolve your problem, use your IDE to find all implementations of the SeedLauncher interface and re-organize your modules to have only one launcher per module.
Related
The document shows me how to create ProcessEngineConfiguration and ProcessEngine, and then it shows me how to modify process instances. I don't know how to manage my process and case defintion files with Repositoryservice. Is there any example?
You have several ways of deploying your diagrams to the engine.
The easiest is to have a ProcessApplication on the classpath and a processes.xml file in src/main/resources/META-INF (con be empty). Camunda will then scan your library and deploy all processes on startup.
Second option, though I personally would not advise you to, is that you use the engine-spring module and activate auto-deployment
And as a third option, you can still deploy manually by using either repositoryService.createDeployment().addClasspathResource(...).deploy() or use the rest api.
I am building out a Sitecore farm with multiple Content Delivery servers. In the current process, I stand up the CD server and go through the manual steps of commenting out connection strings and enabling or disabling config files as detailed here per each virtual machine/CD server:
https://doc.sitecore.net/Sitecore%20Experience%20Platform/xDB%20configuration/Configure%20a%20content%20delivery%20server
But since I have multiple servers, is there any sort of global configuration file where I could dictate the settings I want (essentially a settings template for CD servers), or a tool where I could load my desired settings/template for which config files are enabled/disabled etc.? I have used the SIM tool for instance installation, but unsure if it offers the loading of a pre-determined "template" for a CD server.
It just seems in-efficient to have to stand up a server then config each one manually versus a more automated process (ex. akin to Sitecore Azure, but in this case I need to install the VMs on-prem).
There's nothing directly in Sitecore to achieve what you want. Depending on what tools you are using then there are some options to reach that goal though.
Visual Studio / Build Server
You can make use of SlowCheetah config transforms to configure non-web.config files such as ConnetionStrings and AppSettings. You will need a different build profiles for each environment you wish to create a build for and add the appropriate config transforms and overrides. SlowCheetah is available as a nuget package to add to your projects and also a Visual Studio plugin which provides additional tooling to help add the transforms.
Continuous Deployment
If you are using a continuous deployment tool like Octopus Deploy then you can substitute variables in files on a per environment and machine role basis (e.g. CM vs CD). You also have the ability to write custom PowerShell steps to modify/transform/delete files as required. Since this can also run on a machine role basis you can write a step to remove unnecessary connection strings (master, reporting, tracking.history) on CD environments as well as delete the other files specified in the Sitecore Configuration Guide.
Sitecore Config Overrides
Anything within the <sitecore> node in web.config can be modified and patch using Include File Patching Facilities built into Sitecore. If you have certain settings which need to be modified or deleted for a CD environment then you can create a CD-specific override, which I place in /website/App_Config/Include/z.ProjectName/WebCD and use a post-deployment PowrrShell script in Octopus deploy to delete this folder on CM environment. There are example of patches within the Include folder, such as SwitchToMaster.config. In theory you could write a patch file to remove all the config sections mentioned in the depoyment guide, but it would be easier to write a PowerShell step to delete these instead.
I tend to use all the above to aid in deploying to various environments for different server roles (CM vs CD).
Strongly recommend you take a look at Desired State Configuration which will do exactly what you're talking about. You need to set up the actual configuration at least once of course, but then it can be deployed to as many machines as you'd like. Changes to the config are automatically flowed to all machines built from the config, and any changes made directly to the machines (referred to as configuration drift) are automatically corrected. This can be combined with Azure, which now has capability to act as a "pull-server" through the Automation features.
There's a lot of reading to do to get up to speed with this feature-set but it will solve your problem.
This is not a Sitecore tool per se.
I am evaluating wso2 and came across the following issue: imagine that my company already has a well defined Common Data Model for their business. Those schemas (and even service definitions - wsdls) live on a repository and references between files are done using relative paths between them. Now, what I want is to import all of these XSD's and WSDL's into wso2 Gorvernance Registry (wso2greg) to make it manage them. More (and this is where I start to lose the grip on wso2) I want to reference wso2greg's resources on wso2bps's BPEL Workflows. I want to say: "Hey, workflow! Forget all about your auto-generated interface. Your interface will be this one {wsdl_from_wso2greg}."
I am trying to accomplish this by creating an Registry Resources Project inside my "main" Carbon Application Project (along-side with my BPEL Workflow) and then creating PartnerLinks on the workflow but, after I configured everything, I get the following error: "The import location of ../TestGreg/TestServiceWsdl.wsdl is not supported by this implementation. Import artifacts must be contained within the folder hierarchy that has the deployment descriptor at the root".
Now, am I doing something really stupid or wso2 really does not support what I am trying to do? If so, how do you guys usually deal with these issues?
Thks,
Leandro Nunes
When you are referring to WSDLs/XSDs from BPEL, you need to package them with BPEL. You cannot refer the ones stored in the registry.
Referring from the external registry can be done only for security policies and endpoint references. Any other resources need to be packaged with the BPEL.
I have a list of Jenkins jobs that are independent, but it would be convenient if I could group them together to have them all run with the click of one button. Each of the projects is concerned with deployment, not compilation.
I've found the bulk-builder plugin, but to use bulk-builder it's necessary to specify a pattern each time you wish to invoke it.
I'm looking for a Jenkins plugin that will allow me to group projects together, and the Maven system seems to suggest this is possible: I'd make a top level build job that sets up dependencies on each of the jobs I wish to run, then I'd just need to run my top level job.
If possible, has anyone found Maven to be useful in managing dependencies of anything but Java? Would I be able to use it in the way I'm expecting?
EDIT: These are all .net projects
In jenkins, you can explicitly define other projects to build upon a successful build (search for downstream). This way, you can have one project trigger bunch of others effectively grouping them.
Maven is a great tool but I wouldn't use it for this purpose.
I am thinking about writing my own release storage server and before I do this, I'd like to know what people use to see integration instead of create.
So what do you use to store your builds for internal access?
I'm looking for a web app that allows me to upload artifacts and then reference them by various tags so I can group them together by component or release vehicle. I also want access controls per build by readiness or promotion.
I define staging as placing built artifacts on a server for communities of users to access. The artifacts are usually zip files containing either applications or libraries + documentation. The user communities are developers, QA, and service delivery/operations. Basically, the creators, the checkers and external-users.
We release artifacts individually and as groups in a release vehicle (e.g., release 1.1 contains foo 1.0.1 and bar 1.0.7). Depending on the artifact, we may want to restrict access. Operations shouldn't be able to access pre-released builds and we may want to track who downloads a limited availability release.
So, I'm hoping to find a tool that does most of what I want with a good extensible design so I can add in what I don't have.
Any one know of a good tool for managing the builds post-build?
Examples might be:
quickbuild/lunt build
Team forge
build forge
Jira & confluence as a set
sonatype nexus
home grown
SVN repository using branching to promote builds from dev->Qa->GA
Peter,
Since you're not getting many answers, I'll let you know about AnthillPro whose developer, Urbancode, I work for.
Ok, disclaimers out of the way, AnthillPro is designed to serve exactly the broad audience that you're discussing - dev, checkers, and operations. Compared to the tools you list, AnthillPro is something like a BuildForge (a key competitor of ours) or quick build with a tightly integrated artifact repository (like nexus). So the builds are run, and you can view the results of your builds - and the build artifacts - in a nice web ui. Users with correct permissions can run a secondary process like a deployment or test against prior builds - and the artifacts from the selected build.
The goal is to manage the entire build lifecycle from creation, through various testing tools and deployment environments out through release to production. It's not a big nasty suite, instead we integrate with tools like Subversion and Jira to make sure every release has a manifest of source and problem ticket changes.
Your release packages would map well to AnthillPro's built in dependency system. We often see customers create virtual projects that take little or no source code, but instead either relate or package components into a release bundle.
Where AnthillPro may fall short for you is that generally, we would allow operations to see pre-release builds. However, you could add rules that would immediately fail / block an attempted releaes by operations of any build not marked as "pre-release". AnthillPro's system of statuses allows the team to flag a build with custom markers like, "In QA" or "Approved for Release". Combined with rules about running workflows,that should give you the control you need. If some projects are particularly sensitive, you'd just use the role based security to lock those away.
Hope that gives you something to look into.
-- Eric
My options are
build automation systems like AntHill, QuickBuild, TeamForge, BuildForge
file server
source control server
maven repository manager (nexus, archiva)
My goals are
group build by multiple criteria (artifact type, release vehicle, stage/phase)
promote build from dev -> qa -> released
provide access control for dev builds, qa ready builds, production ready builds
I'm going to focus on either source control as file server (using svn) or maven repos manager as file server using nexus. The rational is as follows:
minimize effort
minimize cost
use something I can easily extend when needed to (because I'm certain my requirements will shift).
maven use is growing and will eventually be the dominant build technology here.
Thanks for the information.