ApisupportEnterprise69

Contents

Dependency Injection Frameworks like Spring, Guice,...

The major issue is classloading and making it work in modular environment. Less important is bridging the framework and the netbeans way of registering stuff.

Possible Options:

  • Use context classloader to find components and all..
  • Use only the module dependency tree (module' classloader)
  • Registration based (layers) which will expand/shrink the context based on installed modules. Can have multiple contexts at once?
  • Use OSGI module systems and reuse existing solutions

Some writeup by users: nb platform with spring spring and lookup

How it's done in OSGI spring dynamic modules

why spring dynamic modules?

Web (REST) Services

  • Most of the popular (REST) services require authentication. Currently WS Manager approach is very uncomfortable. We need some (per user) centralized approach where user may register his private API keys, and other stuff, to access those services. The excellent sample of this approach was Zembly API Key Manager capability.
  • Currently there is already a way to register REST service in IDE from WADL file. It's not obvious from UI that this is even possible. (The UI should be improved). Moreover, it should be possible to:
    • generate wadl file from project
    • register REST application even before deployment


  • PetrJiricka: it would be useful to have a "Test Case" scenario described for REST services, similarly to what David did below for AppClient. This would help us figure out the whole development cycle.
  • PetrJiricka: it would be useful discuss how the REST client libraries will be injected to the user's target platform, so the necessary runtime part is present.

Test case

Create Web project and some REST services (one or more REST applications). Register REST application in Web Services tab.
Then: create Netbeans module in Netbeans platform. Generate REST client for the REST service (REST application) previously registered in Web Services tab.

See also: Rest Usecases

AppClient

Application Client is standard J2SE app which is deployed to client from an application server and which can access (or is injected with) server managed resource. Next paragraphs look at definition of app client, potential problems it creates for NB RCP based app and simple test case.

Background

Some relevant background bits on AppClient as defined in chapter EE.10 in Java EE 6 spec:

Application clients are first tier client programs that execute in their own Java™ virtual machines. Application clients follow the model for Java technology-based applications: they are invoked at their main method and run until the virtual machine is terminated. However, like other Java EE application components, application clients depend on a container to provide system services. The application client container may be very light-weight compared to other Java EE containers, providing only the security and deployment services.

As with all Java EE components, application clients use JNDI to look up enterprise beans, get access to resource managers, reference configurable parameters set at deployment time, and so on. Application clients use the java: JNDI namespace to access these items.

Injection is also supported for the application client main class. Because the application client container does not create instances of the application client main class, but merely loads the class and invokes the static main method, injection into the application client class uses static fields and methods, unlike other Java EE components. Injection occurs before the main method is called.

Application clients have all the facilities of the JavaTM Platform, Standard Edition (subject to security restrictions), as well as various standard extensions. Each application client executes in its own Java virtual machine. Application clients start execution at the main method of the class specified in the Main-Class attribute in the manifest file of the application client’s JAR file (although note that application client container code will typically execute before the application client itself, in order to prepare the environment of the container, install a SecurityManager, initialize the name service client library, and so on).

The tool used to deploy an application client to the client machine, and the mechanism used to install the application client, is not specified.

How an application client is invoked by an end user is unspecified. Typically a Java EE Product Provider will provide an application launcher that integrates with the application client machine’s native operating system, but the level of such integration is unspecified.

RCP based app client

In order to run NetBeans RCP based application as AppClient several things needs to be explored/evaluated (in no particular order):

  • is it worth to provide this feature at all? That is do we want to allow and support running NB RCP app as AppClient? Evaluation should assess how easy/difficult it is to provide this feature and how many potential users of this feature there are. It is possible that it is too expensive feature for too few people.
  • app client application launcher is product specific and unspecified by the spec. That means that different solutions may need to be provided for different servers.
  • injection of Container managed beans to application client's main class
  • JNDI lookup of Container managed objects from application client
  • it must be possible to add 'NetBeans based RCP application' to NetBeans EAR project. There is a set of NetBeans J2EE APIs which describe J2EE Module of AppClient type. Project type implementing this API then can be added to EAR project and EAR project will take care about deployment of project build artifacts to an app server.
  • possible more items; TBD

Test case

Create Ear project with EJB project. In EJB project create some JPA entities from database and generated for these entities Session Stateless EJBs. Create NetBeans module project which uses previously created EJBs to retrieve data and show them in UI. Create NetBeans Platform Application(????)(NPA) and add it to the Ear project and add to it the NB module. NPA should (somehow) pass injected EJBs to the NB module. Deploy Ear to GlassFish and using WebStart start the app from GlassFish server and validate that data from EJBs/DB are correctly shown in the NB RCP based app.

  • PetrJiricka: sounds like the base use case is to get the data from database to the RCP application and back, but the question is whether the appclient is the most requested way to accomplish this, and whether there are other ways to do this (e.g. via REST services) which should be higher on the priority list. What are the concrete requests for appclient usage that we have from the users?
Not logged in. Log in, Register

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo