In my service.xml I defined two entities Assignment and Submission, with the latter containing <column name="assignmentId" type="long"></column>.
After I run Gradle's buildService, I get this code in AssignmentLocalService:
public Assignment addAssignment(Assignment assignment);
[...]
#Indexable(type = IndexableType.REINDEX)
public Assignment addAssignment(Assignment assignment);
Eclipse marks this as an error, and Gradle's jar task fails with:
error: method addAssignment(Assignment) is already defined in interface AssignmentLocalService
Why is Service Builder doing this?
How to prevent it from creating duplicate methods, or how to make compilation work if Service Builder is actually doing the right thing?
Related
We are getting following below error when we deploy any application in Liferay DXP 7.
When we clean the Liferay DXP and then redeploy the below issue gets fixed.
But the problem with this approach is that all the caches gets deleted after cleaning and when we redeploy and access the site , the caches gets recreated but it takes lot of time to access any page on the site.
[2018-05-17 10:58:33,113] [DEBUG] [10.111.2.74] [] [http-nio-5443-exec-8] [com.fsvps.clientPortal.service.common.ProgramFilterPopulator] - Retrieving logged in user
[2018-05-17 10:58:33,137] [DEBUG] [10.111.2.74] [] [http-nio-5443-exec-8] [com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor] - Portlet mode view and debug mode = false
[2018-05-17 10:58:33,137] [DEBUG] [10.111.2.74] [] [http-nio-5443-exec-8] [com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor] - Checking to see if invalid filter view should be shown
[2018-05-17 11:07:40,859] [DEBUG] [] [] [http-nio-5443-exec-2] [com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor] - Entering
[2018-05-17 11:07:40,859] [WARN] [] [] [http-nio-5443-exec-2] [org.springframework.web.portlet.DispatcherPortlet] - Handler execution resulted in exception - forwarding to resolved error view
java.lang.ClassCastException: com.fsvps.clientPortal.domain.common.UserContext cannot be cast to com.fsvps.clientPortal.domain.common.UserContext
at com.fsvps.clientPortal.domain.common.UserContext$$FastClassBySpringCGLIB$$818d2483.invoke(<generated>)
at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:738)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:133)
at org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:121)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:673)
at com.fsvps.clientPortal.domain.common.UserContext$$EnhancerBySpringCGLIB$$830ac420.setIpAddress(<generated>)
at com.fsvps.clientPortal.util.common.UserContextInitializationInterceptor.preHandle(UserContextInitializationInterceptor.java:93)
at org.springframework.web.portlet.handler.HandlerInterceptorAdapter.preHandleRender(HandlerInterceptorAdapter.java:72)
at org.springframework.web.portlet.DispatcherPortlet.doRenderService(DispatcherPortlet.java:739)
at org.springframework.web.portlet.FrameworkPortlet.processRequest(FrameworkPortlet.java:537)
The exact cause is impossible to pinpoint with the information you give. However, the class of problem is easy to identify:
java.lang.ClassCastException:
com.fsvps.clientPortal.domain.common.UserContext cannot be cast to
com.fsvps.clientPortal.domain.common.UserContext
(separated to lines to illustrate the identical class name)
Whenever a class can't be typecasted to itself or a legitimate superclass/interface, you're dealing with duplicate code: There are two versions of the class with the same name available to the classloader, and the system is choosing both.
As the error message just contains the name of the class, not its classloader, a first glance at the error message doesn't make sense. Knowing that a class is uniquely described by its package, name, and its classloader leads you to the root cause.
Identify your modules and make sure that there's only one option for com.fsvps.clientPortal.domain.common.UserContext available.
Edit: Answering to your comments - without knowing your deployment details, there's no way to help you other than wild guesses. Please add more information to your question if the next wild guess doesn't help:
The name of the class, UserContext, suggests that you might store it somewhere, e.g. in a session. Doing so will prevent the original class from unloading when you're undeploying your plugin. Note that there is a huge difference between undeploying code and garbage collecting objects: GC can only happen, when there is no more reference.
If you deploy an updated version of your plugin, the old and existing objects still are referencing the previously loaded UserContext class, while the new code is trying to assign it to a new UserContext reference. Even though, both might be identical in implementation, they are different classes that just share the name.
You can't keep long living references to code that might undeploy, and expect them to stay usable. A quick fix (if you're deploying OSGi modules) might be to extract stable and long-used classes into its own bundle that you won't redeploy. Or replace session stored objects (assuming that this is it) with Java runtime classes, e.g. Map of built-in types, and build a UserContext object from those types whenever you need it.
I'm trying to use AutoMapper in a API wrapper class library project to map from API models to our domain models. While looking at the AutoMapper documentation I ran into the inline mapping feature.
Documentation says:
AutoMapper creates type maps on the fly (new in 6.2.0). When you call Mapper.Map for the first time, AutoMapper will create the type map configuration and compile the mapping plan. Subsequent mapping calls will use the compiled map.
So I wrote the following line of code in my wrapper class library:
var data = response.Results.Select(Mapper.Map<Session, Media>).ToList();
basically just trying to map the Session object I get from the API into our Media objects. But this throws the following error:
Mapper not initialized. Call Initialize with appropriate configuration. If you are trying to use mapper instances through a container or otherwise, make sure you do not have any calls to the static Mapper.Map methods, and if you're using ProjectTo or UseAsDataSource extension methods, make sure you pass in the appropriate IConfigurationProvider instance.
I was under the impression that inline mapping is exactly supposed to bypass having to initialize and define configuration for AutoMapper? Am I wrong?
Also if I am indeed wrong then how are you supposed to configure and initialize AutoMapper inside a class library to where it happens only once? I would like the library to be independent, meaning I don't want the programmer using the library to have to configure AutoMapper in his project in order for the library to work properly.
I'm in the process of trying to migrate a R# extension project from R# 6 to R# 8. (I've taken over a project that someone wrote, and I'm new to writing extensions.)
In the existing v6 project there is a class that derives from RenameWorkflow, and the constructor used to look like this;
public class RenameStepWorkflow : RenameWorkflow
{
public RenameStepWorkflow(ISolution Solution, string ActionId)
: base(Solution, ActionId)
{
}
This used to work in R# SDK v 6, but now in V8, RenameWorkflow no longer has a constructor that takes Solution and actionId. The new constructor signature now looks like this;
public RenameWorkflow(
IShellLocks locks,
SearchDomainFactory searchDomainFactory,
RenameRefactoringService renameRefactoringService,
ISolution solution,
string actionId);
now heres my problem that I need help with (I think)
I've copied the constructor, and now the constructor of this class has to satisfy these new dependancies. Through some digging I've managed to find a way to satisfy all the dependencies, except for 'SearchDomainFactory'. The closest I can come to instantiating via the updated constructor is as follows;
new RenameStepWorkflow(Solution.Locks, JetBrains.ReSharper.Psi.Search.SearchDomainFactory.Instance, RenameRefactoringService.Instance, this.Solution, null)
All looks good, except that JetBrains.ReSharper.Psi.Search.SearchDomainFactory.Instance is marked as Obsolete, and gives me a compile error that I cannot work around, even using #pragma does not allow me to compile the code. The exact error message I get when I compile is Error 16 'JetBrains.ReSharper.Psi.Search.SearchDomainFactory.Instance' is obsolete: 'Inject me!'
Obvious next question..ok, how? How do I 'inject you'? I cannot find any documentation over this new breaking change, in fact, I cannot find any documentation (or sample projects) that even mentions DrivenRefactoringWorkflow or RenameWorkflow, (the classes that now require the new SearchDomainFactory), or any information on SearchDomainFactory.Instance suddenly now obsolete and how to satisfy the need to 'inject' it.
Any help would be most appreciated! Thank you,
regards
Alan
ReSharper has its own IoC container, which is responsible for creating instances of classes, and "injecting" dependencies as constructor parameters. Classes marked with attributes such as [ShellComponent] or [SolutionComponent] are handled by the container, created when the application starts or a solution is loaded, respectively.
Dependencies should be injected as constructor parameters, rather than using methods like GetComponent<TDependency> or static Instance properties, as this allows the container to control dependency lifetime, and ensure you're depending on appropriate components, and not creating leaks - a shell component cannot depend on a solution component for instance, it won't exist when the shell component is being created.
ReSharper introduced the IoC container a few releases ago, and a large proportion of the codebase has been updated to use it correctly, but there are a few hold-outs, where things are still done in a less than ideal manner - static Instance properties and calls to GetComponent. This is what you've encountered. You should be able to get an instance of SearchDomainFactory by putting it as a constructor parameter in your component.
You can find out more about the Component Model (the IoC container and related functionality) in the devguide: https://www.jetbrains.com/resharper/devguide/Platform/ComponentModel.html
I have created a Visual Studio extension that provider syntax highlighting by implementing IClassifierProvider. I would like to add additional features such as support for the standard Edit.CommentSelection and Edit.FormatDocument commands, but I have no idea how to do that. All the documentation I can find is about adding new commands, but the commands I want to handle already exist.
How can I handle these commands?
I considering the specific Comment Selection and Uncomment Selection commands you refer to as special cases, because I'm working on a Commenter Service specifically intended to support these two actions. The service is being developed on GitHub and will be released via NuGet when it is ready. I'll start with a description of this service, and follow with some general information about implementing support for specific commands, including the Format Document command.
I would like to release the library and its dependencies this week, but the restriction that the Commenter Interfaces assembly be an immutable assembly demands more testing than is generally given to a library prior to its initial release. Fortunately the only thing in this particular assembly is two interfaces is the Tvl.VisualStudio.Text.Commenter.Interfaces namespace.
Using the Commenter Service
Source: Commenter Service (Tunnel Vision Labs' Base Extensions Library for Visual Studio)
This services allows extension developers to easily support the Comment and Uncomment commands for new languages in Visual Studio.
Providing a Standard Commenter
The easiest way to provide commenting features is to use the standard Commenter implementation of the ICommenter interface. The following steps show how to create an instance of Commenter and provide it to the Commenter Service by exporting an instance of ICommenterProvider.
Create a new class derived from ICommenterProvider. This class is exported using the MEF ExportAttribute for one or more specific content types using the ContentTypeAttribute. The commenter in the example supports C++-style line and block comments, for the SimpleC content type.
[Export(typeof(ICommenterProvider))]
[ContentType("SimpleC")]
public sealed class SimpleCCommenterProvider : ICommenterProvider
{
public ICommenter GetCommenter(ITextView textView)
{
// TODO: provide a commenter
throw new NotImplementedException();
}
}
Define the comment format(s) the commenter will support.
private static readonly LineCommentFormat LineCommentFormat =
new LineCommentFormat("//");
private static readonly BlockCommentFormat BlockCommentFormat =
new BlockCommentFormat("/*", "*/");
Implement the GetCommenter(ITextView) method by returning an instance of Commenter. The ITextUndoHistoryRegistry service is imported in order for Commenter to correctly support the Undo and Redo commands. The following code is the complete implementation of ICommenterProvider required to support the Comment and Uncomment commands for a simple language.
[Export(typeof(ICommenterProvider))]
[ContentType("SimpleC")]
public sealed class SimpleCCommenterProvider : ICommenterProvider
{
private static readonly LineCommentFormat LineCommentFormat =
new LineCommentFormat("//");
private static readonly BlockCommentFormat BlockCommentFormat =
new BlockCommentFormat("/*", "*/");
[Import]
private ITextUndoHistoryRegistry TextUndoHistoryRegistry
{
get;
set;
}
public ICommenter GetCommenter(ITextView textView)
{
Func<Commenter> factory =
() => new Commenter(textView, TextUndoHistoryRegistry, LineCommentFormat, BlockCommentFormat);
return textView.Properties.GetOrCreateSingletonProperty<Commenter>(factory);
}
}
Command Handling in Visual Studio
The following are general steps for handling commands in Visual Studio. Keep in mind that the implementation details are quite complicated; I've created some abstract base classes to simplify specific implementations. After this overview, I will point to both those and a concrete example of their use for you to reference.
Create a class which implements IOleCommandTarget. The QueryStatus method should check for the specific commands handled by your command target and return the appropriate status flags. The Exec method should be implemented to execute the commands.
Register the command target with a specific text view by calling IVsTextView.AddCommandFilter. If you are working with an MEF-based extension, you can obtain the IVsTextView by either exporting an instance of IVsTextViewCreationListener, or by importing the IVsEditorAdaptersFactoryService component and using the GetViewAdapter method to obtain an IVsTextView from an instance of ITextView.
Here are some specific implementations of the interfaces described here:
CommandFilter: This class implements the basic requirements for IOleCommandTarget
TextViewCommandFilter: This class implements additional functionality to simplify the attachment of a command filter to a text view
CommenterFilter: This class is a concrete implementation of a command filter used by the Commenter Service implementation to handle the Comment Selection and Uncomment Selection commands
I have an EDMX model with a generated context.
Now i generated a Self Tracking Entities library is separate project and referenced this from the EDMX model.
Also set the correct namespace in the context to the same namespace as the entities.
Now working with this all works except when i try to create a WCF data service with this context.
So just create new ObjectContext and working with it directly works fine.
But having referenced the context + model lib and the entities lib i get the following error when loading the service
The server encountered an error processing the request. The exception message is 'Value cannot be null. Parameter name: key'. See server logs for more details. The exception stack trace is:
Now i found that this could happen when using data service with external entity lib and fix was overriding the createcontext
with code
Collapse
System.Data.Metadata.Edm.ItemCollection itemCollection;
if (!context.MetadataWorkspace.TryGetItemCollection
(System.Data.Metadata.Edm.DataSpace.CSSpace, out itemCollection))
{
var tracestring = context.CreateQuery<ClientDataStoreContainer>("ClientDataStoreContainer.DataSet").ToTraceString();
}
return context;
Now the error is gone but i get the next one and that is:
Object mapping could not be found for Type with identity 'ClientDataStoreEntities.Data'.
This error occurs on the .toTraceString in the createcontext
the ssdl file has the defined type
Collapse
<EntitySetMapping Name="DataSet">
<EntityTypeMapping TypeName="IsTypeOf(ClientDataStoreEntities.Data)">
So it has to load the ClientDataStoreEntities.Data type which is the namespace and type of the STE library that i have generated from the model.
EDIT: with
var tracestring = context.CreateQuery<Data>("ClientDataStoreContainer.DataSet").ToTraceString();
It does seem to load all types , however now the service does not have any methods that i can call.
there should be 2 DataSet and PublishedDataSet but:
<service xml:base="http://localhost:1377/WcfDataService1.svc/">
−
<workspace>
<atom:title>Default</atom:title>
</workspace>
</service>
is what i get.
I ran into the same issue (the first one you mention). I have worked around using the suggestion by Julie Lerman in this thread. The other suggestion didn't work for me although I will experiment with them more since Julie's solution may have performance implications since it's executed (and has some cost) for every query.
MSDN Fail to work with POCO ModelContainer which entities are located in other assembly
Edit: Sorry, just realized you utilized the other solution mentioned in this thread.