I want to make a blackberry app installable over-the-air (OTA) by deploying it as an OSGi bundle. Any ideas on how to setup the OSGi bundle?
I believe I'll need a way to enable a directory listing at particular URL as well associate the mime type for two file types (*.cod, *.jad)
Any takers?
See Wireless Application Deployment to BlackBerry Smartphones for the details.
In the end I was able to figure it out.
Used the following:
For the most part I followed the steps laid out by Peter Friese (found here)
The tweaking required is as follows:
Tweak1:
In the HttpServiceTracker's addingService() method one needs to invoke:
httpService.registerResources("/blackberry", "/appfiles", new CustomResourceHttpContext());
instead of the servlet registration to map a URL to the location of your files.
Tweak2:
You'll need to create a folder called appfiles at the root of your eclipse project in which you place your blackberry binaries.
Tweak3:
You'll need to implement your own custom HttpContext class inside the HTTPServiceTracker to associate the required mime types
e.g
public String getMimeType(String name) {
if (name.endsWith(".jad")) {
return "text/vnd.sun.j2me.app-descriptor";
} else if (name.endsWith(".cod")) {
return "application/vnd.rim.cod";
} else {
return null;
}
}
Caveat: In order to install the app over the air you'll need to specify the jad file name as there is no support for a directory listing using this approach.
Related
I need to validate the user input from 2 TextBoxes first on client Side and later on server side. I createt a class called FieldVerifier in the shared package.
I have 2 Methods to validate IBAN and BIC with iban4j:
public static boolean isValidIban(String iban) {
try {
IbanUtil.validate(iban, IbanFormat.Default);
} catch (Exception exc) {
return false;
}
return true;
}
public static boolean isValidBic(String bic) {
try {
BicUtil.validate(bic);
} catch (Exception exc) {
return false;
}
return true;
}
But if I try to start the application I get following error:
Line 91: No source code is available for type org.iban4j.IbanUtil; did
you forget to inherit a required module?
Line 101: No source code is available for type org.iban4j.BicUtil; did you
forget to inherit a required module?
Line 91: No source code is available for type org.iban4j.IbanFormat; did you forget to inherit a required module?
What do I need to do to build this library to use it on client side?
You set the the Validator class inside shared directory. So, the code for the Validator itself can be used in client side, but the dependencies (iban4j) need to be compatible with GWT also to be included on client side.
To do what you want, you have 2 choices.
Add the code of iban4j directly in your shared directory - It means loose the link to the iban4j library
Transform the iban4j to a GWT module. ( this is done by adding in the iban4j jar the source code and a Iban4j.gwt.xml file) and include the module to your project - It means modify the current library or recompile it with your need
Just checked iban4j.
as wargre already mentioned, you have to do some work. iban4j can not be used with GWT without major changes.
You have to:
add a module descriptor to the lib
do some code changes (f.e.: String.format is not supported in GWT)
and the *.gwt.xml & the Java sources to the lib.
In this state the lib can not be used with GWT. There has to be done some major changes.
Update: I have ported iban4j to GWT: https://github.com/mvp4g/iban4g
Update 2:
iban4g has moved: https://github.com/NaluKit/iban4g and updated.
This new version will work with Java, GWT and J2CL!
I needed to override portalLDAPImporterImpl.java addUser() method to perform some action after a user is imported from LDAP and added to Liferay. I followed these steps (Eclipse Environment):
Created Ext plugin project name customLdap;
In docroot/WEB-INF/ext-impl/src I created a package name com.liferay.portal.security.ldap
There I create my CustomPortalLDAPImporterImpl.java class extending portalLDAPImporterImpl.java and override the method addUser
Code extract:
#Override
protected User addUser(long companyId, LDAPUser ldapUser, String password)
throws Exception {
if (_log.isDebugEnabled()) {
_log.debug("Adding user " + ldapUser.getEmailAddress());
}
boolean autoPassword = ldapUser.isAutoPassword();
if (!PropsValues.LDAP_IMPORT_USER_PASSWORD_ENABLED) {
autoPassword = PropsValues.LDAP_IMPORT_USER_PASSWORD_AUTOGENERATED
&& !PropsValues.AUTH_PIPELINE_ENABLE_LIFERAY_CHECK;
if (!autoPassword) {
String defaultPassword = PropsValues.LDAP_IMPORT_USER_PASSWORD_DEFAULT;
if (StringUtil.equalsIgnoreCase(defaultPassword,
_USER_PASSWORD_SCREEN_NAME)) {
defaultPassword = ldapUser.getScreenName();
}
password = defaultPassword;
}
}
Calendar birthdayCal = CalendarFactoryUtil.getCalendar();
birthdayCal.setTime(ldapUser.getBirthday());
int birthdayMonth = birthdayCal.get(Calendar.MONTH);
int birthdayDay = birthdayCal.get(Calendar.DAY_OF_MONTH);
int birthdayYear = birthdayCal.get(Calendar.YEAR);
User user = UserLocalServiceUtil.addUser(ldapUser.getCreatorUserId(),
companyId, autoPassword, password, password,
ldapUser.isAutoScreenName(), ldapUser.getScreenName(),
ldapUser.getEmailAddress(), 0, StringPool.BLANK,
ldapUser.getLocale(), ldapUser.getFirstName(),
ldapUser.getMiddleName(), ldapUser.getLastName(), 0, 0,
ldapUser.isMale(), birthdayMonth, birthdayDay, birthdayYear,
StringPool.BLANK, ldapUser.getGroupIds(),
ldapUser.getOrganizationIds(), ldapUser.getRoleIds(),
ldapUser.getUserGroupIds(), ldapUser.isSendEmail(),
ldapUser.getServiceContext());
_log.info("-----------------------------------------User||||Added----------------------------------------");
if (ldapUser.isUpdatePortrait()) {
byte[] portraitBytes = ldapUser.getPortraitBytes();
if (ArrayUtil.isNotEmpty(portraitBytes)) {
user = UserLocalServiceUtil.updatePortrait(user.getUserId(),
portraitBytes);
}
}
return user;
}
Created folder name META-INF in docroot/WEB-INF/ext-impl/src
In META-INF created a file named ext-spring.xml with the following code:
build and published my plugin
copied the customLdap-ext.war file from dist folder and pasted it in my Tomcat deploy folder
started my server the old configuration are loaded no log is printed while a new user is imported from ldap
Where am I going wrong in doing this?
Note: I am using liferay 6.2.0.1 CE-GA6
I have also overriden PortalLDAPImporterImpl.java. You don't have to define ext-spring.xml. Just take the original class, copy it to docroot/WEB-INF/ext-impl/src in package com.liferay.portal.security.ldap and change it. Do not create CustomPortalLDAPImporterImpl.java
Something in your description doesn't sound right - specifically the combination of an ext-plugin and
build and pusblished my plugin
copied the customLdap-ext.war file from dist folder and pasted it in my tomcat delpoy folder
While this is documented as the steps to deploy in production, you'll at least need to restart Liferay (ext is not hot-deployable).
Also, validate that the WAR file doesn't end up as a separate webapplication in tomcat. Instead it will be woven into Liferay, aka the ROOT web application. This is another thing that you can/should validate. And observe the documented steps for redeployment (different from first deployment), where you basically need to reinstall Liferay from scratch and your ext plugins.
I haven't validated if you can go without ext here, the documented steps are a prime reason to try to go without ext whenever possible.
If you follow Klimiuk's advice in the other answer to this question, note that you're depending on classloader order in that case: Some JVMs/appservers will pick up your implementation first, while others pick up the original one first. It's typically reproducible - e.g. if it works once, it'll always work. At least until an update to your environment changes the behavior any you suddenly wonder why your modification doesn't work any more (if you're lucky to find out quickly).
I'm trying to get a list of all deployed applications, and specifically the name of the application mapped to tomcat root.
I want to be able to do it during runtime, using a java agent that collects information on the tomcat server.
I tried using this code sample:
private Iterable<String> collectAllDeployedApps() {
try {
final Set<String> result = new HashSet<>();
final Set<ObjectName> instances = findServer()
.queryNames(new ObjectName("Tomcat:j2eeType=WebModule,*"), null);
for (ObjectName each : instances) {
result.add(substringAfterLast(each.getKeyProperty("name"), "/")); //it will be in format like //localhost/appname
}
return result;
} catch (MalformedObjectNameException e) {
//handle
}
}
taken from a similar question but since I'm not logged into the manager app, I don't have the right permissions, so I get an empty list.
What I actually want - I have a java agent (based on aspectJ), and I'd like during runtime/deployment time etc. to be able to get the list of all deployed apps without actually logging in to the manager myself.
How can I do this? I don't mind instrumenting tomcat's deployment code (which doesn't require any login from my side as I'm already instrumenting the code), but I'm not sure which function to instrument.
Thanks,
Lin
The question consists of 2 parts:
Get a list of all deployed applications - After reviewing Tomcat's API, I found several relevant deployment code parts which can be instrumented:
WarWatcher.java (allows to detect changes), and we can also see the apps from - UserConfig.java which is called on startup (instrumentation can be done on setDirectory name etc.), and of course HostConfig.java that is called on stratup:
protected void org.apache.catalina.startup.HostConfig.deployWARs(java.io.File, java.lang.String[])
protected void org.apache.catalina.startup.HostConfig.deployApps()
protected void org.apache.catalina.startup.HostConfig.deployWAR(org.apache.catalina.util.ContextName, java.io.File)
In addition - you can check the argument for:
protected boolean org.apache.catalina.startup.HostConfig.deploymentExists(java.lang.String)
It includes the war/folder name (which usually means the application name+-).
Get the root application name - This can be done by using ServletContext.getRealPath() - It returns the folder name, from which the war name can be extracted (and can be used, in my case at least as the app name).
I am currently migrating an Eclipse 3.0 application to 4.4. The user data was and still should be stored in the folder C:\Users\username\AppData\Roaming\applicationname
The application is using following code to read the directory:
public static String getUserDirectory()
{
String directory = InternalPlatform.getDefault().getUserLocation().getFile();
return directory;
}
I know the code is deprecated, but following code returns the same:
public static String getUserDirectory()
{
String directory = Platform.getUserLocation().getURL().getFile();
return directory;
}
They both return C:\Users\username\user but as I said the user data should be stored at C:\Users\username\AppData\Roaming\applicationname. Did the behaviour of those methods change?
How can I realize that I store my user data under C:\Users\username\AppData\Roaming\applicationname and my application can still find the directory?
I know this has to do something with environment-variables which I don't fully understand.
I don't have a 3.x target platform at hand to compare but C:\Users\username\user looks plain wrong.
If you are interested in the details, the constructor of EquinoxLocations computes the userLocation and adds the literal 'user' the the user's home directory if no default is specified.
Hence, if you start your application with -user #user.home or -Dosgi.user.area=#user.home, the user location will be set to C:\Users\username\. Still not what you are looking for, but at least a sane value.
I think this is a bug in Equinox and recommend to file a bugzilla. If it turns out that there is a good reason for this appraoch the bug entry will still serve as documentation/reasoning.
In the meanwhile you could obtain the home directory on Windows through System.getenv( "APPDATA" ). According to this post it will return the roaming home directory.
I solved the problem by adding three properties in the Configuration tab of my config.ini.product-file:
osgi.configuration.area =
#user.home/AppData/Roaming/ApplicationName/...
osgi.user.area =
#user.home/AppData/Roaming/ApplicationName/...
osgi.instance.area =
#user.home/AppData/Roaming/ApplicationName
Now my method as stated in my question reads the paths that are configured by those properties and the config.ini file which is generated looks exactly like the one of the old build with Eclipse 3.0.
I'm trying to use the libre office mail merge functionality automatically from an java application.
I have tried to install the libreoffice sdk but without success because they require software that is not available anymore (e.g. zip-tools). Anyway I was able to get the jar files (jurtl-3.2.1.jar, ridl-3.2.1.jar, unoil-3.2.1.jar and juh-3.2.1.jar) from the maven repository.
With this jar files I was able to reproduce a lot of examples which are provided here http://api.libreoffice.org/examples/examples.html#Java_examples
Also in the LibreOffice API documentation a service named 'MailMerge' is listed (see here http://api.libreoffice.org/docs/idl/ref/servicecom_1_1sun_1_1star_1_1text_1_1MailMerge.html)
But in none of the jar's this service class is available, the only instance available for me is MailMergeType.
I'm able to open an *.odt templatefile within my javacode and the next step would be to create an instance of the mail merge service and pass a *.csv datasourcefile to the mail merge service.
At the API documentation some functions are listed which could help me but as I said before I'm not able to get access to this service class because its simply not exist in the provided jar files.
Do anybody know how I can get access to the mail merge service for libreoffice?
If you need more information about my environment just ask.
Sincerly
Looking at this code from 2004, apparently you can simply use Java's Object class. Here are a few snippets from that code:
Object mmservice = null;
try {
// Create an instance of the MailMerge service
mmservice = mxMCF.createInstanceWithContext(
"com.sun.star.text.MailMerge", mxComponentContext);
}
// Get the XPropertySet interface of the mmservice object
XPropertySet oObjProps = (XPropertySet)
UnoRuntime.queryInterface(XPropertySet.class, mmservice);
try {
// Set up the properties for the MailMerge command
oObjProps.setPropertyValue("DataSourceName", mDataSourceName);
}
// Get XJob interface from MailMerge service and call execute on it
XJob job = (XJob) UnoRuntime.queryInterface(XJob.class, mmservice);
try {
job.execute(new NamedValue[0]);
}
See also How to do a simple mail merge in OpenOffice.
Regarding a source for the old zip tools, try zip.exe from http://www.willus.com/archive/zip64/.