If we have two components with the same name and precedence then seam throws an exception
java.lang.IllegalStateException: Two components with the same name and precedence - component name:
But these components are in two separate EAR projects.
Isn't APPLICATION scope confined to one application (EAR)?
Does it mean the entire instance?
Related
Given a library referenced in a project. That library has precompiled views (see this post how to achieve it). So the lib has ABC.dll and ABC.PrecompiledViews.dll assemblies.
There's a view in library inside /Views/Shared/Index.cshtml. And a controler which returns it.
Then I have an application references the library (both assemblies). MVC discovers and returns that Index view in runtime.
Now I create a view inside application in Views/Shared/Index.cshtml. So its relative name is the same as in referenced view. By I doing this I mean that I want to override the view from the library.
When application is started from VS (Ctrl-F5) it works but the view in application is ignored.
When application is published (dotnet publish) then the application fails on start with the following error:
InvalidOperationException: The following precompiled view paths differ only in case, which is not supported:
/Views/Shared/Index.cshtml
/Views/Shared/Index.cshtml
Microsoft.AspNetCore.Mvc.Razor.Internal.RazorViewCompiler..ctor(IFileProvider fileProvider, RazorTemplateEngine templateEngine, CSharpCompiler csharpCompiler, Action compilationCallback, IList precompiledViews, ILogger logger)
Besides the problem that the view is ignored when I run from VS it's meaningful behavior. The app has two similar view and can't understand which one to choose.
So the question is how to force MVC to use a particular view (from app instead of from lib)?
There's a method to separate views with same relative names when they are belong to different controllers. Here's nice discussion - Restrict route to controller namespace in ASP.NET Core
But my case is a bit different.
I'm using Jetty 8 to run some servlets. I have two (or more) applications that share source code, and I want to run them on the same port (i.e., 8080). I have placed two different WAR files into Jetty, one.war and two.war, so that I access them at, for example,
http://localhost:8080/one
http://localhost:8080/two
Both WARS contain an identical common JAR file (common utils). Does each WAR application get its own JVM? Really, I just want to be sure that the common JAR classes are entirely separate, since some of the classes are static and I need the two applications to obviously not share access to the same static class.
This seems obvious, and I seemed to confirm that it is the case that the common classes are loaded separately for each WAR with a simple test scenario (two identical WARs hosted in the same Jetty instance, but at different paths...see above). But I lack written documentation or confirmation that this is the case.
Each WAR file will have its own class loader see http://docs.codehaus.org/display/JETTY/Classloading. So you can safely use static classes.
An application I am working on is encapsulated inside an ear file, which contains a jar (containing EJB files) and a war (having, apart from its normal contents, package hierarchy of action classes, directly inside it). The context-root is specified in both WEB-INF/jboss-web.xml as well as in META-INF/application, and, well... is different in both.
The interesting part is that if I deploy that ear file in JBoss 4.2, I am able to access the application by the context-root given in application.xml, whereas when I deploy it in JBoss-6.1, I can access my application only with the context-root provided in jboss-web.xml. Why is this happening ?
Could there be a rationale for specifying two different context-roots in the 2 xml files ?
I'm integrating a series of controllers into an existing project which already contain controllers which use Castle Windsor for DI/IoC. I've modified the Installer to only register Controllers in a certain namespace (specifically the root). This modification appears to be working. When I try to access my controllers, which do not use Castle Windsor and are located in a different namespace (specifically, a custom Area), I get the error message: "No component for supporting the service [Controller Name] was found".
Is it possible to mix "traditional" controllers with controllers which use Castle Windsor in a single project?
Does this make sense?
If you are getting that error, you are trying to resolve the controller (directly or indirectly) through the container.
If you have a separate logic path that needs a controller that isn't register from the container, nothing is stopping you from calling new MyController().
As an aside, thinking in terms of the controller using the container is somewhat backwards. The container manages your instances--your instances have no idea whether they are container-managed or not.
When starting a BizTalk project I generally follow the naming conventions found here. Where you name your projects and assembly's something like:
MyCompany.MyProject.Orchestrations.dll
MyCompany.MyProject.Schemas.dll
MyCompany.MyProject.Pipelines.dll
MyCompany.MyProject.Transforms.dll
MyCompany.MyProject.PipelineComponents.dll
A couple of questions for other BizTalk folks:
1) I usually find myself having more than one project with schemas or a need to separate schemas. Do you stick them in separate assemblies and if yes, what convention do you then follow for naming the project/assembly. If no, do you stick them in a subfolder in one assembly.
2) I believe, could be wrong, that it's been sort of a BizTalk convention to name the project and assembly the same, like above. I've thought about getting away from naming the projects the same as the full assembly name, so I might have the project named Maps and it's assembly is named MyCompany.MyProject.Maps. Do others do this?
Starting with BTS 2009 we named our projects and assemblies according to the application they belong to plus an optional sub-application or concern scope:
MyCompany.Biz.MyFirstApp.dll
MyCompany.Biz.MyFirstApp.Util.dll
MyCompany.Biz.MyFirstApp.ConcernOne.dll
MyCompany.Biz.MySecondApp.dll
We took the path to keep orchestrations, schemas and maps together because multi-assembly dependencies can make deployment a real hassle.
Our main goal was to separate source and target systems to avoid direkt references. We achieved this be introducing "core" components for all concerns we're dealing with:
BTS application MyFirstApp
MyCompany.Biz.MyFirstApp.OrderProcessing.dll
MyCompany.Biz.MyFirstApp.Util.dll
BTS application CORE
MyCompany.Biz.CORE.OrderProcessing.dll
BTS application MySecondApp
MyCompany.Biz.MySecondApp.OrderProcessing.dll
Both MyFirstApp and MySecondApp will reference schemas in CORE.OrderProcessing.
Update
MyCompany.Biz.MyFirstApp.OrderProcessing would contain the message schema for incoming order documents and a map for mapping those into the core order message schema (contained in MyCompany.Biz.CORE.OrderProcessing). If needed it could also contain an orchestration for receiving messages and (receive) pipeline components (when dealing with flat files for example).
MyCompany.Biz.MySecondApp.OrderProcessing would contain the message schema for outgoing documents and a map for mapping from the core order message schema (to outgoing).
In this basic layout CORE will merely be a container for your internal message schemas but it will be the best location to add information to your order documents - for example an orchestration which awards a global discount for class A customers (Business Rules!). In short basically any step you'd do twice or even more times when sending or receiving messages and you do not want to touch if incoming or outgoing message schemas changes or new application is added.
Here is a wonderful BizTalk Naming Conventions guide from Scott Colestock