i've some classes deployed in WEB-INF/classes.
When i refresh design database on production, this classes are not updated?
Why?
Depending on the server version you need to take a "brute force" attack:
Instead of refresh design use replace design
Use a small agent that removes the Java design elements before the refresh/replace operation (they are stored in regular design note entries
The failure might happen when the classes are currently loaded
Try to make Clean on production database after design refresh. That will wipe class files and compile them from sources. From that moment on there should be no problem with next refresh.
Related
We have a (super)user who has been using VBA in an Excel spreadsheet to create and manipulate documents in a Domino database application.
The user has 'Editor' access to the application, and should normally be able to create/edit the document contents.
They have been, however, creating documents using VBA. That logic doesn't consider such important document fields as Readers, Authors, etc. .
We would like to restrict access to all Domino data so that it can only be created/modified using an IBM Notes client.
I have tried looking through the ECL, but that only restricts what 'others' do.
Since he has his Notes client available, the external logic is using his normal Notes credentials.
I have tried setting a hidden field with the Notes client and looking for that in the QuerySave event of the form design.
Unfortunately, the external code pays no attention to the form events and the save is executed despite the missing field.
Similarly, the Database Script has no bearing on the execution of external logic.
I was going to inspect the client version upon database open and restrict activity based on a variance in the version (I was hoping!).
I have de-selected the 'Don't prompt for a password...' option in the user security preferences, but that has no effect at all (suspected as much!).
The ONLY thing I have been able to suggest is to hide the database design... That's really only designed to thwart a user's efforts to understand the underlying design.
It won't prevent them from creating hundreds of thousands of documents with a fictitious form and throwing the app into disarray.
I'm hoping that there is a solution out there that I'm missing.
The user has been instructed not to undertake such activity in the future.
We were lucky that there really wasn't any malicious intent - "Just trying to be more efficient" we're told.
The effects of the activity have been remedied, and the user has been warned.
What I want to know is... how can I prevent this from ever happening again?
The circumstances are rare I know, but I would've thought there'd be a means of restricting the platforms used to manage Notes/Domino data.
Is there a way to ensure no external applications are able to access, create or modify Notes database documents?
I am currently focussing on access to Notes via COM.
I thought that, if I unregistered 'nlsxbe.dll' from the registry, that would prevent such activity - It has not.
I also tried removing the .TLB files from the Notes executable folder - removal of 'notes32.tlb' and 'domobj.tlb' have no effect at all. Removal of 'ltsci3.tlb' screws everything up (as expected!).
I'm really having no luck at all - Any/all suggestions would be most appreciated!
I'm not aware of any way to detect that a connection has been made by standalone code instead of by the Notes client, but you do have two paths available to you:
A Domino server add-in that prevents documents from being saved in that particular database if certain criteria aren't met.
An agent that is triggered to run shortly after documents are saved or modified in that particular database. The agent code can delete (or modify, if you prefer) the documents that don't conform to the required criteria.
The server add-in route would normally require coding in C, but thanks to the Open NTF Trigger Happy project, the hard part is done for you, and the rest can be filled in with either LotusScript or Java agent code that is "triggered" by the pre-written C code. You will need to have some basic knowledge of how the Notes Extension Manager interface works, but once you get past that and write your agent code to enforce your data consistency/integrity requirements, the only real hurdle is your willingness to host open source code on your server.
There may be two other possibilities, but I can't say if either will solve or deal with the issue...
In the ECL you can disable 'COM' access for the user (also known as OLE or ActiveX) automation since VBA access is usually via COM. This has stopped Notes using external COM access for me, but I don't know if also prevents VBA using Notes. Additional steps may be needed to enforce the ECL and apply to the specific users.
There is an (old) notes.ini 'DisableExternalApps' (or something similar) that disables some external access. This can affect many things (DDE/Prompts/#dblookups) but again I don't know if this will disable VBA/COM and its not user specific, but server wide.
I would have thought that removing the nlsxbe.dll or restricting access to execute it might work, but the ECL may be the best bet.
Alternatively, rather than add hidden flags to your design (and the documents), and then delete the offending documents, your agent could apply the correct author/reader fields to the documents instead.
Very tricky. Did you find a better solution?
Scenario: We have four databases that are setup to inherit from a master template and they in turn have individual design elements that inherit from a different master template via template name added in the field shown in image.
It has always been my understanding that in order for the individual design elements in the database to inherit any changes a version of the master template must also be on all servers where the database resides so that the nightly server process will make updates to the design element(s).
Is this true? Does this change when creating a build using Teamstudio CIAO Builds/Promotions?
If you want changes to any design elements to be automatically picked up from templates overnight - regardless of whether they inherit individually as in your screenshot, or inherit from the template named in the database properties - then one of the following must be true:
If the database is replicated to multiple servers, then the templates must be on at least one of those servers; or
If the database is only on one server, then the templates must be on that server.
So, if you have a few databases that are on one server each and not replicated, and they inherit from the same templates, then you'd need those templates on every server to get automatic overnight inheritance in every database.
However, there's no need to rely on automatic inheritance, as users with Designer access to affected databases can manually refresh designs from templates using the Notes or Designer client. If you do this, you can keep the templates on just one server regardless of how many servers have databases using those templates.
Note regarding template designs in any case, whether databases are automatically or manually refreshed: Best practice (as I understand it) is to have production template designs signed by a single user id created for the express purpose of signing designs, with a Domino policy in place to ensure that all users Execution Control Lists (ECLs) trust that signer, to prevent users from getting ECL alerts when using production applications.
My experience with Teamstudio CIAO isn't extensive, but I don't think it changes any of the above.
CIAO! / Build Manager uses the IBM Domino API to perform a Design Refresh, therefore it does not need to wait for the nightly Design task to run.
CIAO! / Build Manager calls the Design Refresh API and passes the Target DB info and then name of the IBM Server where the template resides. Therefore for a full design refresh of a Target db the Template does not need to reside on the same server.
If you have indicated a Design Template for individual Design Elements within a Notes Application, then in this scenario the Master Template would need to reside on the IBM Domino server where the Notes Application also resides. The CIAO! / Build Manager application does not include the capability of updating these individual Design Elements.
I'm looking for simple way to update custom translations in Liferay without redeploy of language hook. Restart is no option for me too :).
UPDATE:
The customer has quite big portal with about 50 different portlet-applications. Each application has rich user interface in four languages. Together the portal has about 800 keys that must be translated.
For this translation work the customer has specific department that works with appropriate tools. This tools can generate Liferay compliant property files.
Furthermore, by 800 key-words / translations, that is frequently necessary to change the translation.
Hence, I'm looking for method to update UI translations live - on the fly. Without redeploy of language-hook and without restart the Liferay.
If you're thinking of translating the content that you already enter to your portal, that's already changeable through the UI, no hook or anything necessary. However, as you mention hooks I believe that this is not what you're looking for.
Redeploy of a language hook is the simple option to update the application's language (i.e. Liferay's own UI). You can hot-deploy a language hook without restarting the server. All the other solutions I can think of are at least an order of magnitude more complex and would involve program code that overrides the mechanics how Liferay looks up translated UI elements.
IMHO you can choose either one, "simple" or "no redeploy of a hook". You can't eat your cake and have it, too.
Update (after your update): What I described above is Liferay's mechanism, which you're free to use or to ignore. If your plugins have specific needs that their translation must be updated without the plugins being updated at all, you're free to choose any different language lookup mechanism of your choice. The Liferay mechanism - in this case - might not be what you need to use. Or you'll need to talk to your business users and get their information on how often they believe that the translation will be required to update when the plugins stay unchanged. Or how often they are prepared to redeploy the plugins (and if they can wait for this amount of time)
Does CouchDB allow you to call an external web service from within the definition of your view? I basically want to resolve a woeid (where on earth id) using Yahoo's API's and update a view accordingly.
No, you cannot. The reason is that view indexes need to be completely self-contained. Using any external source would require the view index to be recalculated upon every change of that external resource. (not even to mention that CouchDB has no way of knowing when an external change has occurred.)
For this same reason, you cannot use CommonJS modules in your map/reduce (view) functions, as the server would have no way of knowing what changes to any CommonJS modules (in any design document) would have any effect on a given view. The only solution would be to update the view every time a change is made to any design document, which nobody would ever want.
I would recommend you look into GeoCouch for utilizing positioning in your project.
What is the general feeling amongst developers regarding the changing of files in the 12 hive.
For example if you were asked to remove the sign is a different user menu item, you would need to modify the relevent user control on the filesystem. Now if you just go and modify it via notepad or copy over and then if you go and bring a new server into the farm you will need to remember to do the same on the new server.
Obvouisly you could deploy the changed file as a solution and have that done automatically, but I'm just wondering if people are hesitant to make changes to the default installed files?
I have done a bit of SharePoint development, and I must tell you that messing with the 12-hive is a ticket to a world of pain if you ever want to move the app.
I'd rather hack up some javascript to hide it, at least that can be bound to the master page, which is much more portable.
And remember, you never know when the next service pack comes around and nukes your changes :)
I agree with Lars. Sometimes you will not be able to avoid it, depending on your needs. But, in general the best policy is to avoid modification if at all possible.
I know that some of the other menu items in the current user menu (change login, my settings, etc) can be changed by removing permissions from the user. Under Users and Groups there is an option for permissions. I can't remember the exact setting (develop at work, not at home), but there are reasonable descriptions next to each of the 30+ permissions. Remove it and you start hiding menu options. No modifications to the 12-hive needed.
There is a very simple rule: if you want to keep official support from Microsoft, don't change any of the files in the 12 hive that are installed by SharePoint.
I've never encountered a situation where the only solution was to change such a file. For example if you want to change an out-of-the-box user control of SharePoint, you can do so by making use of the DelegateControl, and overriding it in a feature.
More info:
http://msdn.microsoft.com/en-us/library/ms463169.aspx
http://www.devx.com/enterprise/Article/36628
I know it's tempting to quickly change a file, and I have to admit sometimes I just do that on a DEV box, but don't go there on a production server!
Not sure if there is much use pitching in, as everyone else pretty much has it covered, but I would also say don't do it. As tempting as it is, its just impossible to know the full impact of that little change you have made.
From a support perspective you will make it difficult for Microsoft support (patches/hotfixes).
From a maintenance perspective you are also opening yourself up to long term costs.
Go the javascript route.
The way to go about it is to use a Sharepoint Solution (WSP) file.
To change the user control, create a new Sharepoint feature with the new functionality.
Include this feature in your solution.
Deploy the solution either using the stsadm command line, or through Central Site Admin.
This will then get automatically deployed to all the servers in your farm, and it avoids you overwriting anything default sharepoint files.
For more info, check out Sharepoint Nuts and Bolts blog on http://www.sharepointnutsandbolts.com/ which give an introduction to WSP and Sharepoint Features.
I've done this many times and I will speak from experience: Never ever touch the onet.xml files within the 12 hive under any circumstance. Any error that you make in there, and to make the CAML even more complex the file is largely whitespace sensitive, will have an impact on every part of SharePoint.
You should also consider that aside from the substantial risk to the installation, you may well be building in dependencies upon your changes that are then over-written in a future patch or service pack.
Most of the time, you can accomplish everything you want to using features and solution packages without modifying the files. However, there are a few (rather annoying) rare cases where your only option would be to modify a file on the system. I have used it for two particular cases so far. One was to add the PDF iFilter to the docicon.xml file, and the other was to add a theme to the themes.xml file. In both cases, it seemed to be the only way to achieve the goal. Still, we used a solution package to write those files out to all the servers in the farm.