We Keep Coding

Read external Files with GlassFish / Vaadin?

I would like to make .txt-files accessible for my VaadinApp on a GlassfishServer.
Lets say I have a .txt-file, its content is 12345.
Now, when I click a button on my Vaadin StartPage, I would like to show the Data that has been written into this .txt-file.
I know how Java Input/Output is working but I have no clue how to make those files accessible for my VaadinApplication running on Glassfish 4.1.2.
Is there a folder I can put the .txt-file in, or how would I access the file?
Thanks

There is component named Label is available in Vaadin.
So that, the values which needs to be shown on the screen can be set as a caption/value for that object.
This can be done either through constructor or setter in that object.We will set the value through the setter as we need to display the value, once the button is clicked. That can be done like this.
Label sampleLabel = new Label();
sampleLabel.setContentMode(com.vaadin.shared.ui.ContentMode.HTML);
Now we will see how this can be added to the label, when a button is clicked.
Button sampleButton = new Button("Click");
sampleButton.addClickListener(event -> sampleLabel.setValue(<call the method that reads data from the text file>));
I hope this will be helpful.
Note: Basically you can place the file anywhere in the system.
But most preferred way.
If you are using maven to build the project, place the files in the resource folder.(src/main/resources)

Hiding and showing Eclipse view programmatically

I am showing and hiding Eclipse view with code below. It works perfectly with Eclipse 3.3, but with Eclipse Juno (version 4.3) it's not showing the first time but showing when I fire the event for the second time.
IWorkbenchPage page = PlatformUI.getWorkbench().getActiveWorkbenchWindow()
.getActivePage();
page.showView(UserView.ID);
page.hideView(page.findView(UserView.ID));
Is somebody come across with this situation before?

I am not sure why you are not getting it the first time. Check to see if you dont have null pointer errors when you fire it the first time.
PlatformUI.getWorkbench().getActiveWorkbenchWindow().getActivePage()
can return a null if the workbench is not yet loaded.

I faced the same issue with the minimized state, so I tried chaging the view's state forcing it to appear after page.showView(UserView.ID);
this piece of code got my viewPart to show :
page.showView(UserView.ID);
IWorkbenchPartReference ref = page.getReference(searchResultUI);
page.setPartState(ref,IWorkbenchPage.STATE_RESTORED); //or STATE_MAXIMIZED

Text duplication

I am working on simple text editor and on main panel, I have JList with currently opened files (CDocument class) and active document, which contents is shown (also CDocument class). I store opened files (CDocument objects) in vector and on the right side the active document is shown.
Now, at program start, there is no active document and opened document list is empty. After I click File->New, I create new, empty object from class CDocument. If I enter something into active document area (the red region on screenshot) and then I reclick File->New, I get new, empty (with no text - I've doublechecked with ) CDocument object. But, the text from previous active document still shows into newly created (red region - newly empty CDocument). I am busting my brain here because I do not know why?! Here is File->New code chunck:
`
if(e.getSource()==this.menuItemFileNew())
{
CDocument currentDocument=new CDocument();
if(this.panelMain().documentActive()!=null)
{
this.panelMain().remove(this.panelMain().documentActive());
}
this.panelMain().openedDocuments().add(currentDocument);
this.panelMain().setDocumentActive(currentDocument);
this.panelMain().add(panelMain().documentActive().pane(),
BorderLayout.CENTER);
this.panelMain().documentActive().addKeyListener(this);
this.panelMain().documentActive().requestFocus();
this.menuItemFileSave().setEnabled(true);
this.menuItemFileSaveAs().setEnabled(true);
this.menuItemFileClose().setEnabled(true);
this.menuItemFileCloseAll().setEnabled(true);
this.toolBarFileSwitcher().panelActiveDocumentInfo().
panelFileSizeInfo().updatePanel(this.panelMain().documentActive().getText().length(),
false);
this.toolBarFileSwitcher().listOpenedFiles().model().addElement(currentDocument.filename());
this.toolBarFileSwitcher().listOpenedFiles().setSelectedIndex(this.toolBarFileSwitcher().listOpenedFiles().model().size()-1);
this.toolBarFileSwitcher().setVisible(true);
}
`
Why is text shown, I've tried updateUI, repaint, nothing works!

Use Action to encapsulate functionality related to your CDocument data type. This will help ensure that all invocations are consistent. This example manages images, while this example illustrates a menu of files.

How to force update of view titles after having changed the locale and restarted?

In a RCP application, I change the locale by programatically setting it in the .ini file and restarting the application.
The problem is that view titles, which are defined in OSGI-INF/l10n files referred from the plugin.xml file, aren't updated until I focus them.
For example after having switched from EN to FR, I have this :
It's only after I click on the second tab that I get this :
I can't reset the perspectives as they may have been changed by the user (view resized, removed or added). I've set configurer.setSaveAndRestore(true); in my WorkbenchAdvisor.initialize method to ensure the views layout is restored at launch.
Is there a way to programatically force an update of the views titles without losing the perspective configuration ?
I precise that I can't use the new Eclipse 4 (Juno) API.

As you are restoring perspective from previous session, it might be remembering part titles.
By default ViewPart doesnt do anything in saveMemento() method.
Override below methods are to debug the issue
public void init(IViewSite site, IMemento memento) throws PartInitException
String getPartName()

Setting a navigation rules in a returnListener from a Dialog doesn't work in ADF 10g (JSF faces 1.1)

I've a confirmation dialog created using the dialog framework. The dialog is opened by a command link and the value selected in tg is returned to a return listener. This is my command link.
<af:commandLink id="btnSalva" shortDesc="Salva"
binding="#{segnaPrzzDep.btnSalva}"
partialSubmit="true" immediate="true"
windowHeight="250"
windowWidth="350"
useWindow="true"
action="#{segnaPrzzDep.aclSalvaSegnaPrezzoDep}"
returnListener="#{segnaPrzzDep.rtlSalvaSegnaPrezzoDep}"
styleClass="btnSalva"/>
In the return listener i try to set a navigation rule, but nothing happens. I do it like this (the return handler does only this):
FacesContext fc = FacesContext.getCurrentInstance();
NavigationHandler nh = fc.getApplication().getNavigationHandler();
nh.handleNavigation(fc, "", "archivio");
The starnge thing is that if i use the dialog framework but withouth opening the window everything is ok. I f i set-up the command link like this:
<af:commandLink id="btnSalva" shortDesc="Salva"
binding="#{segnaPrzzDep.btnSalva}"
partialSubmit="true" immediate="true"
action="#{segnaPrzzDep.aclSalvaSegnaPrezzoDep}"
returnListener="#{segnaPrzzDep.rtlSalvaSegnaPrezzoDep}"
styleClass="btnSalva"/>
Everything works correctly. I'm using jDev 10.3.1.4 and the same version of ADF.

I have been just writing a very similar question, then i noticed that you have already post it.
I guess that the root cause will be the same in both our cases even that I am using the trinidad lib not ADF. The trinidad lib was actually a fork from ADF so they share quite a lot of code.
In my case, we have migrated from trinidad 1.0.7 to trinidad 1.0.10 (due to this problem).
Because of this upgrade the "commandButton" tag in our jsp files defined as
<tr:commandButton ... returnListener="bean.listenerMethod" ... useWindow="true" />
stops calling the bean.listenerMethod when the dialog where this button is present is closed.
Setting useWindow="false" causes the bean.listenerMethod to be called again.
Before the upgrade, the mentioned commandButton worked well in both cases (useWindow="true"/"false").
So as you can see the symptoms are very similar.
Now for the findings that i have made when analysing this issue.
By checking the logs I observed that the LifeCycleImpl class did not invoke all of the phases when returning back to the main page (after closing the dialog).
So 1) the post on the dialog was processed, which means all phases were processed and 2) the main page was called afterwards, but this time the very first phase "restore view" was just processed and then jumped directly to "render response" phase calling the main page without invoking the bean.listenerMethod.
When checking the same logs on trinidad 1.0.7 all of the phases where called also in step 2).
I have debugged the sources of trinindad 1.0.10 and tracked this difference to be caused by this "bug".
The problem here is that the UIViewRoot is being removed from session. When then calling close on the dialog, the "restore view" phase during (described above) step 2) can not find the UIVIewRoot of the main page.
When this happen, LifeCycleImpl decides to skipp directly to the "render phase" since it is probably expecting that due to missing UIViewRoot in the session this is the first call to the page (view) and so it just reloads the main page.
I am quite new to JSF but to me this looks like a bug.
In my case there is quite a high pressure on me to fix this problem somehow, so lets see what i will be able to do with this.

I have posted a new bug to https://issues.apache.org/jira/browse/TRINIDAD-2171.
I have find a workaround for this problem. In my project I created a class and a package
as org/apache/myfaces/trinidadinternal/application/StateManagerImpl.java.
To this class i have copied everything from corresponding class in trinidad lib. Then i
have commented out changes done due to fix in https://issues.apache.org/jira/browse/TRINIDAD-1193.
Finally I make sure that my class gets loaded first before the one from trinidad lib (in tomcat this was done by coping the class to WEB_INF\classes dir, since this dir is called as first one when loading classes, i.e. before loading WEB-INF\libs where trinidad lib are placed).