When I try to use the stereotype DISCUSSION with Oracle I get an error because of the entity DiscussionComment column named "comment". Although I'm using the correct dialect for my Oracle version, Hibernate is not quoting DDL as needed. This is a very common problem with simple solution. I just want to apply the solution to OpenXava.
I tried to change the DiscussionComment source in OpenXava project (the one that comes with the OpenXava IDE). I changed the column name but it had no effect.
What and where should I change to alter the mapping of the entity?
The same problem applies to "YourFirstEntity", the demo entity of every project because of the "date" column.
Add the property hibernate.globally_quoted_identifiers to true in your persistence unit in persistence.xml
To modify OpenXava Java code, XML or i18n files:
Modify the code on OpenXava/src, OpenXava/xava or OpenXava/i18n.
Execute the Ant target buildOpenXava from
OpenXava/build.xml. It compiles the OpenXava Java code and creates
openxava.jar.
Refresh OpenXava project in Eclipse (F5).
Execute the Ant target updateOX from the build.xml of your own project.
Refresh your own project in Eclipse (F5).
reference:
https://openxava.org/OpenXavaDoc/docs/modify-openxava-code_en.html
Credits to #javierpaniza
Related
I am using Liferay 6.2 GA5 Community Edition.
Sample case I have 2 entities in my service.xml, let's say entity A & B.
When I run Service Builder then it will generate many JAVA files in my source code, and also generate JAR file located in
".\my-app\liferay-plugins-sdk-6.2\portlets\my-app-portlet\docroot\WEB-INF\lib\my-app-service.jar"
I open it with 7-zip, and I can see in package com.mycompany.myapp.model contains classes of entity A & B.
Then I try to remove entity A in service.xml, and I have removed the corresponding JAVA files generated in my source code, then I run Service Builder again, but inside my-app-service.jar, entity A is still exist.
How do I completely remove it from JAR file? because in my case, Service Builder will not remove it, although I have remove generated JAVA files manually.
ServiceBuilder is a code generator, thus it only generates new code.
If you want to get rid of the once generated code, there's a lot more than just the java classes to get rid of: Spring configuration, Hibernate configuration etc. are there as well for you to take care of. All of these will have to be deleted manually. And if the code still remains in the jar, good old ant clean (or whatever build environment you use) should get rid of the my-app-service.jar file (which you otherwise also can also just delete manually, so that it will be rebuilt next time a build process or ServiceBuilder runs)
I recommend searching for occurrences of A in all your project's files to see if you still find leftovers, because otherwise some component might complain at runtime that a declarated class can't be found.
I'm trying to generate NSManagedModels from my datamodel. Generation works but after I got many errors :
error: filename "Station+CoreDataProperties.swift" used twice:
'/Users/Me/MyApp/Models/CoreData/Station+CoreDataProperties.swift' and
'/Users/Me/Library/Developer/Xcode/DerivedData/MyApp-gwacspwrsnabomertjnqfbuhjvwc/Build/Intermediates/MyApp.build/Debug-iphoneos/MyApp.build/DerivedSources/CoreDataGenerated/Model/Station+CoreDataProperties.swift'
:0: note: filenames are used to distinguish private
declarations with the same name
I try clean build folder and derivedData directory hard delete. I'm using Xcode 8 BETA maybe it's a bug ?
I get this in Xcode 8.1
For me following steps solved the issue. Please note that order matters.
1) Create entity in Core Data model.
2) Under class section, make settings as on following image.
Module: Current Product Name
Codegen: Manual/None
3) Generate your NSManagedObject subclass.
This post greatly helped me solve this problem myself. Personally I look at this as an Xcode bug. Bug or not this is a huge chicken and egg situation.
I ran into this by:
Created a new Project using Core Data
Generated my NSManagedObject subclass+extension (while codegen: ClassDefinition)
I accidentally saved the generated classes in the Wrong folder
I deleted the generated files
Re-generated in folder I wanted
đź’Ą- Xcode used twice errors
As others have posted I kept cleaning my build (and clean build folder) but that never fixed the build issue.
I finally figured out if you originally created your NSManagedObject generated classes with codegen: ClassDefinition, as I did without knowing then you are locked in for the chicken and egg issue.
I then deleted the auto generated classes thinking I had to re-generate, so I did. Once re-generated I would get the used twice build error again. I manually went into the ../DerivedSources/CoreDataGenerated/Model/.. and deleted the duplicates. Again, I re-generated thinking I'd only have 1 copy (in my project) but I was wrong. If codegen: ClassDefinition was originally set then Xcode will keep creating the auto-generated classes+extensions and put them in the buried folder ../DerivedSources/CoreDataGenerated/Model/... I repeated this chicken and egg a few times before catching on.
I later realized you do indeed need to mark codegen: Manual/None however to get things back in sync you need to delete the auto-generated files in ../DerivedSources/CoreDataGenerated/Model/.. and in your project if you have any there still.
Be careful setting codegen: Manual/None, for me it was bit tricky because codegen: Manual/None wouldn't stick. I had to click back and forth between entities multiple times to double/triple check each entity was set to codegen: Manual/None. Then auto generate the files. At this point your only copy of the auto generated files should be in your project and not in ../DerivedSources/CoreDataGenerated/Model/...
Last, I think this is a bug because if you specify codegen: Manual/None I don't expect Xcode to auto generate files at all, yet it does and puts them in your project. More confusing if your setting is codegen: ClassDefinition, who the heck knows Xcode will put the files in a buried directory yet it is available for use in your project. My beef with this is the auto generated files aren't source controlled and if I change computer I have to know to auto-generate them on the new station.
Hope this helps someone else!
Cheers!
This is indeed not a bug. As #Morrowless suggests both class definition and properties extension are created. If this is not wanted, select Manual/None under Codegen before generating the code. If the code is already generated, just delete them, and try Editor->Create NSManagedObject Subclass... again from the menu (after setting Manual/None).
Note, in the picture below, the Class Name 'Contact' is specific to my project. You will see your entity name instead.
If you generated CoreData subclasses with codegen: ClassDefinition your basically screwed. The only way to fix it is to:
Delete your CoreData subclasses.
Delete your derived data folder.
Clean your project (CMD+K).
Generate new CoreData subclasses, this time select Codegen: Manual/None and Module: Current Product Module
This is not a bug. Codegen generates these files in the DerivedData folder, so you don't need to create them again in your project, hence the compile error.
From Xcode 8.0 Release notes:
Xcode automatically generates classes or class extensions for the entities and properties in a Core Data data model. Automatic code generation is enabled and disabled on an entity by entity basis, and is enabled for all entities in new models that use the Xcode 8 file format. This feature is available for any data model that has been upgraded to the Xcode 8 format. You specify whether Xcode generates Swift or Objective-C code for a data model using the data model’s file inspector.
When automatic code generation is enabled for an entity, Xcode creates
either a class or class extension for the entity as specified in the
entity's inspector: the specified class name is used and the sources
are placed in the project’s Derived Data. For both Swift and
Objective-C, these classes are directly usable from the project’s
code. For Objective-C, an additional header file is created for all
generated entities in your model. The header file name conforms to the
naming convention “DataModelName+CoreDataModel.h”.
However, if you selected Category/Extension under the codegen pulldown menu in the data model inspector (because you want to add logic to your model): codegen will wrongly generate both the class definition and properties extension.
The solution is to simply delete the properties extension (ClassName+CoreDataProperties.swift). Your project should now compile.
After following the guidance from oyalhi and Vladimir Shutyuk, (deleting the NSManagedObject files, changing the entity codegen to Manual/None), I had to restart Xcode to allow it to index again before I could re-generate the NSManagedObject files and get a successful compile.
For the sake of completeness..:
I just ran into the same error, but none of the proposed solutions worked. What puzzled me was that even switching from automated code generation to manual for the one (as I thought) problematic entity didn't do anything.
Finally, I figured out that I had several entities with the same name, but they all shared the same classname. The reason for this was that I copy&pasted one entity several times to save me some work, because they also have a few attributes in common.
Turns out XCode renames the duplicates by adding 1, 2,... to the entity name, but leaves the class name as before. And since now entity name and class name are "unrelated", renaming the entity won't change the class name either.
Hope it helps someone - I have also filed a bug report for this.
I am working with a java developer who is writing a jar that needs to use multi-threading. We discovered today that Domino is managing the way that it uses threads using the NotesThread class. He is in the process of changing his code to do it the "domino" way. The traditional java 1.6 way is not going to work.
He is asking me for the jar that contain the following classes so he can build his solution. Can someone point me to what jar contains these classes.
com.ibm.domino.xsp.module.nsf.NSFComponentModule;
com.ibm.domino.xsp.module.nsf.NotesContext;
com.ibm.domino.xsp.module.nsf.SessionCloner;
Note: I have sent him most every XPages and ExtLib jars that I had on my machine and he is still getting a computation error.
Also, I am not 100% sure he is using NotesThread, I recently found this: http://www.wissel.net/blog/d6plinks/SHWL-99U64Q and sent it to him. Perhaps all he needs is to manage the NotesContext and Session. First I need to get him the jar he needs, hence this question. The developer does not have Notes Designer installed. He uses Rational Application Developer to write his jar.
I see Frantisek has pointed you in the right direction for the jar you are looking for.
However, if you need to find one yourself here is how:
In Domino Designer, go to the Editor for Java Design Element (either open an existing .java file or create a new one, you just need to be in the Java Editor. (or alternatively switch to the 'Java' perspective)
Then press 'Ctrl + Shift + T' which is the shortcut for the 'Open Type' dialog.
The Open Type dialog lets you search for a Java Class and will open the Source if it can do so. In this case we won't be able to open the source, but it will tell us where it is getting the .class file from.
The Open Type search will show you matching classes for your search, and if you click one of the classes, it will show you the location of the class/source in the field at the bottom of the dialog.
When I
yo jhipster:entity MyEntity
the generated code is taking no notice of the MyEntity table definition in db-changelog-002.xml. For example, I am expecting the fields on the table to be listed in the generated html. Instead I am getting the 3 default fields for id, text and date.
The db-changelog-002.xml file has been generated by Liquibase using their instructions for generating it from a fresh start. It looks fine as far as I can tell. I put it into the \src\main\resources\config\liquibase directory, along with db-changelog-001.xml
How can I debug? Are my expectations incorrect?
If you are running in "hot reload" mode, then he Liquibase file should be generated, and the database schema should be updated. This the "normal" scenario, and it works surprinsigly well given how complex this task is.
However, the HTML page is not updated. No work has been done to implement this, but this would be a good idea, I'll have a look at it.
Is there a way to generate an XSD document automatically from the binding.xml used by JIBx? This is mainly to allow offline validation of the XML documents will be unmarshalled eventually.
I checked the JIBx homepage, it mentioned a tool called Schema Generator:
http://jibx.sourceforge.net/jibxtools/schema-example.html
but looks like the jibx-genschema.jar file is no longer part of the package anymore, as such I was wondering if there is any alternative
Thanks!
Here is the link to the original package.
http://mirrors.ibiblio.org/pub/mirrors/maven2/org/codehaus/xfire/jibx/genschema/jibx-genschema.jar
Schema generator main class is org.jibx.binding.Compile. It is available in jibx-bind.jar.
This jar can be added to your project with maven dependency org.jibx:jibx-bind:1.2.3 (for example).
The SchemaGen tool has been included in the jibx-tools.jar file for some time. See the JiBX Binding Generator page for instructions on running tools in the jar, just substitute the target class org.jibx.schema.generator.SchemaGen to run the schema generator.