[JBoss JIRA] Created: (CDITCK-61) Some tests have dependencies with jsr299-tck-api.jar and jsr299-tck-impl.jar
by Santiago Pericas-Geertsen (JIRA)
Some tests have dependencies with jsr299-tck-api.jar and jsr299-tck-impl.jar
----------------------------------------------------------------------------
Key: CDITCK-61
URL: https://jira.jboss.org/jira/browse/CDITCK-61
Project: CDI TCK
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Tests
Affects Versions: 1.0.1.CR1
Environment: Solaris x86 / JDK 16u6 / GF v3
Reporter: Santiago Pericas-Geertsen
We have found that certain TCK test load classes from jsr299-tck-api.jar and jsr299-tck-impl.jar, but these jars are not normally included in the generated application bundles. An example of such a test is:
*.deployment.packaging.installedLibrary.WarInstalledLibraryTest.test
which looks for:
org/jboss/jsr299/tck/tests/deployment/packaging/installedLibrary/Bar
This test fails with GF as these classes are not available to applications. Should jsr299-tck-api.jar and jsr299-tck-impl.jar be bundled with apps? (We can provide a complete list of tests that depend on these TCK jars if needed).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (CDITCK-222) Typos in documentation
by Jozef Hartinger (JIRA)
Typos in documentation
----------------------
Key: CDITCK-222
URL: https://issues.jboss.org/browse/CDITCK-222
Project: CDI TCK
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Documentation
Affects Versions: 1.0.4.Final
Reporter: Jozef Hartinger
Priority: Minor
Fix For: 1.0.5.CR1, 1.1.0.CR1
appeals-process.xml: spell check failed on 'challengable'
appeals-process.xml: spell check failed on 'rigourous'
Book_Info.xml: spell check failed on 'Refernce'
Book_Preface.xml: spell check failed on 'motiviations'
configuration.xml: repeated instance(s) of 'the'.
configuration.xml: spell check failed on 'implementators'
configuration.xml: spell check failed on 'IntellJ'
configuration.xml: spell check failed on 'testng' (should be TestNG)
eclipse-running.xml: spell check failed on 'dependenices'
eclipse-running.xml: spell check failed on 'Ecilpse'
eclipse-running.xml: spell check failed on 'jsr' (should be JSR)
executing.xml: spell check failed on 'artfact'
executing.xml: spell check failed on 'knowlege'
executing.xml: spell check failed on 'substituate'
executing.xml: spell check failed on 'transitve'
installation.xml: spell check failed on 'documention'
introduction.xml: spell check failed on 'catagory'
introduction.xml: spell check failed on 'specficiation's'
introduction.xml: spell check failed on 'Technially'
introduction.xml: spell check failed on 'TODO'
introduction.xml: spell check failed on 'transfered'
part-test-harness.xml: spell check failed on 'TODO'
reporting.xml: spell check failed on 'Aftering'
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 11 months
[JBoss JIRA] Created: (WELD-855) Error while catching NonexistentConversationException with Seam Faces/Catch
by Brian Leathem (JIRA)
Error while catching NonexistentConversationException with Seam Faces/Catch
---------------------------------------------------------------------------
Key: WELD-855
URL: https://issues.jboss.org/browse/WELD-855
Project: Weld
Issue Type: Bug
Environment: Glassfish 3.1 M2 (b41), weld 1.1 patched with Stuart's WELD-846 patch.
Reporter: Brian Leathem
I have a Faces app, with the exception handler:
void conversationExpired(@Handles CaughtException<NonexistentConversationException> t) {...}
When I pull up a URL with an invalid cid, I get the stacktrace below.
(copied from SEAMCATCH-46)
Stacktrace:
---------------
java.lang.RuntimeException: Exception invoking method [conversationExpired] on object [ca.triumf.mis.qms.workrequest.jsf.exception.ExceptionCatchHandler@264d6a2c], using arguments [org.jboss.seam.exception.control.CaughtException@24758259]
at org.jboss.seam.solder.reflection.Reflections.invokeMethod(Reflections.java:547)
at org.jboss.seam.solder.reflection.Reflections.invokeMethod(Reflections.java:458)
at org.jboss.seam.solder.reflection.annotated.InjectableMethod.invoke(InjectableMethod.java:189)
at org.jboss.seam.exception.control.HandlerMethodImpl.notify(HandlerMethodImpl.java:189)
at org.jboss.seam.exception.control.ExceptionHandlerDispatch.executeHandlers(ExceptionHandlerDispatch.java:129)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.weld.util.reflection.SecureReflections$13.work(SecureReflections.java:305)
at org.jboss.weld.util.reflection.SecureReflectionAccess.run(SecureReflectionAccess.java:54)
at org.jboss.weld.util.reflection.SecureReflectionAccess.runAsInvocation(SecureReflectionAccess.java:163)
at org.jboss.weld.util.reflection.SecureReflections.invoke(SecureReflections.java:299)
at org.jboss.weld.introspector.jlr.WeldMethodImpl.invokeOnInstance(WeldMethodImpl.java:188)
at org.jboss.weld.introspector.ForwardingWeldMethod.invokeOnInstance(ForwardingWeldMethod.java:59)
at org.jboss.weld.injection.MethodInjectionPoint.invokeOnInstanceWithSpecialValue(MethodInjectionPoint.java:198)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:270)
at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:253)
at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:222)
at org.jboss.weld.manager.BeanManagerImpl.notifyObservers(BeanManagerImpl.java:632)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:619)
at org.jboss.weld.manager.BeanManagerImpl.fireEvent(BeanManagerImpl.java:613)
at org.jboss.seam.faces.exception.CatchExceptionHandler.handle(CatchExceptionHandler.java:81)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:119)
at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:113)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:409)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1534)
at org.apache.catalina.core.ApplicationDispatcher.doInvoke(ApplicationDispatcher.java:787)
at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:649)
at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:483)
at org.apache.catalina.core.ApplicationDispatcher.doDispatch(ApplicationDispatcher.java:454)
at org.apache.catalina.core.ApplicationDispatcher.dispatch(ApplicationDispatcher.java:350)
at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:300)
at org.apache.catalina.authenticator.FormAuthenticator.forwardToLoginPage(FormAuthenticator.java:465)
at org.apache.catalina.authenticator.FormAuthenticator.authenticate(FormAuthenticator.java:253)
at com.sun.web.security.RealmAdapter.invokeAuthenticateDelegate(RealmAdapter.java:1192)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:551)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:623)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:595)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:98)
at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:91)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:326)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:227)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:170)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:822)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:719)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:1013)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:225)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:79)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:59)
at com.sun.grizzly.ContextTask.run(ContextTask.java:71)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:532)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:513)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.IllegalStateException: Unable to load current conversations from the associated request, something went badly wrong when associate() was called
at org.jboss.weld.context.AbstractConversationContext.getCurrentConversation(AbstractConversationContext.java:413)
at org.jboss.weld.jsf.ConversationAwareViewHandler.getActionURL(ConversationAwareViewHandler.java:91)
at com.sun.faces.application.view.MultiViewHandler.getRedirectURL(MultiViewHandler.java:381)
at javax.faces.application.ViewHandlerWrapper.getRedirectURL(ViewHandlerWrapper.java:204)
at javax.faces.application.ViewHandlerWrapper.getRedirectURL(ViewHandlerWrapper.java:204)
at org.jboss.weld.jsf.ConversationAwareViewHandler.getRedirectURL(ConversationAwareViewHandler.java:134)
at com.sun.faces.application.NavigationHandlerImpl.handleNavigation(NavigationHandlerImpl.java:166)
at org.jboss.seam.faces.event.SeamPreNavigationHandler.handleNavigation(SeamPreNavigationHandler.java:77)
at ca.triumf.mis.qms.workrequest.jsf.exception.ExceptionCatchHandler.conversationExpired(ExceptionCatchHandler.java:27)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.jboss.seam.solder.reflection.Reflections.invokeMethod(Reflections.java:535)
... 59 more
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Created: (WELD-834) URLScanner can not handle paths containing spaces
by Štěpán Mík (JIRA)
URLScanner can not handle paths containing spaces
-------------------------------------------------
Key: WELD-834
URL: https://issues.jboss.org/browse/WELD-834
Project: Weld
Issue Type: Bug
Components: Bootstrap and Metamodel API
Affects Versions: 1.1.0.Final
Environment: Windows, Jetty 7.2.2
Reporter: Štěpán Mík
When actual classpath includes folder that contains spaces, URLScanner throws an exception (java.io.FileNotFoundException). Problem is at line 93 where string holding URL is "converted" to path just by stripping URL scheme prefix. Unfortunately, spaces in URL are expressed either by plus sing or %20 escape sequence, which remains in file path instead of proper URL decoding. For example "file:/C:/with%20space" is converted to "/C:/with%20space" instead of "C:/with space".
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[JBoss JIRA] Created: (CDITCK-221) Synchronization bug in test<X>ScopeActiveDuringCallToEjbTimeoutMethod tests
by David Blevins (JIRA)
Synchronization bug in test<X>ScopeActiveDuringCallToEjbTimeoutMethod tests
---------------------------------------------------------------------------
Key: CDITCK-221
URL: https://issues.jboss.org/browse/CDITCK-221
Project: CDI TCK
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Tests
Affects Versions: 1.0.4.Final
Reporter: David Blevins
Waiting on either climbed or descended just tests that the timeout method was entered but does not guarantee the end of the method was reached and the proper state was set in the other variables. These tests will occasionally fail for this timing issue.
Though not fancy, this kind of synchronization can work. We just need to move these variables to the end of the timeout method. That will guarantee that when either climbed or descended are set to true the other variables are also in a testable state.
{code}
@Timeout
public void timeout(Timer timer)
{
if (beanManager.getContext(ApplicationScoped.class).isActive())
{
applicationScopeActive = true;
if (beanId > 0.0)
{
if (beanId == simpleApplicationBeanInstance.get().getId())
{
sameBean = true;
}
}
else
{
beanId = simpleApplicationBeanInstance.get().getId();
}
}
// applicationScopeActive, beanId and sameBean have been set and are testable
if (timer.getInfo().equals(CLIMB_COMMAND))
{
climbed = true;
}
if (timer.getInfo().equals(DESCEND_COMMAND))
{
descended = true;
}
}
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 1 month