LPS-32743 Modify the required filters in order to support the new kind of applications we are deploying into the OSGi container
LPS-32743 This new servlet is responsible of the handling for the requests directed to an application deployed into the OSGi container. It is important to note that this servlet needs to work through the module framework adapter in order to solve the classloading issues we can suffer in some application servers running a different OSGI container in the same JVM instance
LPS-32743 Some constants required for the module framework. Some of them are not used right now but they will be used in the next modules I will push shortly
LPS-32742 Setup the IDE files to include the new OSGi Http Service impl
LPS-32742 Ability to compile and deploy the module. Basic bnd file in order to create a valid MANIFEST.MF file in the generated bundle
LPS-32742 Basic model definitions for filters, listeners and servlets
LPS-32742 Why did we change it from catching an Exception to catching a SystemException?
LPS-32742 Move "compile" logic out of http-service/build.xml since all other modules will follow this pattern. Make log-bridge/build.xml's "compile" smarter to call the one from build-common-java, so this commit does not change behavior but will save the amount of duplicate code later
LPS-32742 We have project.classpath, plugin.classpath, etc... so this.classpath is not descriptive. Renaming it to module.classpath.
LPS-32742 Sort
LPS-32742 In the constructor we sort by the constructor parameters, down at the bottom of the class we sort alphabetically
LPS-32742 Simplify
LPS-32742 consolidate logic so if we ever need /o/ with the context path, we don't have to do this again. And, it's consistent with PortalUtil.getPath*
LPS-32742 The way the constants file are set up still confuse me. So, I'm trying to break them up into something that logically makes more sense -> FrameworkPropsKeys -> they are keys for java.util.Properties for the Framework object. ServicePropsKeys -> they are keys for java.util.Properties when making a Service object. It's hard for me to understand / comprehend where the additional constants should go without seeing the final class where they are used. So when making a small commit, the best thing is to NOT include unused constants. It pollutes the pull. I've simplified it, and will expect a pull where the additional servlet constants are used (who knows, may be we will just put those contants in that servlet). Thanks Miguel! This is cool stuff :)
LPS-32782 LPS-32908 Cannot create users. When you create a new user, organizationsId in UserServiceImpl.updateUser(...) is not null but empty array so when UserServiceImpl.checkOrganizations(...) is called user doesn't exist so and user.getUserId(userId) throws an Exception
LPS-32782 LPS-32908 the other associations may also be enabled by configuration
LPS-32782 LPS-32908 Technically, CompanyConstants.SYSTEM is equal to 0, but the method is expecting a userId, so chagne it to a manual 0 so we don't think we're passing in a companyId
LPS-32782 LPS-32908 Never check for isMembershipAllowed if user is null
LPS-32782 LPS-32908 Consistency (and prevent null)
LPS-32830 javascript variable should be eventName