Namespace for solution names

[rieder]

Hi

Recently we started developing our first NG solutions. Now we are running a tomcat server at our customer and did deploy the WAR files. Each WAR contains a Servoy application server and is importing the solutions into the same repository. So far, everything is fine.

Now we try to run our Smart Client application on the same tomcat. For this we did deploy a WAR file called 7r.war without active solution. It contains our application context (Servoy application server, plugins, beans, etc). Then we did export the smart client solution as .servoy file and did import it into the context. We found out, that the solutions (and probably also style sheets ) in the Servoy repository are not separated by there context. Which we somehow expected.

• Is this true?
• Is this expected and reasonable behaviour?
• What are the benefits? E.g. reuse of modules.
• What are the downsides? E.g. paying attention when naming solutions (and styles).
• Are there plans for changing this?

Thanks for sharing your opinions and ideas.
Best regards

[sbutler]

Every Servoy instance needs its own repository server DB. In your case, you have 2, since you've deployed 2 WAR files at different context. So you need 2 repository DB's, and your WAR's need to each point to their own repository. It sounds like you did a shared Servoy repository DB between 2 different server contexts, which you shouldn't do.

PS. I assume you also know that you don't need to deploy to another context just to run a different client type? From a single WAR deployment, you should be able to run ng, Smart, and Web clients, assuming there are no namespace conflicts between them so they can coexist in the same repository.

[rieder]

Hi Scott

Thank you for your response! I never thought about running different repositories. Until now, we only had smart clients running in the same repository. But of course, this would separate our code (if needed) and avoid name conflicts. We will do so immediately!

Yes, I know, I do not need an other context, just to allow different client types. But we now have two NG client only solutions. And the smart clients do not run as ng clients without any changes.

Thanks again and best regards