I'm running REDHAWK 1.10 on a CentOS6.5 VM. I have the connection set to bridged and can locate the USRP by its IP address using: uhd_find_devices --args="addr= <ip address>"
I have a usrp2 with serial E5R1AS2UP
Here are the steps I take:
$ sudo $OSSIEHOME/bin/cleanomni
$ nodeBooter -D -debug 5
$ nodeBooter -d <location to USRP_UHD node>.xml -debug 5
I have also run these commands as requested by the USRP:
sudo sysctl -w net.core.rmem_max=50000000
sudo sysctl -w net.core.wmem_max=1048576
Relavant Console output thus far:
2014-08-22 15:31:43 DEBUG USRP_UHD_i:980 - target device hint contains 3 values
2014-08-22 15:31:43 DEBUG USRP_UHD_i:992 - Found 1 devices, choosing first one found.
-- Opening a USRP2/N-Series device...
-- Current recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
2014-08-22 15:31:45 DEBUG USRP_UHD_i:1107 - updateDeviceInfo|found 1 rx channels
2014-08-22 15:31:45 DEBUG USRP_UHD_i:1109 - updateDeviceInfo|found 1 tx channels
2014-08-22 15:31:45 DEBUG USRP_UHD_i:1144 - updateDeviceInfo|rx0|got clock rates [3.125e+06:1e+08]
2014-08-22 15:31:45 DEBUG USRP_UHD_i:1186 - updateDeviceInfo|tx0|got clock rates [3.125e+06:1e+08]
2014-08-22 15:31:45 DEBUG USRP_UHD_i:748 - targetDeviceChanged|device is not started, must start device after initialization
In the IDE, I click connect to REDHAWK_DEV, and start the device running under the custom node that I created.
By monitoring the ports of the USRP_UHD device, I see that my dataFloatTX_IN / dataShortTX_IN is 0 E/s as well as the rest of the columns, all of the other rows and columns are blank. This is strange since I want to RX and not TX; I had the FRONTEND::tune_allocation settings set to:
center freq = 9.91e7
bandwidth = 1.0e6
sample_rate = 1.0e6
tuner_type = RX_DIGITIZER
So then I tried using the steps outlined by pwolfram here: USRP_UHD source and sink for redhawk
I now have a waveform that contains a dataConverter as the assembly controller, AMFMDEMOD (2), and dataWriter (3). Running the waveform gives the error:
2014-08-22 14:46:25 ERROR ApplicationFactory_impl:1463 - Error in application creation; Failed to satisfy 'usesdevice' dependencies DCE:0dd76dd3-b44e-4e6a-b44a-896980682972for application 'USRP_Wave_234_134622508'
I saw that this was in the usesdevice line so I double checked to make sure that the usesdevice id is equal to the ID of the USRP_UHD device, and that the frontend ID and USRP ID both match the DCE in the properties view.
Trace of the issue:
2014-08-25 15:07:12 TRACE ComponentInfo:863 - Done building component info from file /components/DataWriter/DataWriter.spd.xml
2014-08-25 15:07:12 TRACE ApplicationFactory_impl:2132 - Done building Component Info From SPD File
2014-08-25 15:07:12 TRACE ComponentInfo:983 - Instantiation property id = overwrite
2014-08-25 15:07:12 TRACE prop_utils:167 - overriding simple property id overwrite
2014-08-25 15:07:12 DEBUG ComponentInfo:1033 - Attempting to override property overwrite
2014-08-25 15:07:12 DEBUG ComponentInfo:1036 - Overriding property overwrite with value 1
2014-08-25 15:07:12 DEBUG ComponentInfo:1033 - Attempting to override property overwrite
2014-08-25 15:07:12 DEBUG ComponentInfo:1033 - Attempting to override property overwrite
2014-08-25 15:07:12 DEBUG ComponentInfo:1033 - Attempting to override property overwrite
2014-08-25 15:07:12 TRACE ComponentInfo:983 - Instantiation property id = filename
2014-08-25 15:07:12 TRACE prop_utils:167 - overriding simple property id filename
2014-08-25 15:07:12 DEBUG ComponentInfo:1033 - Attempting to override property filename
2014-08-25 15:07:12 DEBUG ComponentInfo:1036 - Overriding property filename with value /home/Jovianite/Desktop/USRP_Wave
2014-08-25 15:07:12 DEBUG ComponentInfo:1033 - Attempting to override property filename
2014-08-25 15:07:12 DEBUG ComponentInfo:1033 - Attempting to override property filename
2014-08-25 15:07:12 DEBUG ComponentInfo:1033 - Attempting to override property filename
2014-08-25 15:07:12 TRACE ApplicationFactory_impl:1040 - Application has 1 usesdevice dependencies
2014-08-25 15:07:12 TRACE prop_utils:509 - setting struct item FRONTEND::tuner_allocation::allocation_id
2014-08-25 15:07:12 TRACE prop_utils:509 - setting struct item FRONTEND::tuner_allocation::bandwidth
2014-08-25 15:07:12 TRACE prop_utils:509 - setting struct item FRONTEND::tuner_allocation::center_frequency
2014-08-25 15:07:12 TRACE prop_utils:509 - setting struct item FRONTEND::tuner_allocation::group_id
2014-08-25 15:07:12 TRACE prop_utils:509 - setting struct item FRONTEND::tuner_allocation::rf_flow_id
2014-08-25 15:07:12 TRACE prop_utils:509 - setting struct item FRONTEND::tuner_allocation::sample_rate
2014-08-25 15:07:12 TRACE prop_utils:509 - setting struct item FRONTEND::tuner_allocation::tuner_type
2014-08-25 15:07:12 TRACE AllocationManager_impl:134 - Servicing 1 allocation request(s)
2014-08-25 15:07:12 TRACE AllocationManager_impl:144 - Allocation request DCE:d8e4147c-2c86-11e4-99d3-080027dc953e contains 3 properties
2014-08-25 15:07:12 TRACE AllocationManager_impl:243 - Allocating against device DCE:d7a37203-11f1-4643-b5f9-c5549b36b8d1
2014-08-25 15:07:12 TRACE AllocationManager_impl:353 - Matching DCE:cdc5ee18-7ceb-4ae6-bf4c-31f983179b4d 'FRONTEND::TUNER' eq 'FRONTEND'
2014-08-25 15:07:12 TRACE AllocationManager_impl:248 - Matching failed
2014-08-25 15:07:12 DEBUG ApplicationFactory_impl:1060 - Failed to satisfy 'usesdevice' dependencies DCE:d8e4147c-2c86-11e4-99d3-080027dc953efor application 'USRP_Wave_237_140642295'
2014-08-25 15:07:12 TRACE ApplicationFactory_impl:528 - Unbinding the naming context
2014-08-25 15:07:12 TRACE Properties:85 - Destruction for properties
2014-08-25 15:07:12 TRACE PRF:312 - Deleting PRF containing 7 properties
2014-08-25 15:07:12 TRACE Properties:85 - Destruction for properties
2014-08-25 15:07:12 TRACE PRF:312 - Deleting PRF containing 3 properties
2014-08-25 15:07:12 TRACE Properties:85 - Destruction for properties
2014-08-25 15:07:12 TRACE PRF:312 - Deleting PRF containing 4 properties
2014-08-25 15:07:12 ERROR ApplicationFactory_impl:1463 - Error in application creation; Failed to satisfy 'usesdevice' dependencies DCE:d8e4147c-2c86-11e4-99d3-080027dc953efor application 'USRP_Wave_237_140642295'
2014-08-25 15:07:12 INFO DomainManager_impl:1845 - Uninstalling application DCE:ca3d638e-b769-4bec-b950-4ff67c4e804e
Solution:
Next step is to make sure your GPP is running. The spd of the waveform needs to be edited as such:
<usesdevicedependencies>
<propertyref refid="DCE:<default value>" value="FRONTEND::TUNER"/>
The ::TUNER part needs to be added as it appears in your USRP_UHD properties tab.
Afterwards, you will have to adjust the values that you tune to based on whichever USRP you are using. The waveform then needs to be exported to the target sdr and then it can be launched. Using a trace on the node will tell you if your values need to be adjusted. I also removed the datawriter from the waveform because of how large the generated files were.
Related
I have a json having all the information of my project, its activities, dependencies / relationships and the calendar. Using the MPXJ java library am trying to generate a corresponding Primevera P6 XML file that can be imported in Oracle primevera. I have been successful in creating an xml but when I import it in P6 it is giving me the below error.
*Microsoft.Practices.Prism.Modularity.ModuleInitializeException: An exception occurred while initializing module 'CommandLineModule'.
The exception message was: Object reference not set to an instance of an object.
The Assembly that the module was trying to be loaded from was:
Primavera.Mercury.CommandLineModule, Version=15.2.0.15383, Culture=neutral, PublicKeyToken=null
Check the InnerException property of the exception for more information. If the exception occurred while creating an object in a DI container, you can exception.GetRootException() to help locate the root cause of the problem.
---> System.NullReferenceException: Object reference not set to an instance of an object.
at Primavera.Mercury.Importer.ImportCleaner.CleanupActivities(EntityContext sourceContext)
at Primavera.Mercury.Importer.ImportCleaner.CleanSourceContext(EntityContext sourceContext, IVenusDataServiceContext targetContext, ILoggerFacade logger, ImportProjectSettings importProjectSettings, Dictionary`2 initialKeyDictionary)
at Primavera.Mercury.CommandLineModule.ExecuteImportExport.DoImport()
at Microsoft.Practices.Prism.Modularity.ModuleInitializer.Initialize(ModuleInfo moduleInfo)
--- End of inner exception stack trace ---
Failed to load type for module CommandLineModule.
Error was: An exception occurred while initializing module 'CommandLineModule'.
- The exception message was: Object reference not set to an instance of an object.
- The Assembly that the module was trying to be loaded from was:Primavera.Mercury.CommandLineModule, Version=15.2.0.15383, Culture=neutral, PublicKeyToken=null
Check the InnerException property of the exception for more information. If the exception occurred while creating an object in a DI container, you can exception.GetRootException() to help locate the root cause of the problem.*
I'm using RedHawk 1.10.0 on CentOS 6.5_x64.
I installed UHD 3.7.2.0 in order to try to employ USRP, B100 0r USRP1, both linked by usb connection, on this fantastic framework!
I built new node using GPP and USRP_UHD device and everything seems going well(GPP and USRP_UHD status are STARTED).
Therefore I tried to allocate FrontEnd Tuner from DeviceManager>USRP_UHD>FrontEnd Tuner>Allocate.
After I filled every fields and I pushed Finish.
Every parameter referred to USRP is correct, except for Your Allocation ID in which I have some doubts.
I got this message on my screen:
'The allocation request was not accepted because resources matching all aspects of the request were not available'
and I got this message on the console(level of console debug:TRACE):
2014-09-05 17:10:39 TRACE FrontendTunerDevice:369 - CORBA::Boolean frontend::FrontendTunerDevice<TunerStatusStructType>::allocateCapacity(const CF::Properties&) [with TunerStatusStructType = frontend_tuner_status_struct_struct]
2014-09-05 17:10:39 INFO FrontendTunerDevice:502 - allocateCapacity: NO AVAILABLE TUNER. Make sure that the device has an initialized frontend_tuner_status
2014-09-05 17:10:39 TRACE FrontendTunerDevice:578 - void frontend::FrontendTunerDevice<TunerStatusStructType>::deallocateCapacity(const CF::Properties&) [with TunerStatusStructType = frontend_tuner_status_struct_struct]
2014-09-05 17:10:39 DEBUG FrontendTunerDevice:603 - ALLOCATION_ID NOT FOUND: [dspcola:f096df16-0179-478a-a539-6605a96c17b9]
2014-09-05 17:10:39 DEBUG FrontendTunerDevice:637 - ERROR WHEN DEALLOCATING. SKIPPING...
Can some good man help me?
Thanks
I have a waveform used to demodulate a signal received on an RTL device. Someone else created the waveform using REDHAWK 1.8.3 and it works fine for him. I am running REDHAWK 1.9 in a CentOS 6.3 virtual machine. I have reconfigured and rebuilt everything. When that did not work, I regenerated everything for 1.9 and rebuilt again and had the same result. I am able start the domain manager and device manager without error. When I try to instantiate an instance of the waveform, I get the following:
WARNING: Unable to set bandwidth.
INFO:RTLRDC_i - Allocated [FRONTEND::tuner_allocation] RX_DIGITIZER_CHANNELIZER, 0 to MC_Frontend
ERROR:PropertySet_impl - Setting property control failed. Cause: Unable to set value
ERROR:ApplicationFactory_impl - Failed to 'configure' component: 'MultiDemod' with component id: 'MultiDemod_1:MCWaveform_1 assigned to device: 'DCE:539804f4-37cc-426f-8dd0-3128d866981e' in waveform 'MCWaveform_1';InvalidConfiguration with this info: <No matching properties found> for these invalid properties: (control,Kind: 21) error occurred near line:3251 in file:ApplicationFactory_impl.cpp;
INFO:RTLRDC_i - Deallocated [FRONTEND::tuner_allocation] RX_DIGITIZER_CHANNELIZER, 0 for MC_Frontend
ERROR:ApplicationFactory_impl - Error in application creation; Configure of component failed (unclear where in the process this occurred)
The 'control' property does exist on the component. Does anyone have any thoughts on what the issue could be?
The control property is a struct. One of the fields in the struct did not have an initial value set. This was not an issue for REDHAWK 1.8.3 but caused the above error for REDHAWK 1.9. The solution was to make sure that all parameters for the struct had an initial value.
I am using Redhawk 1.9. I create a Redhawk Device, Component, Node, and Waveform with default settings. I use C++ implementation on all the above. The problem is that the device can't be allocated since it is not an executable device. In the implementation tab in the code section the "type" variable is set to "Executable" (default value). If this is incorrect then what should it be?
Note: When I make an Device derived from executable device then the problem goes away.
I was able to reproduce the problem with dummy device and component as shown below:
I update the Component so that it will use the device.
<usesdevice id="dummy_device_2" type="usesdevice">
<propertyref refid="DCE:cdc5ee18-7ceb-4ae6-bf4c-31f983179b4d" value="dummy_device_kind_1"/>
</usesdevice>
I update the device properties:
<simple id="DCE:cdc5ee18-7ceb-4ae6-bf4c-31f983179b4d" mode="readonly" name="device_kind" type="string">
<description>This specifies the device kind</description>
<value>dummy_device_kind_1</value>
<kind kindtype="configure"/>
<kind kindtype="allocation"/>
<action type="eq"/>
</simple>
I add the Dummy device created here into the dummy node created here.
I add the Dummy Component to the Dummy Waveform.
I launched the Dummy node that only contains the dummy device
I launched the Dummy waveform that only contains the above dummy device.
I get the following error message:
Failed to create application:
DeviceOnlyTestWaveform_343_114533234 The
following CORBA exception occurred: InvalidCapacity while creating the
application IDL:CF/ApplicationFactory/CreateApplicationError:1.0*
The Domain Manager (run with Trace logging) shows the following:
DEBUG:ApplicationFactory_impl - Trying to find the device
TRACE:ApplicationFactory_impl - Searching for a place to deploy component amongst 1 devices
TRACE:ApplicationFactory_impl - Checking Device DummyNode:DeviceOnlyTesTDevice_1
TRACE:ApplicationFactory_impl - Device DummyNode:DeviceOnlyTesTDevice_1 is loadable
TRACE:ApplicationFactory_impl - Device DummyNode:DeviceOnlyTesTDevice_1 is not loadable
TRACE:ApplicationFactory_impl - Done checking all the devices
DEBUG:ApplicationFactory_impl - Device Allocation Failed.. need to clean up
In ApplicationFactory_impl the code appear to show that the allocation fails since the device is not derived from Executable Device. The code section has "type" to Executable (default setting). If this is not correct then what should it be?
// Check that the device meet's the needs of this component
// - Validate the type of device meets the requirements in the 'code' section of the implementation
//
LOG_TRACE(ApplicationFactory_impl, "Checking Device " << deviceNodeIter->identifier);
if (deviceNodeIter->device->usageState() == CF::Device::BUSY)
{
LOG_TRACE(ApplicationFactory_impl, "Ignoring Device " <<deviceNodeIter->label << " is BUSY");
continue;
}
if ((implementation->getCodeType() == CF::LoadableDevice::EXECUTABLE) ||
(implementation->getCodeType() == CF::LoadableDevice::SHARED_LIBRARY)) {
// Does this device provide LoadableDevice?
LOG_TRACE(ApplicationFactory_impl, "Device " << deviceNodeIter->identifier << " is loadable");
CF::LoadableDevice_var loaddev;
loaddev = ossie::corba::_narrowSafe<CF::LoadableDevice> (deviceNodeIter->device);
if(CORBA::is_nil(loaddev)) {
LOG_TRACE(ApplicationFactory_impl, "Device " << deviceNodeIter->identifier << " is not loadable");
continue;
}
if (implementation->getEntryPoint().size() != 0) {
// Does this device provide ExecutableDevice?
LOG_TRACE(ApplicationFactory_impl, "Device " << deviceNodeIter->identifier << " is executable");
CF::ExecutableDevice_var execdev;
execdev = ossie::corba::_narrowSafe<CF::ExecutableDevice> (deviceNodeIter->device);
if(CORBA::is_nil(execdev)) {
LOG_INFO(ApplicationFactory_impl, "Device " << deviceNodeIter->identifier << " is not executable");
continue;
}
}
}
Although your device is capable of satisfying the usesdevice allocation, without a GPP or other ExecutableDevice, there is no place to run your component. There are two ways that allocation is performed when launching components:
Satisfying usesdevice relationships
Deciding on which device to deploy the executable
Each implementation in the component's SPD has a list of dependencies that must be satisfied to run the entry point. Typically, for a C++ component, this will include the OS and processor type. Additional requirements can be defined based on the processing requirements of the component, such as memory or load average; these must be allocation properties known to the target device, just like with usesdevice. There is also an implicit requirement that the device selected for deployment should support the ExecutableDevice interface (there is slightly more nuance to it, but that's by far the most common case).
When launching a waveform, the ApplicationFactory tries to allocate all required devices and select an implementation for each component in sequence. Each possible implementation is checked against all of the devices in the domain to see if there is a device that meets its dependencies. If so, the entry point for that implementation will be loaded onto the device and executed, and the ApplicationFactory moves on to the next component. If no suitable device can be found, it throws a CreateApplicationError, as you are seeing.
For most cases, you can use the GPP device included with REDHAWK to support the execution of your components. You would usually only write your own ExecutableDevice if you have a specific type of hardware that does not work with GPP, like an FPGA. If you have installed from RPM, there should be a node tailored to your local system (e.g., processor type, Java and Python versions) in your $SDRROOT/dev/nodes directory. Otherwise you can create it yourself with the 'nodeconfig.py' script included with the GPP project; see the Ubuntu installation guide for an example (admittedly, somewhat buried in the REDHAWK Manual, Appendix E, Section 5).
I believe the problem is that you don't have a GPP in the node with your Dummy Device. Because your original Device was not Executable, it was unable to execute the Component's code, which is what the GPP would do for you.
To add the GPP in the IDE, simply open up the DeviceManager.dcd.xml file of your Node, navigate to the Devices tab, and click the Add button. If everything is installed correctly, you should be able to select the GPP, then click Finish. Finally, save the Node and drag it to Target SDR and try launching it with nodeBooter again.
Also, the type "Executable" in the *.spd.xml file isn't specific to Devices. If you look at the implementation section for a Component, you'll notice there is a Type drop down under the Code section as well. The reason for this is because it isn't describing the type of Device/Component, but how the output of the build process should be interpreted.
I am trying to get some of the demo's working, but have been having problems. I am using Tomcat 7 + MySql. When I try to the jsf2 portlet demo found at: http://repository.portletfaces.org/content/repositories/liferay-releases/com/liferay/faces/demos/jsf2-portlet/3.1.0-rc2/jsf2-portlet-3.1.0-rc2.war my logs (configured for log4j) show it gets registered but is immediately unregistered. I have no idea why and am not seeing any reason in the log. I would appreciate any help.
The log entry in question is: "04:17:55,430 INFO [PortletHotDeployListener:470] Unregistering portlets for jsf2-portlet".
Here are the ones leading to the one above.
04:17:53,693 DEBUG [BridgeConfigImpl:223] Processing faces-config: [/WEB-INF/faces-config.xml]
04:17:53,694 DEBUG [BridgeConfigImpl:296] Processing web-app: [/WEB-INF/web.xml]
04:17:53,695 DEBUG [BridgeConfigImpl:306] Processing web-app: [/WEB-INF/liferay-web.xml]
04:17:53,699 DEBUG [BridgeConfigImpl:341] Added implicit extension-mapped servlet-mapping for urlPattern=[*.xhtml]
04:17:53,699 DEBUG [BridgeConfigImpl:341] Added implicit extension-mapped servlet-mapping for urlPattern=[*.jsp]
04:17:53,713 INFO [PortletHotDeployListener:433] 1 portlet for jsf2-portlet is available for use
04:17:55,418 INFO [PluginPackageUtil:1099] Reading plugin package for jsf2-portlet
04:17:55,430 INFO [PortletHotDeployListener:470] Unregistering portlets for jsf2-portlet
**04:17:55,437 INFO [PortletHotDeployListener:503] 1 portlet for jsf2-portlet was unregistered**
The full log can be seen below.:
04:17:53,183 INFO [PluginPackageUtil:1099] Reading plugin package for jsf2-portlet
04:17:53,469 INFO [PortletHotDeployListener:614] Registering portlets for jsf2-portlet
04:17:53,511 INFO [BridgeImpl] Initializing Liferay Faces Bridge 3.1.0-rc2 (Galatia / Jul 14, 2012 AD)
04:17:53,592 DEBUG [BridgeConfigImpl:168] Pre-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/lib/weld-servlet.jar!/META-INF/faces-config.xml]
04:17:53,598 DEBUG [BridgeConfigImpl:168] Pre-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/lib/ext/resin.jar!/META-INF/faces-config.xml]
04:17:53,599 DEBUG [BridgeConfigImpl:168] Pre-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/webapps/jsf2-portlet/WEB-INF/lib/liferay-faces-alloy-3.1.0-rc2.jar!/META-INF/faces-config.xml]
04:17:53,600 DEBUG [BridgeConfigImpl:168] Pre-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/webapps/jsf2-portlet/WEB-INF/lib/liferay-faces-bridge-impl-3.1.0-rc2.jar!/META-INF/faces-config.xml]
04:17:53,601 DEBUG [BridgeConfigImpl:168] Pre-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/webapps/jsf2-portlet/WEB-INF/lib/util-taglib.jar!/META-INF/faces-config.xml]
04:17:53,602 DEBUG [BridgeConfigImpl:202] Post-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/webapps/jsf2-portlet/WEB-INF/lib/liferay-faces-bridge-impl-3.1.0-rc2.jar!/META-INF/faces-config.xml]
04:17:53,603 DEBUG [BridgeConfigImpl:802] render-response-wrapper-class=[com.liferay.faces.bridge.application.view.BridgeWriteBehindResponseRenderImpl]
04:17:53,604 DEBUG [BridgeConfigImpl:806] resource-response-wrapper-class=[com.liferay.faces.bridge.application.view.BridgeWriteBehindResponseResourceImpl]
04:17:53,609 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,609 DEBUG [BridgeConfigImpl:592] Instantiated bridgeContextFactory=[com.liferay.faces.bridge.context.BridgeContextFactoryImpl] wrappedFactory=[null]
04:17:53,615 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,622 DEBUG [BridgeConfigImpl:612] Instantiated bridgeFlashFactory=[com.liferay.faces.bridge.context.flash.BridgeFlashFactoryImpl] wrappedFactory=[null]
04:17:53,624 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,624 DEBUG [BridgeConfigImpl:632] Instantiated bridgePhaseFactory=[com.liferay.faces.bridge.BridgePhaseFactoryImpl] wrappedFactory=[null]
04:17:53,626 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,663 DEBUG [BridgeConfigImpl:652] Instantiated BridgeRequestScopeFactory=[com.liferay.faces.bridge.scope.BridgeRequestScopeFactoryImpl] wrappedFactory=[null]
04:17:53,665 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,666 DEBUG [BridgeConfigImpl:673] Instantiated BridgeRequestScopeCacheFactory=[com.liferay.faces.bridge.scope.BridgeRequestScopeCacheFactoryImpl] wrappedFactory=[null]
04:17:53,668 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,669 DEBUG [BridgeConfigImpl:695] Instantiated BridgeRequestScopeManagerFactory=[com.liferay.faces.bridge.scope.BridgeRequestScopeManagerFactoryImpl] wrappedFactory=[null]
04:17:53,671 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,672 DEBUG [BridgeConfigImpl:717] Instantiated BridgeWriteBehindResponseFactory=[com.liferay.faces.bridge.application.view.BridgeWriteBehindResponseFactoryImpl] wrappedFactory=[null]
04:17:53,676 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,677 DEBUG [BridgeConfigImpl:737] Instantiated BridgeURLFactory=[com.liferay.faces.bridge.context.url.BridgeURLFactoryImpl] wrappedFactory=[null]
04:17:53,683 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,684 DEBUG [BridgeConfigImpl:789] Instantiated PortletContainerFactory=[com.liferay.faces.bridge.container.PortletContainerFactoryImpl] wrappedFactory=[null]
04:17:53,686 DEBUG [BridgeConfigImpl:39] Creating instance with zero-arg constructor since wrapperConstructor=null
04:17:53,687 DEBUG [BridgeConfigImpl:817] Instantiated UploadedFileFactory=[com.liferay.faces.bridge.model.UploadedFileFactoryImpl] wrappedFactory=[null]
04:17:53,688 DEBUG [BridgeConfigImpl:202] Post-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/lib/weld-servlet.jar!/META-INF/faces-config.xml]
04:17:53,690 DEBUG [BridgeConfigImpl:202] Post-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/lib/ext/resin.jar!/META-INF/faces-config.xml]
04:17:53,691 DEBUG [BridgeConfigImpl:202] Post-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/webapps/jsf2-portlet/WEB-INF/lib/liferay-faces-alloy-3.1.0-rc2.jar!/META-INF/faces-config.xml]
04:17:53,692 DEBUG [BridgeConfigImpl:202] Post-processing faces-config: [jar:file:/usr/local/LiferayTomcat/liferay-portal-6.1.0-ce-ga1/apache-tomcat-7.0.27/webapps/jsf2-portlet/WEB-INF/lib/util-taglib.jar!/META-INF/faces-config.xml]
04:17:53,693 DEBUG [BridgeConfigImpl:223] Processing faces-config: [/WEB-INF/faces-config.xml]
04:17:53,694 DEBUG [BridgeConfigImpl:296] Processing web-app: [/WEB-INF/web.xml]
04:17:53,695 DEBUG [BridgeConfigImpl:306] Processing web-app: [/WEB-INF/liferay-web.xml]
04:17:53,699 DEBUG [BridgeConfigImpl:341] Added implicit extension-mapped servlet-mapping for urlPattern=[*.xhtml]
04:17:53,699 DEBUG [BridgeConfigImpl:341] Added implicit extension-mapped servlet-mapping for urlPattern=[*.jsp]
04:17:53,713 INFO [PortletHotDeployListener:433] 1 portlet for jsf2-portlet is available for use
04:17:55,418 INFO [PluginPackageUtil:1099] Reading plugin package for jsf2-portlet
04:17:55,430 INFO [PortletHotDeployListener:470] Unregistering portlets for jsf2-portlet
**04:17:55,437 INFO [PortletHotDeployListener:503] 1 portlet for jsf2-portlet was unregistered**
The behavior you describe usually means that there's still an exception that occurs, it just isn't being logged correctly by Liferay. What works for me most of the times is to add a logging.properties file to the WEB-INF/classes directory of my portlet and give it the following content:
handlers = org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
org.apache.juli.FileHandler.level = FINE
org.apache.juli.FileHandler.directory = ${catalina.base}/logs
org.apache.juli.FileHandler.prefix = catalina.
java.util.logging.ConsoleHandler.level = FINE
java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
After deploying this new WAR you should hopefully see additional logging that should help you find the cause of the failed deployment.