vaadin / cdi Goto Github PK

View Code? Open in Web Editor NEW

41.0 22.0 56.0 1.69 MB

CDI Integration for Vaadin

License: Apache License 2.0

Java 98.29% JavaScript 1.71%

jave javaee jakartaee cdi vaadin webapp

cdi's Introduction

Vaadin CDI

This is the official CDI integration for Vaadin Flow.

This branch is compatible with upcoming Vaadin platform versions. See other branches for other Vaadin versions:

15.0 for Vaadin 24
14.1 for Vaadin 23.3
13.1 for Vaadin 22.1
11.3 for Vaadin 14.10
10.0 for Vaadin 10
3.0 for Vaadin 8.2+
2.0 for Vaadin Framework 8.0...8.1 versions
1.0 for Vaadin Framework 7 versions

Using with Vaadin 10

To use CDI with Vaadin 10, you need to add the following dependency to your pom.xml:

<dependency>
  <groupdId>com.vaadin</groupId>
  <artifactId>vaadin-cdi</artifactId>
  <version>10.0.0.beta1</version> <!-- Or the LATEST version -->
</dependency>

Since the current release version is a prerelease, you need to also include the prerelease Maven repository:

<repositories>
  <repository>
    <id>Vaadin prereleases</id>
    <url>https://maven.vaadin.com/vaadin-prereleases</url>
  </repository>
</repositories>

Getting started

NOTE: This is still WIP. The easiest way for starting a project is to go to vaadin.com/start and select the Project Base with CDI to get an empty project with everything setup ready for you.

NOTE: This is still WIP. There is a tutorial also available in https://github.com/vaadin/flow-cdi-tutorial that helps you get started with Vaadin 10 and CDI.

Building the project

Execute mvn clean install -DskipTests in the root directory to build vaadin-cdi.

Run integration tests

Execute mvn -pl vaadin-cdi-itest -Ptomee verify in the root directory to run integration tests.

Test can be executed against the following containers, activating the specific profile:

Wildfly Jakarta EE 9: -Pwidfly
Wildfly Jakarta EE 10: -Pwidfly,jakartaee-10
OpenLiberty Jakarta EE 9: -Pliberty
OpenLiberty Jakarta EE 10: -Pliberty,jakartaee-10
Payara Jakarta EE 10: -Ppayara (Payara does not support Jakarta EE 9)
TomEE Jakarta EE 9: -Ptomee (TomEE does not yet support Jakarta EE 10)

Issue tracking

If you find an issue, please report it in the GitHub issue tracker.

Contributions

The contributing docs can be found here: https://vaadin.com/docs-beta/latest/guide/contributing/overview/

cdi's People

Contributors

Stargazers

Watchers

cdi's Issues

build fails ....

cloned the repo, ran mvn clean install:

[ERROR] Failed to execute goal org.codehaus.mojo:properties-maven-plugin:1.0-alpha-2:read-project-properties (default) on project vaadin-cdi: Execution default of goal org.codehaus.mojo:properties-maven-plugin:1.0-alpha-2:read-project-properties failed. NullPointerException -> [Help 1]

Use @RolesAllowed annotation instead of custom annotation parameter

Originally by @hesara

CDIViewProvider should use the standard @RolesAllowed annotation instead of a custom parameter to @CDIView.

Imported from https://dev.vaadin.com/ issue #11398

Migrate GitHub cdi tickets here and close GitHub cdi issues

Originally by @Artur-

Imported from https://dev.vaadin.com/ issue #11851

ContextDeployer throws cryptic exception if no @Root annotation is used.

You get an exception from this row if you haven't used the @root annotation anywhere

https://github.com/vaadin/vaadin-cdi-integration/blob/master/vaadin-cdi/src/main/java/com/vaadin/cdi/ContextDeployer.java#L165

Class<?> rootClass = beans.iterator().next().getBeanClass();

the iterator will be empty and the call to .next() will give you a NoSuchElementException. Handle the case where there is no @root specified.

Prefix public classes with CDI instead of Vaadin

Originally by @Artur-

When creating a Vaadin application it feels much more natural to use @CDIUI (CDI handles the UI) instead of @VaadinUI. The same for VaadinView -> CDIView. VaadinUIScoped should be simply @UIScoped to be consistent with other scope naming.

Imported from https://dev.vaadin.com/ issue #11214

Restructure the packages

Originally by @Artur-

Access control files should go into an access package, internal classes should go into an internal package.

Imported from https://dev.vaadin.com/ issue #11213

Disallow direct commits to repository

Originally by @Artur-

All commits should go through code review

Imported from https://dev.vaadin.com/ issue #11206

Add a test for validating component in component injection

Originally by @Artur-

Add a test or extend #11209 to contain component injection and also injection of a component inside an injected component

Imported from https://dev.vaadin.com/ issue #11212

"Ambiguous injectinon point" error with vaadin-cdi-integration and Seam Solder - Produces

JaasTools contains:

@produces
@RequestScoped
public static HttpServletRequest getCurrentRequest() {
HttpServletRequest request = VaadinServletService
.getCurrentServletRequest();
getLogger().info("Getting request " + request);

    return request;
}

The @produces allows the following, for instance:
@Inject HttpServletRequest request;

However, if any other part of the app (Seam Solder, in my case) also produces that, the app won't start (see Exception below). There's no way around it that I know of , without either changing the source of vaadin-cdi-integration or Seam Solder.

Is the @produces really needed here? (I don't see any @Inject usages). If it is deemed needed, perhaps it could be qualified? It would be nice to allow Seam Solder to be used along side vaadin-cdi, and Seam solder is not likely to remove it, I think...

Exceptions:
org.jboss.weld.exceptions.DeploymentException: WELD-001409 Ambiguous dependencies for type [HttpServletRequest] with qualifiers [@default] at injection point [[field] @Inject private org.jboss.solder.servlet.http.RequestParamProducer.request]. Possible dependencies [[Producer Method [HttpServletRequest] with qualifiers [@Any @default] declared as [[method] @produces @typed @RequestScoped protected org.jboss.solder.servlet.http.ImplicitHttpServletObjectsProducer.getHttpServletRequest()], Producer Method [HttpServletRequest] with qualifiers [@Any @default] declared as [[method] @produces @RequestScoped public static com.vaadin.cdi.component.JaasTools.getCurrentRequest()]]]

@Postconstruct not called

Originally by ronald.vermeire

In vaadin-cdi-example InjectableLayout initLayout() is not called when run with mvn tomee:run

When run with mvn jboss-as:run it gives a NullPointerException in InjectableLayout constructor. I could workaround this by adding @CDIUI to InjectableLayout.

Imported from https://dev.vaadin.com/ issue #11594

Empty view name should be valid

Normally with the Navigator, a user can have an empty view name for example for their login screen. This approach is shown in the Vaadin 7 wiki: https://vaadin.com/wiki/-/wiki/Main/Creating%20a%20bookmarkable%20application%20with%20back%20button%20support
Currently, you cannot have an empty view name with the CDI addon.

NPE With CDI Events

I had a NullPointerException when listening for Events with @observes(notifyObserver = Reception.IF_EXISTS)

Views supporting parameters currently have too heavy restrictions on their names

Let's say I have two views, with the following URLs:

/myapp/#!users - shows all the users
/myapp/#!user/123 - shows only the user with the ID 123

In this case, the view name of the first view would be users with no support for parameters and the view name of the second view would be user with support for parameters. However, currently Vaadin CDI would find both of the views when looking for the first view. This is because it looks for candidate views by checking if the URL fragment starts with the view name. In this case the fragment #!users starts with both user and users.

The code should be changed so that if view parameters are allowed, they are stripped from the fragment in some way and then the complete view name is used when looking for candidates.

java.lang.IllegalStateException: UI id has already been defined after VaadinSession.close

I've implemented a logout method according to the vaadin Book (4.7.7 Closing a Session).
The method redirects the browser to another page, and close the vaadin session.

    private void logout() {
        getPage().setLocation("/myapp/hello.html");
        getSession().close();
    }

After logout, while navigating back to my UI i get this Exception:

SEVERE: java.lang.IllegalStateException: UI id has already been defined
    at com.vaadin.ui.UI.doInit(UI.java:519)
    at com.vaadin.server.AbstractCommunicationManager.getBrowserDetailsUI(AbstractCommunicationManager.java:2468)
    at com.vaadin.server.AbstractCommunicationManager.handleBrowserDetailsRequest(AbstractCommunicationManager.java:2362)
    at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:325)
    at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:201)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)

My workaround is to close the underlying http session too.

getSession().getSession().invalidate();

This way UIScopedContext destroyed, and my UI can reload.

I think UIScopedContext should destroy automatically on VaadinSession.close.

Write basic CDI tutorial

Originally by @Artur-

How to get started with Eclipse
How to get started with Maven

Imported from https://dev.vaadin.com/ issue #11532

Closing the UI does not trigger @UIScope destruction

Originally by @Artur-

Using the following simple UI causes strange effects when invalidating the VaadinSession or HTTP session:

@CDIUI
public class CditestUI extends UI {

    @Override
    protected void init(VaadinRequest request) {
        final VerticalLayout layout = new VerticalLayout();
        layout.setMargin(true);
        setContent(layout);
        Button closeUI = new Button("Close UI");
        closeUI.addClickListener(new Button.ClickListener() {
            @Override
            public void buttonClick(ClickEvent event) {
                close();
            }
        });
        layout.addComponent(closeUI);

        Button closeSession = new Button("Close VaadinSession");
        closeSession.addClickListener(new Button.ClickListener() {
            @Override
            public void buttonClick(ClickEvent event) {
                getSession().close();
            }
        });
        layout.addComponent(closeSession);

        Button invalidate = new Button("Invalidate session");
        invalidate.addClickListener(new Button.ClickListener() {
            @Override
            public void buttonClick(ClickEvent event) {
                getSession().getSession().invalidate();
            }
        });
        layout.addComponent(invalidate);
    }

    @PostConstruct
    public void postConstruct() {
        System.out.println("postConstruct");
    }

    @PreDestroy
    public void preDestroy() {
        System.out.println("preDestroy");
    }
}

Open the UI, click "Close UI". Note that the preDestroy method is never called. Refreshing until a new UI is shown does not trigger preDestroy either.

Imported from https://dev.vaadin.com/ issue #11792

ContextDeployer breaks VaadinServlet configurability

See here for some details: Vaadin forum

Basically I want to be able to do stuff like

provide my own SystemMessagesProvider
programmatically configure production mode

In a regular Vaadin app I can do all that by subclassing the VaadinServlet. However, since the instantiation of VaadinServlet is hardcoded in ContextDeployer I have no way of providing my own subclass.

Permission check in CDIViewProvider

In order to be able to use other security mechanism than the default JavaEE one (for example Apache Shiro), it is necessary that the method

private boolean isUserHavingAccessToView(Bean<?> viewBean)

is protected and not private, so that it can be overwritten.

UI scope does not work as expected

Originally by @hesara

The annotation @UIScoped only works on UI classes themselves, not other classes injected in them or created otherwise by the server.

java.lang.IllegalStateException: UI id has already been defined after VaadinSession.close

Originally by kumm0307

I've implemented a logout method according to the vaadin Book (4.7.7 Closing a Session).
The method redirects the browser to another page, and close the vaadin session.

private void logout() {
        getPage().setLocation("/myapp/hello.html");
        getSession().close();
    }

After logout, while navigating back to my UI i get this Exception:

SEVERE: java.lang.IllegalStateException: UI id has already been defined
    at com.vaadin.ui.UI.doInit(UI.java:519)
    at com.vaadin.server.AbstractCommunicationManager.getBrowserDetailsUI(AbstractCommunicationManager.java:2468)
    at com.vaadin.server.AbstractCommunicationManager.handleBrowserDetailsRequest(AbstractCommunicationManager.java:2362)
    at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:325)
    at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:201)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:770)

My workaround is to close the underlying http session too.

getSession().getSession().invalidate();

This way UIScopedContext destroyed, and my UI can reload.

I think UIScopedContext should destroy automatically on VaadinSession.close.

Imported from https://dev.vaadin.com/ issue #11418

.project checked in although listed in .gitignore

the root .gitignore marks .project as ignored, but still the repo lists a .project file (twice to be precise, one in root, one in sub-project cdi-integration.
Wouldn't it be cleaner to remove them?

Recent renaming VaadinUI to CDIUI is misleading

The name CDIUI and CDIView (prefix CDI) is misleading. The class it not a CDIView (CDI does not have any views). VaadinUI was better, but longer. I would rename it back to VaadinUI or just straight to UI.

Support for slashes in view names

Right now, a slash in the view name seems to indicate that the text to the right of the slash consists of parameters and is not a part of the view name. However, it would be nice if slashes could be supported in the view names as well, since these could be used for namespacing. For example:

/myapp/#!people/users
/myapp/#!people/user/123
/myapp/#!people/contacts
/myapp/#!people/contacts/456

Allow multiple associated UIs to be specified for a CDIView

Originally by @hesara

The @CDIView should permit specifying more than one UI for a view.

Imported from https://dev.vaadin.com/ issue #11399

Enhancement: Support new "ViewScoped" scope to help with memory management for "one page apps"

In our "one page app" using vaadin-cdi-integration, users only ever use one "ShellUi" UI class and switch between high level functional views with a MenuBar and Navigator. I believe that a consequence of this is that each view bean will live throughout the lifecycle of the UI Bean, which could eventually lead to a large session size as the user traverses the app. It would be nice to have a narrower scope, such as "ViewScoped" (modeled after the JSF 2.0 ViewScoped, which I believe is conceptually somewhat similar), such that the view and its dependent beans would be cleaned up when the Navigator switches top level views.

Move CDIUIProvider out from internal

Originally by @Artur-

If you use your own servlet class you need to use CDIUIProvider, therefore it should not be "internal".

Imported from https://dev.vaadin.com/ issue #11531

Injecting a component inside an injected component does not work

Originally by @Artur-

Imported from https://dev.vaadin.com/ issue #11216

UIScoped should work on individual fields

Originally by @hesara

The annotation @UIScoped currently only works on the class level. There should not be any reason not to support it on individual fields, which would permit more flexible mixing of scopes.

Imported from https://dev.vaadin.com/ issue #11377

Closing of VaadinSession does not trigger @UIScope destruction

Originally by @Artur-

Using the following simple UI causes strange effects when invalidating the VaadinSession or HTTP session:

@CDIUI
public class CditestUI extends UI {

    @Override
    protected void init(VaadinRequest request) {
        final VerticalLayout layout = new VerticalLayout();
        layout.setMargin(true);
        setContent(layout);

        Button closeSession = new Button("Close VaadinSession");
        closeSession.addClickListener(new Button.ClickListener() {
            @Override
            public void buttonClick(ClickEvent event) {
                getSession().close();
            }
        });
        layout.addComponent(closeSession);

        Button invalidate = new Button("Invalidate session");
        invalidate.addClickListener(new Button.ClickListener() {
            @Override
            public void buttonClick(ClickEvent event) {
                getSession().getSession().invalidate();
            }
        });
        layout.addComponent(invalidate);
    }

    @PostConstruct
    public void postConstruct() {
        System.out.println("postConstruct");
    }

    @PreDestroy
    public void preDestroy() {
        System.out.println("preDestroy");
    }
}

Open the UI, click "Close VaadinSession". Note that the preDestroy method is never called. Refreshing until a new UI is shown does not trigger preDestroy either.

Imported from https://dev.vaadin.com/ issue #11791

Lack of @Root

The @root annotation was removed. It means: any @CDIUI annotation with an empty value marks a root. With that you can very efficiently declare a single root (it actually happens only once), but we are loosing Convention over Configuration capabiltities: previously the URI was automatically derived from the CDIUI#getClass().getSimpleName().

Now you will have to declare the URI for all UIs. The behavior is actually not consistent with the JavaEE 6 API (EJBs, CDI, JPA).

Proposal: revival of the @root annotation.

Rename Github project

Originally by @Artur-

The Github project should be renamed to "cdi"

Imported from https://dev.vaadin.com/ issue #11205

Eliminate VaadinCDIServlet

Originally by @hesara

CDI should be possible to do with just CDIUIProvider without a custom servlet to use use it with other servlet classes than the default one.

This requires the UIProvider to be configured automatically for a new VaadinServlet by the context deployer (when no Vaadin servlets configured by the user).

Imported from https://dev.vaadin.com/ issue #11405

Automatically build Directory ZIP package for the CDI add-on

Originally by @hesara

The Vaadin CDI add-on should be automatically packaged also as a ZIP for the directory with a suitable manifest.

Imported from https://dev.vaadin.com/ issue #11606

Add test for injecting EJBs

Originally by @hesara

The tests for Vaadin CDI integration should also test injecting an EJB.

Imported from https://dev.vaadin.com/ issue #11479

Ability to use custom servlets

Originally by @vaadin-kim

The current ContextDeployer implementation doesn't give much room for customization. For example, if I want to use a custom servlet, I would have to copy quite a lot of code since all the necessary methods are set as private.

Imported from https://dev.vaadin.com/ issue #11931

Add a test for validating scopes

Originally by @Artur-

The test should use one UI, a couple of Views and an EJB service. Should not use @SessionScoped anywhere.

Imported from https://dev.vaadin.com/ issue #11209

Update pom.xml to contain required information

Originally by @Artur-

The pom.xml should at least contain scm and developer information to be deployable to Maven central.

Imported from https://dev.vaadin.com/ issue #11207

Mark @UIScoped as @Inherited

When using abstract UI/Component classes, it would eliminante a possible client mistake (I just made when using cdiutils).
If a parent component decides that the scope is UI, then the extending component should just go along with it

Verify that isUserSignedIn works on Glasfish

Originally by @Artur-

At least earlier there was problems with isUserSignedIn and Glassfish as Glassfish returned a dummy Principal instead of null. Check if this is still a problem.

Imported from https://dev.vaadin.com/ issue #11397

Add passivation support

Originally by @Artur-

Imported from https://dev.vaadin.com/ issue #11504

Remove @Root

Originally by @Artur-

There seem to be no need to have a @root annotation. Instead @CDIUI should by default map the UI to "/" (if there is no path defined). Multiple @CDIUIs with "/" mapping should cause an error.

Imported from https://dev.vaadin.com/ issue #11218

Turn vaadin-cdi in an OSGi citizien

Vaadin components are already bundles. Weld was ported to OSGi also. so to be able to use vaadin plus cdi in a OSGi environment we need to port vaadin-cdi too.

Implement a nightly build

Originally by @Artur-

The addon should be built and deployed to maven every night (provided there are changes)

Imported from https://dev.vaadin.com/ issue #11208

Remove automatic CDI view name generation

Originally by @hesara

CDI view names are currently generated automatically when not explicitly specified. This prevents easily registering a root view via @CDIView and desired view names rarely match the class names except in tests.

Automatic generation of view names should be removed so that no name specified means root (default) view.

Imported from https://dev.vaadin.com/ issue #11330

Support injecting Views into Navigator using CDI

Originally by @Legioth

With basic CDI support in the framework and Root instances managed by CDI (#9260), we could allow injecting a Navigator instance that would automatically inject and use View instances marked with a @VaadinView annotation.

@VaadinView would have two parameters to control the behavior. The first is name that is used to define the fragment name that should be used to navigate to the View. If no value is defined, getSimpleName() of the View class is used.

The second parameter is root that contains the Class of the Root to which the View should belong in case there are multiple Root classes in the Application (injecting Navigator instances). If no root parameter is provided, the View gets assigned to the Root that is configured to be served by requests to the Application's root path (if there's no such Root, an exception should be thrown as early as possible).

From a technical point of view, all the CDI integration should probably be defined in a custom ViewProvider.

Imported from https://dev.vaadin.com/ issue #9261

Producers for static helpers (UI.getCurrent(), ...)

Vaadin 7 provides a bunch of static helpers. While easy to use, those are hard to test/mock. In cdi context, we should provide producers like

@produces
@current
public UI getCurrentUI() {
return UI.getCurrent();
}
}

Now we can just use

@Inject
@current
private Instance ui;

Those can be easily injected and combined and for testing/mocking I dont have to mess with the static methods.

RuntimeException when executing tests

The exception below is thrown when running the test on the vaadin-cdi project. I think it only happens, when there is no Vaadin-7.0-SNAPSHOT in the local maven repository. To fix it, I changed the version to 7.0.2 (the version the project currently depends on) in the ArchiveProvider class.

java.lang.RuntimeException: Could not invoke deployment method: public static org.jboss.shrinkwrap.api.spec.WebArchive com.vaadin.cdi.MultipleRootUIsIT.archiveWithMultipleRoots()
at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addAsLibrary(ContainerBase.java:1534)
at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addAsLibrary(ContainerBase.java:1476)
at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addAsLibrary(ContainerBase.java:1450)
at org.jboss.shrinkwrap.impl.base.container.ContainerBase.addAsLibraries(ContainerBase.java:1612)
at com.vaadin.cdi.ArchiveProvider.base(ArchiveProvider.java:55)
at com.vaadin.cdi.ArchiveProvider.createWebArchive(ArchiveProvider.java:46)
at com.vaadin.cdi.MultipleRootUIsIT.archiveWithMultipleRoots(MultipleRootUIsIT.java:62)

Create an interface for access control

Originally by @Artur-

The included JAAS authentication should not be used directly from the CDI addon. It should use an interface for Access control implementations and JAAS should be the default implementation used.

Imported from https://dev.vaadin.com/ issue #11217

Closing of VaadinSession is handled incorrectly in vaadin-cdi

Originally by @Artur-

Using the following simple UI causes strange effects when invalidating the VaadinSession or HTTP session:

@CDIUI
public class CditestUI extends UI {

    @Override
    protected void init(VaadinRequest request) {
        final VerticalLayout layout = new VerticalLayout();
        layout.setMargin(true);
        setContent(layout);

        Button closeSession = new Button("Close VaadinSession");
        closeSession.addClickListener(new Button.ClickListener() {
            @Override
            public void buttonClick(ClickEvent event) {
                getSession().close();
            }
        });
        layout.addComponent(closeSession);

        Button invalidate = new Button("Invalidate session");
        invalidate.addClickListener(new Button.ClickListener() {
            @Override
            public void buttonClick(ClickEvent event) {
                getSession().getSession().invalidate();
            }
        });
        layout.addComponent(invalidate);
    }

    @PostConstruct
    public void postConstruct() {
        System.out.println("postConstruct");
    }

    @PreDestroy
    public void preDestroy() {
        System.out.println("preDestroy");
    }
}

Open the UI, click "Close VaadinSession" and then refresh the browser

The result is

com.vaadin.server.ServiceException: java.lang.IllegalStateException: VaadinServiceSession has already been set. Old session: com.vaadin.server.VaadinSession@22c6bb6c for VaadinServlet. New session: com.vaadin.server.VaadinSession@2a2096d7 for VaadinServlet.

Click refresh again in the browser and the result is either the same or

com.vaadin.server.ServiceException: java.lang.IllegalStateException: UI id has already been defined

Click refresh a couple of more times and you will get a new UI.

Imported from https://dev.vaadin.com/ issue #11790

Revise log levels

Originally by @Artur-

CDI alpha1 constantly logs a lot of almost debug stuff. All logging should be checked and log levels adjusted.

Imported from https://dev.vaadin.com/ issue #11480

vaadin / cdi Goto Github PK

cdi's Introduction

Vaadin CDI

Using with Vaadin 10

Getting started

Building the project

Run integration tests

Issue tracking

Contributions

cdi's People

Contributors

Stargazers

Watchers

Forkers

cdi's Issues

Recommend Projects

Recommend Topics

Recommend Org

Jobs