[JBoss JIRA] (WFLY-3335) JAXB transformer initiation
by Fabien KOCIK (JIRA)
[ https://issues.jboss.org/browse/WFLY-3335?page=com.atlassian.jira.plugin.... ]
Fabien KOCIK commented on WFLY-3335:
------------------------------------
Hello,
Encountering the same issues applying some XSL templates on provided XML files in EJB bean startup context.
My EAR works fine in JBoss AS 7.
Regards.
> JAXB transformer initiation
> ---------------------------
>
> Key: WFLY-3335
> URL: https://issues.jboss.org/browse/WFLY-3335
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Class Loading
> Affects Versions: 8.0.0.Final, 8.1.0.CR1
> Environment: Ubuntu 14.04 with java 7 openjdk
> Reporter: Ghet Ghetolay
> Assignee: David Lloyd
> Priority: Blocker
>
> I'm not directly using JAXB and SaxTransformer, it's part of a the [dcm4chee-arc project|https://github.com/dcm4che/dcm4chee-arc] which I tried to use on Wildfly. It's a rather big and complicated project so I've create a test application to illustrate the bug. I've used a JAR-RS application to illustrate the bug (like the original case) but this should not be related to it.
> {code:title=TestRS.java}
> @Path("test")
> public class TestRS {
>
> private static SAXTransformerFactory factory =
> (SAXTransformerFactory) TransformerFactory.newInstance();
>
> @GET
> public Response test(){
> try {
> Templates template = factory.newTemplates(new StreamSource(
> TestRS.class.getResource("json_compact.xsl").toString()));
>
> factory.newTransformerHandler(template);
>
> } catch (TransformerConfigurationException e) {
> // TODO Auto-generated catch block
> e.printStackTrace();
> }
>
> return Response.ok().build();
> }
> }
> {code}
> {code:title=json_compact.xsl}
> <?xml version="1.0" encoding="UTF-8"?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
> <xsl:output method="text"/>
> <xsl:template match="/">
> <xsl:text>Test</xsl:text>
> </xsl:template>
> </xsl:stylesheet>
> {code}
> {quote}
> 15:24:48,564 ERROR [stderr] (default task-1) javax.xml.transform.TransformerConfigurationException: Translet class loaded, but unable to create translet instance.
> 15:24:48,564 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.defineTransletClasses(TemplatesImpl.java:369)
> 15:24:48,565 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.getTransletInstance(TemplatesImpl.java:383)
> 15:24:48,565 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl.newTransformer(TemplatesImpl.java:418)
> 15:24:48,565 ERROR [stderr] (default task-1) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl.newTransformerHandler(TransformerFactoryImpl.java:1062)
> 15:24:48,565 ERROR [stderr] (default task-1) at __redirected.__TransformerFactory.newTransformerHandler(__TransformerFactory.java:193)
> 15:24:48,566 ERROR [stderr] (default task-1) at test.TestRS.test(TestRS.java:25)
> {quote}
> I've discovered that the initial exception is :
> {quote}
> java.lang.NoClassDefFoundError: com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet
> {quote}
> Both my test case and dcm4che-arc project works fine on JBoss 7.1.1.Final.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (DROOLS-483) Repeated class loading of absent services
by Frank Pavageau (JIRA)
[ https://issues.jboss.org/browse/DROOLS-483?page=com.atlassian.jira.plugin... ]
Frank Pavageau commented on DROOLS-483:
---------------------------------------
Hi there.
It's been more than 3 months and neither this issue nor the pull request has seen any kind of response, so I was wondering if something important is missing (other than time of the Drools team side).
Should I continue rebasing the modification on master from time to time?
> Repeated class loading of absent services
> -----------------------------------------
>
> Key: DROOLS-483
> URL: https://issues.jboss.org/browse/DROOLS-483
> Project: Drools
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final, 5.6.0.Final, 6.0.1.Final, 6.1.0.Final
> Reporter: Frank Pavageau
> Assignee: Mark Proctor
>
> h3. Context
> The {{ServiceRegistry}} is used to get the providers for a number of services, several of which don't have an implementation in a Drools artifact but in jBPM, for example.
> Those providers include:
> - {{ProcessBuilderFactoryService}} (implemented by {{org.jbpm.process.builder.ProcessBuilderFactoryServiceImpl}}) called in the constructor of {{KnowledgeBuilderImpl}} through {{ProcessBuilderFactory}}
> - {{ProcessRuntimeFactoryService}} (implemented by {{org.jbpm.process.instance.ProcessRuntimeFactoryServiceImpl}}) called in the constructor of {{StatefulKnowledgeSessionImpl}} through {{ProcessRuntimeFactory}}, so this one especially can be called frequently
> Both {{ProcessBuilderFactory}} and {{ProcessRuntimeFactory}} use the fact that the static field containing the service is not null to know they've been initialized, which means they'll continuously try to load the class if it's not actually in the classpath.
> h3. Enhancement
> If this behavior is not needed for the OSGi support, I'd like to see the initialization test use a boolean field to only try loading the class once. And if it is needed for OSGi, maybe the behavior could be configured.
> h3. Rationale
> Attempting to load a class is a costly operation, especially in the context of a web application running on Tomcat. I've pushed a [JMH|http://openjdk.java.net/projects/code-tools/jmh/] benchmark on [Github|https://github.com/fpavageau/bench-for-name] to illustrate the point (see the [README.md|https://github.com/fpavageau/bench-for-name#results]): a failed call to Class.forName() takes ~22 microseconds using the context classloader of the benchmark (i.e. probably the system classloader), ~75 microseconds using a Tomcat classloader configured ({{WebappClassLoader}}) with 100 empty jars (that need to be scanned for the missing class). Combined with the fact that {{Class.forName()}} calls {{ClassLoader.loadClass()}} which in the case of {{WebappClassLoader}} is a synchronized method, it becomes a nice bottleneck in a high-traffic application creating {{StatefulKnowledgeSessions}} extensively, because of the lock contention.
> Another side-effect of this flow is that {{ServiceRegistryImpl}} continuously gets a {{ClassNotFoundException}}, then throws an {{IllegalArgumentException}}, which means 2 stacktraces to fill for each call, and that is also an [expensive operation|http://shipilev.net/blog/2014/exceptional-performance/] when throwing exceptions is not exceptional and becomes the regular control flow.
> I've been able to grab stacktraces from Drools to {{WebappClassLoader.loadClass()}} when doing thread dumps on an application with sufficient load, so it's frequent enough that it can be observed by sampling and not just a rhetorical question.
> I could create a pull request, but I'd like to get some feedback first.
> Note: most calls to {{ServiceRegistry.get()}} use the same pattern, but the 2 I have picked out are the ones which happen the most frequently for my use case.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (DROOLS-586) Drools doesn't calculate maximum expiration time properly
by kairat kushaev (JIRA)
[ https://issues.jboss.org/browse/DROOLS-586?page=com.atlassian.jira.plugin... ]
kairat kushaev commented on DROOLS-586:
---------------------------------------
Guys, do you have any updates?
> Drools doesn't calculate maximum expiration time properly
> ---------------------------------------------------------
>
> Key: DROOLS-586
> URL: https://issues.jboss.org/browse/DROOLS-586
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Environment: Linux, Java SE 1.7
> Reporter: kairat kushaev
> Assignee: Mark Proctor
> Fix For: 6.1.0.Final
>
>
> Hello guys,
> we found some contradiction between actual Drools behavior,
> We use the following Rule:
> import drools.test.Event;
> dialect "mvel"
> declare Event
> @role(event)
> @expires(10s)
> end
> rule "ExampleRule"
> when
> ( $a : Event(name == "event a") ) and
> ( $b : Event((name == "event b") && (this after [1ms, 15s] $a)) )
> then
> System.out.println("bingo!");
> end
> In the code above Drools should wait for the second event when the first event came. But it turns out that Drools doesn't wait for the second event because of @expires tag. The value in this tag is less than this after value.
> According to documentation
> "The engine will make this analysis for the whole rulebase and find the offset for every event type. Whenever an implicit expiration offset clashes with the explicit expiration offset, then engine will use the greater of the two."
> but it is not calculating maximal expiration offset. Also we are using STREAM mode.
> Could you please clarify the situation?
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (DROOLS-242) Add out-of-the-box possibility to dump DRL created from decision tables
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-242?page=com.atlassian.jira.plugin... ]
Petr Široký updated DROOLS-242:
-------------------------------
Description:
To get the DRL generated from decision table one has to currently use following code:
{code}
File dtable = new File("../resources/dtable.xls");
KieResources kieResources = KieServices.Factory.get().getResources();
Resource dtableResource = kieResources.newFileSystemResource(dtable);
SpreadsheetCompiler compiler = new SpreadsheetCompiler();
String drl = compiler.compile(dtableResource.getInputStream(), InputType.XLS);
{code}
It would be nice to have this functionality out-of-the-box, similarly like 'drools.dump.dir' which is used to dump the Java classes generated from DRL.
Looking at how the options are being used I see basically three possible solutions here (I maybe missing some other options):
- get the value of `drools.dump.dir` manually using the ChainedProperties. I think this is not good idea as it is duplicating the code.
- add this config. option into DecisionTableConfiguration. This would prevent the backwards comptibility issues when changing the DecisionTableProvider interface, but I am not entirely sure it is the right place for this kind of config.
- pass the entire KnowledgeBuilderConfiguration object into DecisionTableProvider.loadFromInputStream(). This seems like the best option from the clean-code point of view, but it would mean that the DecisionTableProvider interface would have to altered.
was:
To get the DRL generated from decision table one has to currently use following code:
{code}
File dtable = new File("../resources/dtable.xls");
KieResources kieResources = KieServices.Factory.get().getResources();
Resource dtableResource = kieResources.newFileSystemResource(dtable);
SpreadsheetCompiler compiler = new SpreadsheetCompiler();
String drl = compiler.compile(dtableResource.getInputStream(), InputType.XLS);
{code}
It would be nice to have this functionality out-of-the-box, similarly like 'drools.dump.dir' which is used to dump the Java classes generated from DRL.
> Add out-of-the-box possibility to dump DRL created from decision tables
> ------------------------------------------------------------------------
>
> Key: DROOLS-242
> URL: https://issues.jboss.org/browse/DROOLS-242
> Project: Drools
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.CR2
> Reporter: Petr Široký
> Assignee: Petr Široký
>
> To get the DRL generated from decision table one has to currently use following code:
> {code}
> File dtable = new File("../resources/dtable.xls");
> KieResources kieResources = KieServices.Factory.get().getResources();
> Resource dtableResource = kieResources.newFileSystemResource(dtable);
> SpreadsheetCompiler compiler = new SpreadsheetCompiler();
> String drl = compiler.compile(dtableResource.getInputStream(), InputType.XLS);
> {code}
> It would be nice to have this functionality out-of-the-box, similarly like 'drools.dump.dir' which is used to dump the Java classes generated from DRL.
> Looking at how the options are being used I see basically three possible solutions here (I maybe missing some other options):
> - get the value of `drools.dump.dir` manually using the ChainedProperties. I think this is not good idea as it is duplicating the code.
> - add this config. option into DecisionTableConfiguration. This would prevent the backwards comptibility issues when changing the DecisionTableProvider interface, but I am not entirely sure it is the right place for this kind of config.
> - pass the entire KnowledgeBuilderConfiguration object into DecisionTableProvider.loadFromInputStream(). This seems like the best option from the clean-code point of view, but it would mean that the DecisionTableProvider interface would have to altered.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (SECURITY-640) Jboss Negotiation fallback to login page if NTLM token is received or the user is not present in active directory.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-640?page=com.atlassian.jira.plug... ]
Darran Lofthouse resolved SECURITY-640.
---------------------------------------
Resolution: Done
This is not a support case, leaving as 'Resolved' is fine.
> Jboss Negotiation fallback to login page if NTLM token is received or the user is not present in active directory.
> ------------------------------------------------------------------------------------------------------------------
>
> Key: SECURITY-640
> URL: https://issues.jboss.org/browse/SECURITY-640
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Environment: Active Directory Winwos 2003, Client Machine windows XP, Jboss Server Machine Window XP and Jboss 6.1
> Reporter: Hrishi Salvi
> Assignee: Derek Horton
> Fix For: Negotiation_2_3_0_CR2, Negotiation_2_2_8
>
>
> We are trying to configure the single sign on using jboss negotiation.
> We are able to login successfully if the user is present in active directory.
> But in case if user is not present in active directory users, it throw 401 error page.
> Instead of 401 we want user to access login form and authenticate user using different login module.
> In our case we have login page we authenticate user on that page.
> If we receive user credentials we login the user without asking for password.
> Now if the user credentials are not received then we want user to open login form present
> on login page, but before that is throws 401 error.
> We have configure the login-config.xml, web.xml and jboss-web.xml as per the documentation.
> Also defined
> <web-resource-collection>
> <web-resource-name>Restricted</web-resource-name>
> <url-pattern>/Request</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> in web.xml
> Our application is access through Request servlet.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (SECURITY-640) Jboss Negotiation fallback to login page if NTLM token is received or the user is not present in active directory.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-640?page=com.atlassian.jira.plug... ]
Darran Lofthouse reopened SECURITY-640:
---------------------------------------
> Jboss Negotiation fallback to login page if NTLM token is received or the user is not present in active directory.
> ------------------------------------------------------------------------------------------------------------------
>
> Key: SECURITY-640
> URL: https://issues.jboss.org/browse/SECURITY-640
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Environment: Active Directory Winwos 2003, Client Machine windows XP, Jboss Server Machine Window XP and Jboss 6.1
> Reporter: Hrishi Salvi
> Assignee: Derek Horton
> Fix For: Negotiation_2_2_8, Negotiation_2_3_0_CR2
>
>
> We are trying to configure the single sign on using jboss negotiation.
> We are able to login successfully if the user is present in active directory.
> But in case if user is not present in active directory users, it throw 401 error page.
> Instead of 401 we want user to access login form and authenticate user using different login module.
> In our case we have login page we authenticate user on that page.
> If we receive user credentials we login the user without asking for password.
> Now if the user credentials are not received then we want user to open login form present
> on login page, but before that is throws 401 error.
> We have configure the login-config.xml, web.xml and jboss-web.xml as per the documentation.
> Also defined
> <web-resource-collection>
> <web-resource-name>Restricted</web-resource-name>
> <url-pattern>/Request</url-pattern>
> <http-method>GET</http-method>
> <http-method>POST</http-method>
> </web-resource-collection>
> in web.xml
> Our application is access through Request servlet.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (WFLY-3796) org.jboss.weld.exceptions.IllegalArgumentException during HttpSession.invalidate
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-3796?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger reassigned WFLY-3796:
-------------------------------------
Assignee: Martin Kouba (was: Stuart Douglas)
> org.jboss.weld.exceptions.IllegalArgumentException during HttpSession.invalidate
> --------------------------------------------------------------------------------
>
> Key: WFLY-3796
> URL: https://issues.jboss.org/browse/WFLY-3796
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 9.0.0.Beta1
> Reporter: Juergen Zimmermann
> Assignee: Martin Kouba
>
> I'm using WildFly 9.0.0.Alpha1 snapshot. When I invoke HttpSession.invalidate() after PicketLink's logout method I'm getting a org.jboss.weld.exceptions.IllegalArgumentException (see stacktrace below). I also tried weld-core-impl-2.2.4.Final, but got the same stacktrace.
> The Session Bean "ListKundenModel" has these annotations:
> @Named
> @ViewScoped
> @Stateful
> {code}
> WARNING [javax.enterprise.resource.webcontainer.jsf.lifecycle] #{logoutModel.logout}: org.jboss.weld.exceptions.IllegalArgumentException: WELD-000085: Cannot destroy null instance of Session bean [class de.shop.kundenverwaltung.web.ListKundenModel with qualifiers [@Default @Any @Named]; local interfaces are [ListKundenModel]: javax.faces.FacesException: #{logoutModel.logout}: org.jboss.weld.exceptions.IllegalArgumentException: WELD-000085: Cannot destroy null instance of Session bean [class de.shop.kundenverwaltung.web.ListKundenModel with qualifiers [@Default @Any @Named]; local interfaces are [ListKundenModel]
> at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:118) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at javax.faces.component.UICommand.broadcast(UICommand.java:315) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:790) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:1282) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:81) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:198) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at javax.faces.webapp.FacesServlet.service(FacesServlet.java:646) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:259) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:246) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:75) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:165) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:737) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_20]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_20]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_20]
> Caused by: javax.faces.el.EvaluationException: org.jboss.weld.exceptions.IllegalArgumentException: WELD-000085: Cannot destroy null instance of Session bean [class de.shop.kundenverwaltung.web.ListKundenModel with qualifiers [@Default @Any @Named]; local interfaces are [ListKundenModel]
> at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:101) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:102) [jsf-impl-2.2.8-jbossorg-1.jar:]
> ... 33 more
> Caused by: org.jboss.weld.exceptions.IllegalArgumentException: WELD-000085: Cannot destroy null instance of Session bean [class de.shop.kundenverwaltung.web.ListKundenModel with qualifiers [@Default @Any @Named]; local interfaces are [ListKundenModel]
> at org.jboss.weld.bean.SessionBean.destroy(SessionBean.java:155) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at com.sun.faces.application.view.ViewScopeContextManager.destroyBeans(ViewScopeContextManager.java:177) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.view.ViewScopeContextManager.sessionDestroyed(ViewScopeContextManager.java:339) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.view.ViewScopeManager.sessionDestroyed(ViewScopeManager.java:371) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.application.WebappLifecycleListener.sessionDestroyed(WebappLifecycleListener.java:181) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at com.sun.faces.config.ConfigureListener.sessionDestroyed(ConfigureListener.java:377) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at io.undertow.servlet.core.ApplicationListeners.sessionDestroyed(ApplicationListeners.java:264) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.core.SessionListenerBridge.sessionDestroyed(SessionListenerBridge.java:66) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.session.SessionListeners.sessionDestroyed(SessionListeners.java:56) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(InMemorySessionManager.java:395) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(InMemorySessionManager.java:381) [undertow-core-1.1.0.Beta6.jar:1.1.0.Beta6]
> at io.undertow.servlet.spec.HttpSessionImpl.invalidate(HttpSessionImpl.java:197) [undertow-servlet-1.1.0.Beta6.jar:1.1.0.Beta6]
> at de.shop.iam.web.LogoutModel.logout(LogoutModel.java:55) [classes:]
> at de.shop.iam.web.LogoutModel$Proxy$_$$_WeldSubclass.logout(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_20]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_20]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_20]
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_20]
> at org.jboss.weld.interceptor.proxy.SimpleInterceptionChain.interceptorChainCompleted(SimpleInterceptionChain.java:51) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:96) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.proxy.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:149) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at de.shop.util.interceptor.LogInterceptor.log(LogInterceptor.java:96) [classes:]
> at sun.reflect.GeneratedMethodAccessor2531.invoke(Unknown Source) [:1.8.0_20]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_20]
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_20]
> at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:116) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:94) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.proxy.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:149) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInOurTx(TransactionalInterceptorBase.java:92) [narayana-jts-jacorb-5.0.2.Final.jar:5.0.2.Final (revision: d1e56)]
> at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept(TransactionalInterceptorRequired.java:52) [narayana-jts-jacorb-5.0.2.Final.jar:5.0.2.Final (revision: d1e56)]
> at sun.reflect.GeneratedMethodAccessor110.invoke(Unknown Source) [:1.8.0_20]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_20]
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_20]
> at org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:74) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNext(AbstractInterceptionChain.java:116) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.chain.AbstractInterceptionChain.invokeNextInterceptor(AbstractInterceptionChain.java:94) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception(InterceptorMethodHandler.java:43) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke(InterceptorMethodHandler.java:36) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke(CombinedInterceptorAndDecoratorStackMethodHandler.java:51) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at de.shop.iam.web.LogoutModel$Proxy$_$$_WeldSubclass.logout(Unknown Source) [classes:]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_20]
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_20]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_20]
> at java.lang.reflect.Method.invoke(Method.java:483) [rt.jar:1.8.0_20]
> at com.sun.el.parser.AstValue.invoke(AstValue.java:292) [javax.el-impl-3.0.1-b05-jbossorg-1.jar:3.0.1-b05-jbossorg-1]
> at com.sun.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:304) [javax.el-impl-3.0.1-b05-jbossorg-1.jar:3.0.1-b05-jbossorg-1]
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.util.el.ForwardingMethodExpression.invoke(ForwardingMethodExpression.java:40) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at org.jboss.weld.el.WeldMethodExpression.invoke(WeldMethodExpression.java:50) [weld-core-impl-2.2.3.Final.jar:2014-07-07 07:39]
> at com.sun.faces.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:105) [jsf-impl-2.2.8-jbossorg-1.jar:]
> at javax.faces.component.MethodBindingMethodExpressionAdapter.invoke(MethodBindingMethodExpressionAdapter.java:87) [jboss-jsf-api_2.2_spec-2.2.8.jar:2.2.8]
> ... 34 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months