Fullstack | Java | Tech Speaker | Tech Coach | Frank van der Linden
Lately I noticed the increasing demand of Salesforce developers in The Netherlands and I like to explore new technologies.
So I was looking for a way to start learning Salesforce, Rene Winkelmeyer, pointed me to Trailhead.
I can confirm it is very refreshing way to learn a new platform, there a variaty of trails, Admins or Developers. You can earn batches if you complete a module.
Over the last months we build the HR Assistant for the ICS World Wide Development Competition.
The backend of the code is totally written in Java. The XPages and custom controls only serves the data to the browser, nothing more.
We have all the Java classes in the application as Java Design Elements, which give you, like any other Domino Designer Element, an metadata file. I noticed that the runtime is mirroring the java files to a java directory under the WebContent –> WEB-INF, which went sometimes gone wrong in 8.5.x
This metadata files was causing the most annoying conflicts when using GIT during the development, as we developed everything on our local machine and the GIT repository the linking factor.
Today I was looking about moving the Java files to the correct location. For the development we had a debug application with a subset of the classes to test the connectivity with Cloudant.
So I found it a good candidate to do the move first.
Note: below everything happens in the Package Explorer ( found under Menu bar –> Window –> Show Eclipse Views
Step 1: Create in the NSF under WebContent –> WEB-INF a folder, called ‘java’
And make it as source folder, by right clicking on the folder
Step 2: Move the Java files
Locate the Code/Java folder, keep in mind it is not under Code as displayed in the Applications view
And copy and paste them in the new source folder
Remove the files under Code/Java.
Build the application and everything should work as before the move.
A big benefit it is there is much less metadata files which can causing conflicts when using Source Control. Another benefit is that you remove the tight integration of the Domino Designer and you can also move the Java files to a OSGi plugin to make it more flexible.
BTW, In my opinion you should get used to the Package Explorer, as you do Java development, so no pretty panes. In the JEE world where they use the plain Eclipse everything happens in the Package Explorer
Last Friday during the closing session of Icon UK in London Inhi Suh announced, with a little help of Alan Hamilton, the results of the ICS Developer competition 2016. To my big surprise our submission, HR Assistant was selected as winner. Frédéric, my partner in crime in this competition was also very surprised a few timezones to the east from us.
Frédéric Dehédin from the Swiss IBM Business Partner Belsoft Collaboration and I formed a team, Fred & Frank, to build this application.
HR Assistant is an application which can help the HR employee to screen and analyse Job Applications, with the help of several IBM Watson services, like the Tone Analyser, Personality Insight and Alchemy Language.
The analysis results are displayed in charts and stored in Cloudant database.
See it in action on IBM Bluemix, hrassistant.eu-gb.mybluemix.net
HR dashboard
[dropshadowbox align=”none” effect=”lifted-both” width=”auto” height=”” background_color=”#ffffff” border_width=”1″ border_color=”#dddddd” ]
[/dropshadowbox]
Job applicant dashboard
[dropshadowbox align=”none” effect=”lifted-both” width=”auto” height=”” background_color=”#ffffff” border_width=”1″ border_color=”#dddddd” ]
[/dropshadowbox]
Job application with Alchemy Language keywords
[dropshadowbox align=”none” effect=”lifted-both” width=”auto” height=”” background_color=”#ffffff” border_width=”1″ border_color=”#dddddd” ]
[/dropshadowbox]
Expect in the near future more technical blog posts about the application.
BTW, a big shout out to my former employer which one of the runners up with their application Join. Well done…
Today it is 2 years ago that I started my own business as a Freelance developer and I must say I enjoy it every day.
The past year I was helping out Belsoft with Application Development projects for their customers, but most of the time I was doing projects in the JEE world, working with Spring Framework (MVC, Security, Webflow), Hibernate, JPA, Maven and Jenkins.
Let’s make it a another successful year.
I will be speaking, again, at IconUK in September in London
During my holiday I already received an notification that one of my abstracts was accepted. Till last week I didn’t know which session was accepted, but now I know 😉
[dropshadowbox align=”none” effect=”lifted-both” width=”auto” height=”” background_color=”#ffffff” border_width=”1″ border_color=”#dddddd” ]
Servlets made easy. Write once and run everywhere.
Since a few years the Domino server is a real Java server. Which give you plenty of new opportunities, such as real servlets. Get and post data to any database via a Java servlet. Develop once, run everywhere. In this session you will learn what are servlets, how to create a servlet as OSGi plugin. Make use of other plugins projects or third party projects and. Run the servlet on a Domino server and other Java servers, like Websphere Liberty Profile, Tomcat and Wildfly. Last but not least, how to deploy the servlet as OSGi plugin or as jar file or update site to the Domino server.[/dropshadowbox]
Hope to see you in London, register till it is too late
Lately I had pulled a new project to work on, a XPages application with a few external jar files.
When I tried to build the application it produced a lot of errors. The most annoying error was that classes could not found, and these classes are inside the external jar.
Mmmm… strange.
When I looked inside the application view in the Domino Designer I found the external Jars in the Jars section under code as Jar design element.
In the build path there was a reference to these external jars, but the path was changed to WebContent/WEB-INF/lib/external.jar.
Real strange…….
In the package explorer the lib directory under WebContent/WEB-INF was present but empty.
So the Domino Designer magically moves the external jar files under the hood to the correct location. Nice but it gave me a very strange feeling and lots of errors, because it could go wrong.
I have removed all the references of the external jar file from the build path. Moved all the external jars in the Package Explorer from the jars section to the correct location, WebContent/WEB-INF/lib/. That location is the correct place where a Java server is looking for external jars, anyway so why not put them there immediately.
Build the application and gone where all the errors.
As I move more and more over to the J2EE world I get used to the real Eclipse and his perspectives and views. I ‘live’ in the package explorer and have not the luxury of an Application view with design elements. In Domino Designer I hardly use the Application view, everything I do on XPages development I do in the Package Explorer. More what you is what you get 😉
If you want to look around to other technologies and Java/J2Eee/Vaadin is your choice, get use to the Package Explorer and abandon the use of the Application View.
The same apply of the Java classes as for the jar files, put them directly on the right location in a directory under WebContent/WEB-INF/ and make this directory a source folder.
Today I made a few changes to the Cloudant connnector and Jackson4XPages plugin.
I added a new constructor of the JacksonWrapper, a boolean, to control the date format output in the JSON.
JacksonWrapper wrapper = new JacksonWrapper(datesAsTimeStamps);
By default it is true, so the output format is a Timestamp, but if you need a real date, pass false to the contructor
I committed the changes to the repository and updated the ReadMe.
I added a new connector to the plugin, the QueryConnector. In this new part there is the possibillity to actual search the Cloudant database. And have access to the indices.
//search the database List<?> connector.getQueryConnector().search(final String searchIndexId, final Class<?> cls, final Integer queryLimit, final String query) //To learn about the query syntax see, https://docs.cloudant.com/search.html //To get all the indices List<?> allIndices(); //To find documents using an index List<?> findByIndex(final String selectorJson, final Class<?> cls)
I committed the changes to the repository and updated the ReadMe.
Last week I have posted a demo database of my way to add multi language to a XPages application.
Today Patrick Kwinten pinged me on Slack about an 500 error he was hitting when he access the database from the browser.
After some investigation via Slack it the cause of the error was an external jar file which was in still, unused, in the database. The external jar was on the Build Path, but after removing from the Build Path it was still crashing. On stackoverflow I found the answer.
The external library was causing an reflection exception. There was no need for this external library, so no need to update the java policy file.
After removing the external jars completly from the database, the application was up and running again. Everyone happy 😉
I made the update to my demo database and commited to the Bitbucket repository of this demo.
I also noticed that it is not common or the normal way, when using Java in DDE to store the Java classes in a Java directory which I created under WebContent –> WEB-INF and add the directory as source folder.
In my life outside the DDE/Domino world when building Java applications in vanilla Eclipse environments, it is the normal way, so I still use it in DDE. So for Java development I live in the Package Explorer.
To find the Package Explorer. Goto Window –> Eclipse Views –> Packagage
So I encourage everyone when do Java development in an XPages, to use the Package Explorer and the Java classes in a folder under WebContent –> WEB-INF ( next make them a source folder ). When moving to other grounds, outside the Yellow bubble or doing more and more OSGi plugin development, it makes your life easier.
Over time I wrote a few blogs about my way to support multi language in a XPages app.
Very nice, but I got requests about a demo db.
I created a demo database which is available as GIT repository on Bitbucket.
Happy coding