小编HDa*_*ave的帖子

我意识到这已经被问过,但最后一次是在2008年中期.

如果你现在正在开始一个新项目,你会使用哪一个？为什么？他们在可读性,可用性,可维护性和整体稳健性方面的优势/劣势是什么？

如果可能的话,我想将Tomcat的context.xml文件保留在WAR文件的META-INF目录之外.这可以用Maven的货物插件完成吗？我似乎找不到正确的配置.

我正在将应用程序从Flex转换为Javascript.我在Eclipse for Flex中的工作流程是使用Maven在Tomcat中启动我的Java Web应用程序,然后将Eclipse配置为将已编辑的Actionscript文件编译为SWF并将其保存到我的爆炸WAR目录(Maven/Cargo使用).

它在很长一段时间内都运行良好,允许我编辑动作源代码,翻转浏览器,刷新屏幕并查看更改.

我是Javascript的新手,但我正努力让同样的工作流程启动并运行.我不理解的部分是如何告诉Eclipse我希望将编辑好的Javascript文件写出到特定目录(包含爆炸的WAR).在我的WAR项目(一个WTP动态Web项目)中,有些东西看起来像一个名为"Javascript resources"的Javascript构建路径,但是没有输出目录.

如果可能的话,我真的想继续通过Maven继续运行Tomcat和Jetty.我意识到我可以通过WTP(M2E-WTP)做我想做的事,但更喜欢使用Maven/Cargo.

自从迁移到Spring Security 3.2.5.RELEASE和Spring 4.1.1.RELEASE以来,我们在Eclipse(Luna)中收到了一个Spring Bean Validation警告.

确切的警告是:

Class 'org.springframework.security.core.authority.AuthorityUtils' is abstract

这是Spring文件的标题:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:tx="http://www.springframework.org/schema/tx" xmlns:springsecurity="http://www.springframework.org/schema/security"
    xmlns:jaxrs="http://cxf.apache.org/jaxrs" xmlns:cxf="http://cxf.apache.org/core"
    xmlns:jee="http://www.springframework.org/schema/jee"
    xsi:schemaLocation="http://www.springframework.org/schema/jee http://www.springframework.org/schema/jee/spring-jee-4.1.xsd
        http://cxf.apache.org/core http://cxf.apache.org/schemas/core.xsd
        http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.2.xsd
        http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-4.1.xsd
        http://cxf.apache.org/jaxrs http://cxf.apache.org/schemas/jaxrs.xsd
        http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-4.1.xsd">

配置的违规部分如下(意味着如果我删除此部分,则错误消失.具体来说,如果我删除该springsecurity:authentication-provider节:

<springsecurity:authentication-manager alias="authenticationManager">
    <springsecurity:authentication-provider>
        <springsecurity:user-service>
            <springsecurity:user name="john" password="john"
                authorities="ROLE_USER" />
            <springsecurity:user name="admin" password="admin"
                authorities="ROLE_USER, ROLE_ADMIN" />
            <springsecurity:user name="guest" password="guest"
                authorities="ROLE_GUEST" />
        </springsecurity:user-service>
    </springsecurity:authentication-provider>
</springsecurity:authentication-manager>

关于这个根本原因的任何想法？我们的项目没有提出虚假警告,我不想禁用Spring bean验证.

我正在考虑使用Spring安全注释为我的应用程序,使用EL(表达式语言)功能.例如:

@PreAuthorize("hasPermission(#contact, 'admin')")
public void deletePermission(Contact contact, Sid recipient, Permission permission);

我需要EL功能,因为我已经构建了自己的ACL实现.但是,要将此功能与"#contact"类型参数一起使用,Spring文档会说:

如果代码中包含编译的调试信息,则可以按名称访问任何方法参数作为表达式变量.

这引出了两个问题:

1. 将生产应用程序商业化分发并附带调试信息是可以接受的吗？
2. 如果没有,有什么办法吗？

感谢您的任何指导!

我有一个新的Web应用程序,作为多模块Maven项目的一部分打包为WAR.此WAR的applicationContext.xml引用从"service"模块导入的bean,后者又从"dao"模块导入bean.applicationContext.xml中的import语句如下所示:

<import resource="classpath*:service.xml" />

而service.xml文件中的那个看起来像这样:

<import resource="classpath*:dao.xml" />

Spring STS和Eclipse都没有在我的bean文件中显示任何警告或错误.我在整个地方引用了进口的豆子.Maven构建工作正常,DAO集成测试全部通过(他们使用bean).我还没有任何服务集成测试.

但是当我在Jetty中启动WAR时,我收到一个错误:

Error creating bean with name 'securityService' 
Cannot resolve reference to bean 'userDAO' while setting constructor argument

所有导入的bean XML文件都可以在WEB-INF/lib目录中的各自JAR文件中找到.实际上,抛出错误的服务bean本身是在服务模块的JAR文件内的service.xml文件中定义的.

显然,服务模块找不到它从dao模块导入的bean.显然我不明白的东西......看起来这应该只是工作吗？

我有一个不使用EJB的Java EE Web应用程序.我有时会以Jetty/Tomcat为目标进行部署,因此需要一个WAR包装.但是,我也在某些时候瞄准JBoss和Websphere.

我的理解是,成熟的Java EE应用程序服务器可以采用EAR或WAR格式.我何时会使用一个而不是为什么？我知道它们都是标准的压缩文件格式,我已经阅读了10个不同的片段,试图解释它们(包括这个),但我们并没有更接近理解每个片段的优缺点.

我正在从Maven的jetty插件迁移到Cargo插件(cargo-maven2-plugin),因为Cargo将很乐意从依赖的Maven模块运行WAR.在网络应用程序中,我们花了很大力气通过JNDI外部化所有配置.这些JNDI定义是特定于Web应用程序的,因此放在WAR外部的jetty-env.xml文件中.使用Jetty插件,我们将此文件指定如下:

        <plugin>
            <groupId>org.mortbay.jetty</groupId>
            <artifactId>maven-jetty-plugin</artifactId>
            <configuration>
                <jettyEnvXml>${basedir}/target/config/jetty-env.xml</jettyEnvXml>
            </configuration>
        </plugin>

如何在Cargo Plugin中指定它？这是我到目前为止的配置.当然,由于缺少JNDI配置,它失败了:

        <plugin>
                <groupId>org.codehaus.cargo</groupId>
                <artifactId>cargo-maven2-plugin</artifactId>
                <configuration>
                    <container>
                        <containerId>jetty6x</containerId>
                        <type>embedded</type>
                    </container>
                    <configuration>
                        <deployables>
                            <deployable>
                                <groupId>com.mycompany</groupId>
                                <artifactId>my-war-module</artifactId>
                                <type>war</type>
                                <properties>
                                   <context>/</context>
                                </properties>
                            </deployable>
                        </deployables>
                    </configuration>
                    <wait>false</wait>
                </configuration>
                <executions>
                           ......
                </executions>
        </plugin>

我们有一个相当复杂的多模块Maven项目.有Flex模块,GWT模块,Java模块和许多WAR模块.为了简单地将这些项目导入Eclipse的过程,历史上我们在源代码树中包含了所有相关的Eclipse项目文件.

但是,这在过去一直是问题的根源,因为有时这些文件会被意外修改并签入...因此会给其他开发人员带来问题.随着M2E的出现及其对配置器的新支持,以帮助在导入时设置Eclipse项目,我们正在重新考虑这一策略.

一般来说,项目是否包含Subversion/Git/etc中的这些Eclipse文件？

我在 Eclipse 中有一个多模块 Maven Java (WAR) 项目。这取决于一堆其他 Java 项目。我们将 .settings 目录检查到源代码管理中，因为那里有许多手动建立的设置。

.settings 中的文件之一org.eclipse.wst.common.component也具有手动建立的设置。但是，Eclipse 会根据开发人员在 Eclipse 中打开的底层 JAR 项目不断修改该文件。我相信这样做是为了帮助完成这些工件的“工作区解析”。

然而，这种情况的结果是 Eclipse 不断地修改它org.eclipse.wst.common.component，开发人员不断地将它提交给源代码控制并相互争夺它。将这些文件排除在源代码控制之外是行不通的，因为其中有太多针对每个项目的手动调整。

我猜测 Eclipse 中有一个将项目设置和用户设置组合在一起的文件的设计缺陷！如果有人对如何更好地处理这个问题有任何见解，那就太好了。事实上，Eclipse-M2E 根本不适用于复杂项目的团队开发，除非每个开发人员都加载了完全相同的 Java 项目......