Creating Azure storage table on asp.net MVC - asp.net-mvc

I'm following this blog post to create an azure storage table:
http://blogs.msdn.com/jnak/archive/2008/10/28/walkthrough-simple-table-storage.aspx
It works fine on an asp.net webform web_role.
I've re-created the same project using asp.net mvc as the web role, and it's always failing on application start. this line:
StorageAccountInfo account = StorageAccountInfo.GetDefaultTableStorageAccountFromConfiguration();
seem to always fail getting the account shared key.
If I move the line from global asax application start to default.aspx, it works perfectly fine.
Is there any difference in initializing a storage table in azure asp.net mvc compared to webform?
Why can't I get the azure appsettings on application start?
This is the error call stack from event viewer
Exception information:
Exception type: HttpException
Exception message: No account key specified!
Request information:
Request URL: http://127.0.0.1:5100/do.__rd_runtime_init__?shutdownEvent=1B671B93FD-4153-4834-9D5D-595EFC6C19EE1D
Request path: /do.__rd_runtime_init__
User host address: 127.0.0.1
User:
Is authenticated: False
Authentication Type:
Thread account name: *****
Thread information:
Thread ID: 6
Thread account name: *****
Is impersonating: False
Stack trace: at System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app)
at System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers)
at System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context)
at System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context)
at System.Web.HttpApplicationFactory.GetPipelineApplicationInstance(IntPtr appContext, HttpContext context)
at System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext)

Check out the "remarks" at http://msdn.microsoft.com/en-us/library/microsoft.servicehosting.serviceruntime.rolemanager.aspx:
The Windows Azure fabric runs IIS 7.0
in integrated mode. In integrated
mode, the Application_Start event does
not support access to the request
context or to the members of the
RoleManager class provided by the
Windows Azure SDK runtime API. If you
are writing an ASP.NET application
that accesses the request context or
calls methods of the RoleManager class
from the Application_Start event, you
should modify it to initialize in the
Application_BeginRequest event
instead.
For an example that shows how to use
the Application_BeginRequest event,
see the PersonalWebSite Sample that
ships with the Windows Azure SDK.

If you use:
StorageAccountInfo account = StorageAccountInfo.GetDefaultTableStorageAccountFromConfiguration();
Usually the account information is given in the Web.conf file.
<add key="TableStorageEndpoint" value="http://127.0.0.1:10002/devstoreaccount1" />
<add key="AccountName" value="devstoreaccount1" />
<add key="AccountSharedKey" value="YOUR ACCOUNT KEY PROVIDED BY AZURE"/>

Related

ADFS SAML Identity provider redirects to service provider with status "Responder"

I am using omniauth-saml to authenticate users on a Ruby on Rails application.
Authentication has worked well, until we stated attempting to work with companies using ADFS (Windows Active Directory).
Our Application is able to route to the ADFS log-in screen, the log-in operation takes place, and when ADFS redirects back to our application, we are presented with the error message:
The status code of the Response was not Success, was Responder
debugging, we can see that omniauth-saml is what generates this message.
digging though the payload sent to our application, the "SAMLResponse" attribute contains a xml document with the following part:
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder" /></samlp:Status>
which we believe is related to the error message presented by omniauth-saml.
ADFS is noticeable hard to debug, but we believe the following error messages is what is behind this ordeal:
Additional Data
Protocol Name:
Saml
Relying Party:
https://our-domain/users/auth/saml/metadata?attr1=123&attr2=432
Exception details:
Microsoft.IdentityModel.SecurityTokenService.InvalidScopeException: MSIS3055: The requested relying party trust 'https://our-domain/users/auth/saml/metadata' is unspecified or unsupported. If a relying party trust was specified, it is possible the user does not have permission to access the relying party trust. ---> Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.ScopeNotFoundPolicyRequestException: MSIS3020: The relying party trust with identifier 'https://our-domain/users/auth/saml/metadata' could not be located.
--- End of inner exception stack trace ---
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet, List`1 additionalClaims)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, List`1 additionalClaims)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolManager.Issue(HttpSamlRequestMessage httpSamlRequestMessage, SecurityTokenElement onBehalfOf, String sessionState, String relayState, String& newSamlSession, String& samlpAuthenticationProvider, Boolean isUrlTranslationNeeded, WrappedHttpListenerContext context, Boolean isKmsiRequested)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.RequestBearerToken(WrappedHttpListenerContext context, HttpSamlRequestMessage httpSamlRequest, SecurityTokenElement onBehalfOf, String relyingPartyIdentifier, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired, String& samlpSessionState, String& samlpAuthenticationProvider)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.BuildSignInResponseCoreWithSerializedToken(HttpSamlRequestMessage httpSamlRequest, WrappedHttpListenerContext context, String relyingPartyIdentifier, SecurityTokenElement signOnTokenElement, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.BuildSignInResponseCoreWithSecurityToken(SamlSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.Process(ProtocolContext context)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.ScopeNotFoundPolicyRequestException: MSIS3020: The relying party trust with identifier 'https://our-domain/users/auth/saml/metadata' could not be located.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="AD FS" Guid="{2ffb687a-1571-4ace-8550-47ab5ccae2bc}" />
<EventID>364</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000001</Keywords>
<TimeCreated SystemTime="2019-10-15T23:15:19.254339300Z" />
<EventRecordID>1512764</EventRecordID>
<Correlation ActivityID="{19de3423-ee29-40a8-890d-0080000000bf}" />
<Execution ProcessID="752" ThreadID="4076" />
<Channel>AD FS/Admin</Channel>
<Computer>serve-name.domain</Computer>
<Security UserID="S-1-5-21-1708537768-1844237615-682003330-107716" />
</System>
<UserData>
<Event xmlns="http://schemas.microsoft.com/ActiveDirectoryFederationServices/2.0/Events">
<EventData>
<Data>Saml</Data>
<Data>https://our-domain/users/auth/saml/metadata?attr1=123&attr2=432</Data>
<Data>Microsoft.IdentityModel.SecurityTokenService.InvalidScopeException: MSIS3055: The requested relying party trust 'https://our-domain/users/auth/saml/metadata' is unspecified or unsupported. If a relying party trust was specified, it is possible the user does not have permission to access the relying party trust. ---> Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.ScopeNotFoundPolicyRequestException: MSIS3020: The relying party trust with identifier 'https://our-domain/users/auth/saml/metadata' could not be located.
--- End of inner exception stack trace ---
at Microsoft.IdentityModel.Threading.AsyncResult.End(IAsyncResult result)
at Microsoft.IdentityModel.Threading.TypedAsyncResult`1.End(IAsyncResult result)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, IList`1& identityClaimSet, List`1 additionalClaims)
at Microsoft.IdentityServer.Web.WSTrust.SecurityTokenServiceManager.Issue(RequestSecurityToken request, List`1 additionalClaims)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolManager.Issue(HttpSamlRequestMessage httpSamlRequestMessage, SecurityTokenElement onBehalfOf, String sessionState, String relayState, String& newSamlSession, String& samlpAuthenticationProvider, Boolean isUrlTranslationNeeded, WrappedHttpListenerContext context, Boolean isKmsiRequested)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.RequestBearerToken(WrappedHttpListenerContext context, HttpSamlRequestMessage httpSamlRequest, SecurityTokenElement onBehalfOf, String relyingPartyIdentifier, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired, String& samlpSessionState, String& samlpAuthenticationProvider)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.BuildSignInResponseCoreWithSerializedToken(HttpSamlRequestMessage httpSamlRequest, WrappedHttpListenerContext context, String relyingPartyIdentifier, SecurityTokenElement signOnTokenElement, Boolean isKmsiRequested, Boolean isApplicationProxyTokenRequired)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.BuildSignInResponseCoreWithSecurityToken(SamlSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
at Microsoft.IdentityServer.Web.Protocols.Saml.SamlProtocolHandler.Process(ProtocolContext context)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.ScopeNotFoundPolicyRequestException: MSIS3020: The relying party trust with identifier 'https://our-domain/users/auth/saml/metadata' could not be located.
</Data>
</EventData>
</Event>
</UserData>
</Event>
My understanding of ADFS is limited, so I'm not sure if the errors were caused by ADFS misconfiguration or by something specific we would need to add to our application to make it work with ADFS...
Your help would be appreciated!
The RP with identifier "https://our-domain/users/auth/saml/metadata" does not exist in ADFS.
How did you configure the ADFS RP? Did you use metadata?
The RP should have the above identifier in the "Identifier" tab when you view it via the ADFS wizard.
As it turns out the answer was to provide an alternative url for ADFS to retrieve the SAML metadata file from our system.
It seems ADFS cannot handle having query strings into its "relying party trust" "Federation metadata file location" (this ADFS jargon is killing me ...)
anyway, once the url could be used without query strings, all worked fine.
We moved the parameters to be part of the url:
instead of
https://our-domain/users/auth/saml/metadata?attr1=123&attr2=432
we monkey-patched omniauth-saml and used a new url so we could provide the same functionality with the alternative url:
https://our-domain/users/auth/saml/:attr1/:attr2/metadata

WebSecurity.InitializeDatabaseConnection method can be called only once

I'm trying Windows Azure to host an MVC4 web application.
I've created a test app, using VS2012 MVC4 internet application template and added a custom Model and Controller to it.
I've published it on Azure and managed to get 'update-database' apply migrations to the Azure Database.
When i try the app locally, but using the Azure SQL database, it works fine.
I can login/register and use my test controller.
When i try the app online, i can use the test controller but login or register links give the following exception:
Server Error in '/' Application.
The "WebSecurity.InitializeDatabaseConnection" method can be called only once.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.InvalidOperationException: The "WebSecurity.InitializeDatabaseConnection" method can be called only once.
Source Error:
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
Stack Trace:
[InvalidOperationException: The "WebSecurity.InitializeDatabaseConnection" method can be called only once.]
WebMatrix.WebData.WebSecurity.InitializeMembershipProvider(SimpleMembershipProvider simpleMembership, DatabaseConnectionInfo connect, String userTableName, String userIdColumn, String userNameColumn, Boolean createTables) +123
WebMatrix.WebData.WebSecurity.InitializeProviders(DatabaseConnectionInfo connect, String userTableName, String userIdColumn, String userNameColumn, Boolean autoCreateTables) +51
WebMatrix.WebData.WebSecurity.InitializeDatabaseConnection(String connectionStringName, String userTableName, String userIdColumn, String userNameColumn, Boolean autoCreateTables) +52
MembershipTest2.Filters.SimpleMembershipInitializer..ctor() +193
Do you have any idea where that comes from ?
If i debug (the local version), this method is only called once.
Thanks.
You could try encapsulating the call(s) to that method to ensure it's not called more then once
if (!WebMatrix.WebData.WebSecurity.Initialized)
{
WebSecurity.InitializeDatabaseConnection(...);
}
in my case I had both
(in web.config)
<add key="enableSimpleMembership" value="true" />
and
(in _ViewStart.cshtml)
WebSecurity.InitializeDatabaseConnection("club", "Account", "UserID", "UserName", autoCreateTables: true);
Solution: it seems you cannot have both, so remove one
Does the following SO discussion help you?
Cannot seed Users & Roles
I did find the following article helped me lot to use newer MVC4 & EF together with Simple Membership Provider so if you haven't read it please take a look:
SimpleMembership, Membership Providers, Universal Providers and the new ASP.NET 4.5 Web Forms and ASP.NET MVC 4 templates

DynamicData RegisterContext error using multiple edmx

Before posting this I made sure to read all suggestion made from SO.
The application currently has two projects one for the web application and one for the Entity Frame work (version 4.0). We are trying a tool from RSSBus for the Quickbooks Provider description here
Setting it up was easy enough. I prefixed QB on all the entities and generated the QB.tt file, no issues. Both edmx files are housed in the same project using a shared namespace (SMR.Model)
When I rebuilt the project to run it the global.asax.cs file threw an error:
DefaultModel.RegisterContext(typeof(SMR.Model.SMREntities),
new ContextConfiguration() { ScaffoldAllTables = true });
The error given was:
The given key was not present in the dictionary.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary.
Source Error:
Line 36: public static void RegisterRoutes(RouteCollection routes)
Line 37: {
Line 38: DefaultModel.RegisterContext(typeof(SMR.Model.SMREntities),
Line 39: new ContextConfiguration() { ScaffoldAllTables = true });
Line 40:
Source File: C:\all\src\smr\smr.pl.Web\Global.asax.cs Line: 38
Stack Trace:
[KeyNotFoundException: The given key was not present in the dictionary.]
System.Collections.Generic.Dictionary2.get_Item(TKey key) +9624829
System.Web.DynamicData.ModelProviders.EFDataModelProvider..ctor(Object contextInstance, Func1 contextFactory) +800
System.Web.DynamicData.ModelProviders.SchemaCreator.CreateDataModel(Object contextInstance, Func1 contextFactory) +126
System.Web.DynamicData.MetaModel.RegisterContext(Func1 contextFactory, ContextConfiguration configuration) +378
System.Web.DynamicData.MetaModel.RegisterContext(Type contextType, ContextConfiguration configuration) +88
smr.pl.Web.Global.RegisterRoutes(RouteCollection routes) in C:\all\src\smr\smr.pl.Web\Global.asax.cs:38
smr.pl.Web.Global.Application_Start(Object sender, EventArgs e) in C:\all\src\smr\smr.pl.Web\Global.asax.cs:91
[HttpException (0x80004005): The given key was not present in the dictionary.]
System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext context, HttpApplication app) +9170941
System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr appContext, HttpContext context, MethodInfo[] handlers) +131
System.Web.HttpApplication.InitSpecial(HttpApplicationState state, MethodInfo[] handlers, IntPtr appContext, HttpContext context) +194
System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr appContext, HttpContext context) +339
System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr appContext) +253
[HttpException (0x80004005): The given key was not present in the dictionary.]
System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +9090044
System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +97
System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +256
With so little to go on as to what could eb the problem I looked at the .config files to see if they were wrong and all checked out as ok.
<add name="SMREntities" connectionString="metadata=res://*/;provider=System.Data.SqlClient;provider connection string="Data Source=localhost;Initial Catalog=SMR;Persist Security Info=True;User ID=sa;Password=XXX;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient"/>
<add name="RSSQBEntities" connectionString="metadata=res://*/Model.QBOE.csdl|res://*/Model.QBOE.ssdl|res://*/Model.QBOE.msl;provider=System.Data.RSSBus.QuickBooks;provider connection string="Offline=False;Application Id=987654321;Connection Ticket=TGT-000-T_xxxxxxxxxxxxxxxxxxxx;Online Login=ohno"" providerName="System.Data.EntityClient" />
Any thoughts as to what is causing the structure to fail like this?
I finally figured out the "real" problem. I first seperated the two models into separate projects. The problem I was facing was the metadata was being integrated into the same assembly namespace. I resolved my issue by updating the res://*/ section
<add name="SMREntities" connectionString="metadata=res://SMR.Model/;provider=System.Data.SqlClient;provider connection string="Data Source=localhost;Initial Catalog=SMR;Persist Security Info=True;User ID=sa;Password=XXX;MultipleActiveResultSets=True"" providerName="System.Data.EntityClient"/>
<add name="RSSQBEntities" connectionString="metadata=res://SMR.QBOE/Model.RSSQBOE.csdl|res://SMR.QBOE/Model.RSSQBOE.ssdl|res://SMR.QBOE/Model.RSSQBOE.msl;provider=System.Data.RSSBus.QuickBooks;provider connection string="Offline=False;Application Id=987654321;Connection Ticket=TGT-000-T_xxxxxxxxxxxxxxxxxxxx;Online Login=ohno"" providerName="System.Data.EntityClient" />
A Classic "the issue is not the issue".

RavenDB deployment issue

I have an ASP.Net MVC 3 app that I've developed which uses RavenDB Embedded as an integrated backing store for data, I used this tutorial as a basis for getting started creating an MVC app with RavenDB Embedded. I've been able to run it fine on my development PC, but when it came time to deploy it on our Windows Server 2003 web server running IIS6 it threw the following error:
Cannot access file, the file is locked or in use Description: An
unhandled exception occurred during the execution of the current web
request. Please review the stack trace for more information about the
error and where it originated in the code.
Exception Details:
Microsoft.Isam.Esent.Interop.EsentFileAccessDeniedException: Cannot
access file, the file is locked or in use
Source Error:
An unhandled exception was generated during the execution of the
current web request. Information regarding the origin and location of
the exception can be identified using the exception stack trace below.
Stack Trace:
[EsentFileAccessDeniedException: Cannot access file, the file is
locked or in use] Microsoft.Isam.Esent.Interop.Api.Check(Int32 err)
in
C:\Work\ravendb\SharedLibs\Sources\managedesent-61618\EsentInterop\Api.cs:2736
Raven.Storage.Esent.TransactionalStorage.Initialize(IUuidGenerator
uuidGenerator) in
c:\Builds\RavenDB-Stable\Raven.Storage.Esent\TransactionalStorage.cs:207
[InvalidOperationException: Could not open transactional storage:
C:\inetpub\wwwroot\MyApp\App_Data\Database\RavenDB\Data]
Raven.Storage.Esent.TransactionalStorage.Initialize(IUuidGenerator
uuidGenerator) in
c:\Builds\RavenDB-Stable\Raven.Storage.Esent\TransactionalStorage.cs:222
Raven.Database.DocumentDatabase..ctor(InMemoryRavenConfiguration
configuration) in
c:\Builds\RavenDB-Stable\Raven.Database\DocumentDatabase.cs:185
Raven.Client.Embedded.EmbeddableDocumentStore.InitializeInternal() in
c:\Builds\RavenDB-Stable\Raven.Client.Embedded\EmbeddableDocumentStore.cs:143
Raven.Client.Document.DocumentStore.Initialize() in
c:\Builds\RavenDB-Stable\Raven.Client.Lightweight\Document\DocumentStore.cs:496
MyApp.CompositionRoot.CreateControllerFactory() in
...\MyApp\CompositionRoot.cs:36 MyApp.CompositionRoot..ctor() in
..\MyApp\CompositionRoot.cs:17
MyApp.MvcApplication.Application_Start() in ...MyApp\Global.asax.cs:38
[HttpException (0x80004005): Could not open transactional storage:
C:\inetpub\wwwroot\MyApp\App_Data\Database\RavenDB\Data]
System.Web.HttpApplicationFactory.EnsureAppStartCalledForIntegratedMode(HttpContext
context, HttpApplication app) +3985477
System.Web.HttpApplication.RegisterEventSubscriptionsWithIIS(IntPtr
appContext, HttpContext context, MethodInfo[] handlers) +191
System.Web.HttpApplication.InitSpecial(HttpApplicationState state,
MethodInfo[] handlers, IntPtr appContext, HttpContext context) +325
System.Web.HttpApplicationFactory.GetSpecialApplicationInstance(IntPtr
appContext, HttpContext context) +407
System.Web.Hosting.PipelineRuntime.InitializeApplication(IntPtr
appContext) +375
[HttpException (0x80004005): Could not open transactional storage:
C:\inetpub\wwwroot\MyApp\App_Data\Database\RavenDB\Data]
System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +11524352
System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context)
+141 System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest
wr, HttpContext context) +4782309
The source of the error in the referenced CompositionRoot.cs class is when the initialization of the Embeddable Document Store.
private static IControllerFactory CreateControllerFactory()
{
var cacheRepository = new EmbeddableDocumentStore();
cacheRepository.ConnectionStringName = "RavenDB";
#if DEBUG
cacheRepository.UseEmbeddedHttpServer = true;
#endif
Raven.Database.Server.NonAdminHttp.EnsureCanListenToWhenInNonAdminContext(8080);
cacheRepository.Initialize(); //Source of Error
var controllerFactory = new TDRControllerFactory(cacheRepository);
return controllerFactory;
}
Why is this only happening on the web server and not on my development PC? I'm not sure what the exact cause might be. Any help is appreciated.
This turned out to be a permissions issue, I gave the IIS_IUSRS group modify and write permissions on the root of my application's folder and that gave it the permissions it needed to initialize the database properly. There's probably a specific folder within the root that it needs modify/write access to (in my case, probably the App_Data folder, since that's where I'm instantiating my instance of RavenDB). I'll have to test as I wouldn't want any user to have modify/write rights to the entire application folder.
You need to make sure that your CreateControllerFactory will run only once, even in the face of concurrent requests at app startup.

The JNDI lookup for the JTA UserTransaction is not available to MBean threads in Websphere Application Server 7

I'm trying to invoke business logic via JMX (using 'standard' MBeans) in a web application in Websphere Application Server 7 with JTA switched on and would like to know why this business logic can't see the JTA UserTransaction when invoked from an MBean (because it can when invoked via the web app's UI).
When hibernate attempts to look up the UserTransaction via 'java:comp/UserTransaction', the following exception is thrown:
org.hibernate.TransactionException: Could not find UserTransaction in JNDI [java:comp/UserTransaction]
at org.hibernate.transaction.JTATransactionFactory.getUserTransaction(JTATransactionFactory.java:173)
at org.hibernate.transaction.JTATransactionFactory.createTransaction(JTATransactionFactory.java:149)
...
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:600)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:105)
at com.sun.jmx.mbeanserver.StandardMBeanIntrospector.invokeM2(StandardMBeanIntrospector.java:39)
at com.sun.jmx.mbeanserver.MBeanIntrospector.invokeM(MBeanIntrospector.java:220)
at com.sun.jmx.mbeanserver.PerInterface.getAttribute(PerInterface.java:77)
at com.sun.jmx.mbeanserver.MBeanSupport.getAttribute(MBeanSupport.java:228)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:678)
at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:650)
at com.ibm.ws.management.AdminServiceImpl.getAttribute(AdminServiceImpl.java:853)
at com.ibm.ws.management.remote.AdminServiceForwarder.getAttribute(AdminServiceForwarder.java:270)
at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1415)
at javax.management.remote.rmi.RMIConnectionImpl.access$200(RMIConnectionImpl.java:84)
at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1276)
at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1371)
at javax.management.remote.rmi.RMIConnectionImpl.getAttribute(RMIConnectionImpl.java:612)
at javax.management.remote.rmi._RMIConnectionImpl_Tie.getAttribute(_RMIConnectionImpl_Tie.java:578)
at javax.management.remote.rmi._RMIConnectionImpl_Tie._invoke(_RMIConnectionImpl_Tie.java:98)
at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:622)
at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:475)
at com.ibm.rmi.iiop.ORB.process(ORB.java:513)
at com.ibm.CORBA.iiop.ORB.process(ORB.java:1574)
at com.ibm.rmi.iiop.Connection.respondTo(Connection.java:2841)
at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2714)
at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:63)
at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:118)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1563)
Caused by: javax.naming.ConfigurationException: A JNDI operation on a "java:" name cannot be completed because the server runtime is not able to associate the operation's thread with any J2EE application component. This condition can occur when the JNDI client using the "java:" name is not executed on the thread of a server application request. Make sure that a J2EE application does not execute JNDI operations on "java:" names within static code blocks or in threads created by that J2EE application. Such code does not necessarily run on the thread of a server application request and therefore is not supported by JNDI operations on "java:" names. [Root exception is javax.naming.NameNotFoundException: Name "comp/UserTransaction" not found in context "java:".]
at com.ibm.ws.naming.java.javaURLContextImpl.throwConfigurationExceptionWithDefaultJavaNS(javaURLContextImpl.java:428)
at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:399)
at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:214)
at com.ibm.ws.naming.java.javaURLContextRoot.lookup(javaURLContextRoot.java:154)
at javax.naming.InitialContext.lookup(InitialContext.java:455)
at org.hibernate.transaction.JTATransactionFactory.getUserTransaction(JTATransactionFactory.java:163)
... 53 more
Caused by: javax.naming.NameNotFoundException: Name "comp/UserTransaction" not found in context "java:".
at com.ibm.ws.naming.ipbase.NameSpace.lookupInternal(NameSpace.java:1178)
at com.ibm.ws.naming.ipbase.NameSpace.lookup(NameSpace.java:1095)
at com.ibm.ws.naming.urlbase.UrlContextImpl.lookup(UrlContextImpl.java:1233)
at com.ibm.ws.naming.java.javaURLContextImpl.lookup(javaURLContextImpl.java:395)
... 57 more
This problem looks like it's more than just a hibernate configuration problem - hibernate is looking for the UserTransaction at what IBM say is the correct UserTransaction JNDI location ('java:comp/UserTransaction') - see this infocenter document.
Furthermore, I can reproduce the problem in a simple web app that has an MBean that does the lookup:
public class JTALookup extends NotificationBroadcasterSupport implements JTALookupMBean {
Log log = LogFactory.getLog(JTALookup.class);
/**
* {#inheritDoc}
* #see JTALookupMBean#lookupUserTransaction()
*/
#Override
public void lookupUserTransaction() {
try {
log.info("Attempting 'java:comp/UserTransaction' lookup");
Object usrTxn = new InitialContext().lookup("java:comp/UserTransaction");
log.info("Successfully looked up 'java:comp/UserTransaction' [" + usrTxn + "]." );
} catch (NamingException e) {
log.info("'java:comp/UserTransaction' lookup failed");
throw new RuntimeException("Failed to lookup JTA user transaction", e);
}
}
and a context listener that invokes the lookup during start up and then registers the MBean:
public void contextInitialized(ServletContextEvent sce) {
log.info("Initialising context");
JTALookup jtaLookup = new JTALookup();
jtaLookup.lookupUserTransaction(); // This succeeds
log.info("Looked up JTA transaction");
MBeanServer mbServer = AdminServiceFactory.getMBeanFactory().getMBeanServer();
log.info("Got MBeanServer");
try {
mbServer.registerMBean(jtaLookup, new ObjectName("webJTALookupStub:type=JTALookup"));
log.info("Registered dummy MBean");
} catch (Exception e) {
log.info("Failed to register dummy MBean");
throw new RuntimeException("Failed to register dummy MBean", e);
}
}
The lookup on 'java:comp/UserTransaction' succeeds during context initialisation, but fails (with a similar stack trace to that above) when invoked via jmx, like so:
public static void main(String[] args) {
JMXServiceURL url = new JMXServiceURL(
"service:jmx:rmi://" + "your.server.name.co.uk" + ":" + "2809" + "/jndi/JMXConnector"
);
Hashtable<String, Object> env = new Hashtable<String, Object>();
env.put(Context.PROVIDER_URL, "corbaloc:iiop:gbbldd66.sys.chp.co.uk:2809/WsnAdminNameService");
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.websphere.naming.WsnInitialContextFactory");
// Establish the JMX connection.
JMXConnector jmxc = JMXConnectorFactory.connect(url, env);
// Get the MBean server connection instance.
MBeanServerConnection mbsc = jmxc.getMBeanServerConnection();
ObjectName mbeanName = new ObjectName("webJTALookupStub:type=JTALookup");
JTALookupMBean mBean = JMX.newMBeanProxy(mbsc, mbeanName, JTALookupMBean.class, true);
mBean.lookupUserTransaction(); // This fails
The 'Extending the WebSphere Application Server administrative system with custom MBeans' document in IBM's infocenter suggests that standard MBeans that have been tested in applications outside WAS should just work.
IBM do state that the UserTransaction lookup is not available to:
CMT Enterprise beans `http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/cjta_glotran.html
Async Beans created by EJBs `http://publib.boulder.ibm.com/infocenter/wasinfo/v7r0/topic/com.ibm.websphere.javadoc.doc/web/apidocs/com/ibm/websphere/asynchbeans/package-summary.html?resultof=%22%61%73%79%6e%63%68%62%65%61%6e%22%20%22%75%73%65%72%74%72%61%6e%73%61%63%74%69%6f%6e%22%20%22%75%73%65%72%74%72%61%6e%73%61%63%74%22%20
Apologies for the non-functional links - I'm a new user and so can only post two working links.
Do plain old MBeans fall into either of these categories from IBM's point of view?
Interestingly, the UserTransaction appears to be available on JNDI lookup 'jta/UserTransaction' and using that as a fallback option seems to work - but:
WAS 7 is Java EE 5 compliant and as of J2EE 1.3 'java:comp/UserTransaction' is the specified JNDI location for the UserTransaction - see the J2EE 1.3 spec `http://java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf
Using a lookup from an earlier version of the EE specification seems like a potential source of other bugs, and might only be addressing part of my problem - the fact that WAS thinks my MBean's thread is not associated with an application could cause other issues.
One further point to note is that the UserTransaction is also hidden to threads for work submitted from the MBean to the application's work manager (an IBM work manager) - which could be because it's treating that work like it's an async bean submitted by an EJB?
Possible explanations that have occurred to me are:
There might issues with how IBM set up MBean threads in WAS 7 and associate then with the applications that register the MBeans.
There might be some additional configuration options for the MBean registration that would let WAS know that it should associate the MBean with the application that registered it. I have tried several alternative approaches but saw the same exception each time:
Registering the MBeans with UserCollaborators and xml descriptors
Registering them with ModelMBeanInfo
Registering them with the AdminService rather than the MBeanServer
Enhancing the ObjectName for the MBean with additional properties (Application, J2EEApplication) at registration
There might be some additional configuration options for the jmx client request that would let WAS know that it should associate the MBean invokation with the appropriate application. This forum post suggests it's possible to configure a client application to have access to the initial context: `http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14021995
I might just not be supposed to try to use MBeans this way - despite IBM's statements that I should be able to. It's been suggested that EJBs are the appropriate solution for this kind of requirement.
Any light that can be shed on this problem would be greatly appreciated.
MBeans run on a separate thread than your application, so they don't have access to the application naming context in JNDI, and therefore they don't have access to your UserTransaction.
I think your final potential explanation is likely most accurate:
I might just not be supposed to try to use MBeans this way - despite IBM's statements that I should be able to. It's been suggested that EJBs are the appropriate solution for this kind of requirement.
MBeans may not be appropriate for this type of work. Rather, using EJBs or a web service might be more appropriate.
You have to set TransactionManagementType.BEAN on transactionManagement like so:
#TransactionManagement(TransactionManagementType.BEAN)

Resources