[JBoss JIRA] Created: (GTNPORTAL-1646) during shutdown, the PortalContainer throws a PicoIntrospectionException
by Matt Wringe (JIRA)
during shutdown, the PortalContainer throws a PicoIntrospectionException
------------------------------------------------------------------------
Key: GTNPORTAL-1646
URL: https://jira.jboss.org/browse/GTNPORTAL-1646
Project: GateIn Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Matt Wringe
When stopping the server (JBoss version of GateIn), I am sometimes running into the following error:
18:45:06,686 ERROR [STDERR] Exception in thread "Thread-17"
18:45:06,689 ERROR [STDERR] org.picocontainer.PicoIntrospectionException: Failed when calling stop on org.exoplatform.container.PortalContainer@170cd3b6
18:45:06,689 ERROR [STDERR] at org.picocontainer.defaults.LifecycleVisitor.traverse(LifecycleVisitor.java:81)
18:45:06,689 ERROR [STDERR] at org.picocontainer.defaults.LifecycleVisitor.stop(LifecycleVisitor.java:121)
18:45:06,689 ERROR [STDERR] at org.exoplatform.container.ConcurrentPicoContainer.stop(ConcurrentPicoContainer.java:468)
18:45:06,689 ERROR [STDERR] at org.exoplatform.container.ExoContainer.stop(ExoContainer.java:194)
18:45:06,689 ERROR [STDERR] at org.exoplatform.container.RootContainer.stop(RootContainer.java:655)
18:45:06,689 ERROR [STDERR] at org.exoplatform.container.RootContainer$ShutdownThread.run(RootContainer.java:649)
18:45:06,689 ERROR [STDERR] Caused by: org.picocontainer.PicoIntrospectionException: Failed when calling stop on org.gatein.portal.wsrp.WSRPServiceIntegration@37b96ed
18:45:06,689 ERROR [STDERR] at org.picocontainer.defaults.LifecycleVisitor.traverse(LifecycleVisitor.java:81)
18:45:06,689 ERROR [STDERR] at org.picocontainer.defaults.LifecycleVisitor.stop(LifecycleVisitor.java:121)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] Created: (GTNPORTAL-1513) Gadgets become unavailable from JCR after multiple edits.
by Jon Kranes (JIRA)
Gadgets become unavailable from JCR after multiple edits.
---------------------------------------------------------
Key: GTNPORTAL-1513
URL: https://jira.jboss.org/browse/GTNPORTAL-1513
Project: GateIn Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: JCR integration
Affects Versions: 3.1.0-GA
Environment: Windows XP, JBoss AS 5.1.
Reporter: Jon Kranes
After editing a gadget's XML multiple times, the gadget becomes unavailable. The gadget still appears in the Application Registry, but any page where the gadget is embedded shows a 404 error. If you try to delete or edit the gadget, the system responds with an error dialog with the message 'Unknown error'. If you paste the gadget's 'View URL' into a browser, the response indicates a java.io.FileNotFoundException.
The number of edits allowed before the error occurs is not consistent but seems to generally be in the range of 10 - 20.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] Created: (GTNPORTAL-1727) Overriding configuration unit in AbstractKernelTest
by Minh Hoang TO (JIRA)
Overriding configuration unit in AbstractKernelTest
---------------------------------------------------
Key: GTNPORTAL-1727
URL: https://issues.jboss.org/browse/GTNPORTAL-1727
Project: GateIn Portal
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Minh Hoang TO
Assignee: Minh Hoang TO
Creating JUnit test in GateIn from scratch is very complex due to numbers of service component configurations. That 's why the project test.core provides AbstractKernelTest, the class overriding services configuration loading ( custom class loader GateinTestClassLoader is set as context class loader of thread running test, service configuration is retrieved from paths defined in annotation @ConfigurationUnit)
As the annotation @ConfiguredBy is also @Inherited, that makes default service configuration appears in all test unit, even when unnecessary. That slows down test running for sure.
It might be better to define @OverridingConfigurationUnit annotation, processed by AbstractKernelTest to remove service component configuration when it is not used for JUnit test.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] Created: (GTNPORTAL-1728) Define fine-grained test configuration in test.core
by Minh Hoang TO (JIRA)
Define fine-grained test configuration in test.core
---------------------------------------------------
Key: GTNPORTAL-1728
URL: https://issues.jboss.org/browse/GTNPORTAL-1728
Project: GateIn Portal
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Minh Hoang TO
Assignee: Minh Hoang TO
The project test.core does provide default configuration of GateIn services. Anyway, the configuration of independent services are not declared in seperated .xml files, so to create a new JUnit test extending AbstractKernelTest, developer has only two choices:
1. Reuse the existing configuration, which means having all GateIn service components for the test
2. Reconfigure from scratch, which is error-prone and time consuming
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] Created: (GTNPORTAL-1052) configuration of oauth for signed request
by jerem j (JIRA)
configuration of oauth for signed request
-----------------------------------------
Key: GTNPORTAL-1052
URL: https://jira.jboss.org/jira/browse/GTNPORTAL-1052
Project: GateIn Portal
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Affects Versions: 3.0.0-GA
Reporter: jerem j
In gadget, you can do request to an oAuth endpoint.
In some case, the distant server want to make sure who is the server (or developer) doing the request. To do so, they provide a oauth consumer key and a oauth consumer secret. You need to associate this with your gadget. So everytime your gadget is going to do request to their server, it will use this keys.
For example, google is using such a mechanism to protect their analytics APIs. You need to register a domain on https://www.google.com/accounts/ManageDomains and google will give you the OAuth Consumer Key and OAuth Consumer Secret.
The problem is that to configure this now, you need to modify the file oauth.json that is located in jar.
It's something similar to what has been done for http://jira.exoplatform.org/browse/SOC-650 but the properties are different:
* Gadget URL
* oAuth endpoint name (used in the gadget to reference this endpoint)
* consumer_key
* consumer_secret
* key_type
Also a UI to configure this would be awesome.
--
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, 5 months