[Design of POJO Server] - Re: Structure deployer changes comitted to trunk
by kabir.khan@jboss.com
I tried running JBoss with JRockit, but am getting the following error
| $ run.sh
| =========================================================================
|
| JBoss Bootstrap Environment
|
| JBOSS_HOME: C:\cygwin\home\Kabir\sourcecontrol\jboss-head\build\output\jboss-5.0.0.Beta
|
| JAVA: /c/Java/jdk/jrockit-jdk1.5.0_03/bin/java
|
| JAVA_OPTS: -Dprogram.name=run.sh -Xms128m -Xmx512m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000
|
| CLASSPATH: C:\cygwin\home\Kabir\sourcecontrol\jboss-head\build\output\jboss-5.0.0.Beta\bin\run.jar;C:\Java\jdk\jrockit-jdk1.5.0_03\lib\tools.jar
|
| =========================================================================
|
| 17:29:06,734 INFO [ServerImpl] Starting JBoss (Microcontainer)...
| 17:29:06,766 INFO [ServerImpl] Release ID: JBoss [Morpheus] 5.0.0.Beta (build: CVSTag=HEAD date=200610271110)
| 17:29:06,766 INFO [ServerImpl] Home Dir: C:\cygwin\home\Kabir\sourcecontrol\jboss-head\build\output\jboss-5.0.0.Beta
| 17:29:06,766 INFO [ServerImpl] Home URL: file:/C:/cygwin/home/Kabir/sourcecontrol/jboss-head/build/output/jboss-5.0.0.Beta/
| 17:29:06,766 INFO [ServerImpl] Library URL: file:/C:/cygwin/home/Kabir/sourcecontrol/jboss-head/build/output/jboss-5.0.0.Beta/lib/
| 17:29:06,766 INFO [ServerImpl] Patch URL: null
| 17:29:06,766 INFO [ServerImpl] Server Name: default
| 17:29:06,766 INFO [ServerImpl] Server Home Dir: C:\cygwin\home\Kabir\sourcecontrol\jboss-head\build\output\jboss-5.0.0.Beta\server\default
| 17:29:06,766 INFO [ServerImpl] Server Home URL: file:/C:/cygwin/home/Kabir/sourcecontrol/jboss-head/build/output/jboss-5.0.0.Beta/server/default/
| 17:29:06,766 INFO [ServerImpl] Server Data Dir: C:\cygwin\home\Kabir\sourcecontrol\jboss-head\build\output\jboss-5.0.0.Beta\server\default\data
| 17:29:06,766 INFO [ServerImpl] Server Temp Dir: C:\cygwin\home\Kabir\sourcecontrol\jboss-head\build\output\jboss-5.0.0.Beta\server\default\tmp
| 17:29:06,766 INFO [ServerImpl] Server Config URL: file:/C:/cygwin/home/Kabir/sourcecontrol/jboss-head/build/output/jboss-5.0.0.Beta/server/default/conf/
| 17:29:06,766 INFO [ServerImpl] Server Library URL: file:/C:/cygwin/home/Kabir/sourcecontrol/jboss-head/build/output/jboss-5.0.0.Beta/server/default/lib/
| 17:29:06,766 INFO [ServerImpl] Root Deployment Filename: jboss-service.xml
| 17:29:06,797 INFO [ServerImpl] Starting Microcontainer, bootstrapURL=file:/C:/cygwin/home/Kabir/sourcecontrol/jboss-head/build/output/jboss-5.0.0.Beta/server/default/conf/deployer-beans.xml
| Failed to boot JBoss:
| java.lang.RuntimeException: Unable to create a KernelInitializer based on the specified KernelConfig
| at org.jboss.kernel.KernelFactory.createKernelInitializer(KernelFactory.java:156)
| at org.jboss.kernel.KernelFactory.assembleNewKernel(KernelFactory.java:99)
| at org.jboss.kernel.KernelFactory.newInstance(KernelFactory.java:67)
| at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.bootstrap(AbstractBootstrap.java:120)
| at org.jboss.system.server.profileservice.ProfileServiceBootstrap.bootstrap(ProfileServiceBootstrap.java:186)
| at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:89)
| at org.jboss.system.server.profileservice.ServerImpl.doStart(ServerImpl.java:401)
| at org.jboss.system.server.profileservice.ServerImpl.start(ServerImpl.java:340)
| at org.jboss.Main.boot(Main.java:210)
| at org.jboss.Main$1.run(Main.java:508)
| at java.lang.Thread.run()V(Unknown Source)
| Caused by: java.lang.ArrayIndexOutOfBoundsException
| at org.jboss.reflect.plugins.MethodInfoImpl.<init>(MethodInfoImpl.java:103)
| at org.jboss.reflect.plugins.introspection.ReflectMethodInfoImpl.<init>(ReflectMethodInfoImpl.java:67)
| at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getMethods(IntrospectionTypeInfoFactoryImpl.java:170)
| at org.jboss.reflect.plugins.ClassInfoImpl.getDeclaredMethods(ClassInfoImpl.java:281)
| at org.jboss.beans.info.plugins.AbstractBeanInfoFactory.getMethods(AbstractBeanInfoFactory.java:194)
| at org.jboss.beans.info.plugins.AbstractBeanInfoFactory.getBeanInfo(AbstractBeanInfoFactory.java:135)
| at org.jboss.config.plugins.AbstractConfiguration.getBeanInfo(AbstractConfiguration.java:73)
| at org.jboss.kernel.plugins.config.AbstractKernelConfig.getBeanInfo(AbstractKernelConfig.java:55)
| at org.jboss.kernel.plugins.config.property.PropertyKernelConfig.getImplementation(PropertyKernelConfig.java:157)
| at org.jboss.kernel.plugins.config.property.PropertyKernelConfig.createKernelInitializer(PropertyKernelConfig.java:118)
| at org.jboss.kernel.KernelFactory.createKernelInitializer(KernelFactory.java:150)
| ... 10 more
| 17:29:06,906 INFO [ServerImpl] JBoss SHUTDOWN
|
My JRockit is old though, so I'm downloading the latest version
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981832#3981832
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981832
19 years, 5 months
[Design of JBoss jBPM] - Re: extending form / task functionality
by tom.baeyens@jboss.com
crossleyjuan: i agree with you, a process can be seen as the controller in the MVC pattern.
in my proposal, the process contains a tech neutral form identifier. the process execution doesn't do anything with the form identifier. Every UI technology is free to use the form identifier as it sees appropriate.
the benefit is that you get a more compact notation in simple scenarios. also, this approach covers most use cases. in case each UI can live with the same form identifier (and it's own way of resolving this name to a specific form), this would cover most use cases imho. in case you want multiple different form identifiers per task, you can always introduce a forms.xml at that time.
...all this not to prove you wrong. on the contrary: to inform you of the previous discussions and reasonings on this topic so that you can think along.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981756#3981756
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981756
19 years, 5 months
[Design of JBoss Portal] - Re: LDAP Support expectations
by bdaw
"bvogt" wrote : Sorry for being so short in my comment.
|
| May be I do not see the complete picture, but I guess that using LDAP means authentication
| against the LDAP server too?
|
In portal user authentication is done using JAAS in ApplicationServer. So you could just authenticate to ldap by configuring it properly even now with 2.2 and 2.4. But you still need to retrieve the user data so you use database.
anonymous wrote :
| 1. where to store user/role data
|
There are few posible scenarios like:
1) keep it in LDAP - thats what is planned in current implementation. So this means no user/role data in DB. But still you should be able to keep personalization data in DB like user properties.
2) authenticate in LDAP and keep in DB - this is possible at the moment. You just need to configure authentication on the app server side and keep LDAP/DB in sync manually. So here we may consider to make JAAS LoginModule implementation that authenticate against LDAP and update user/role data in DB.
3) keep all in DB - current implementation
anonymous wrote :
| --------------------------------
| The decision where to store the user/role data depends on external critera like:
| - amount of expected data objects
| - availability of additional resources (Memory, CPUs, Servers)
| If there are a few thousands of users expected, the database solution might be
| the way to choose.
|
Yes. The difference between DB and LDAP is that directory server is designed to keep huge amount of data optymized for read operations. So you rather choose LDAP server if you have many users and want to authenticate them among many systems (so portal is not the only client).
anonymous wrote :
| On the other hand the LDAP based solution requires at least a service on the
| portal server (if CPUs and amount of memory permits this).
|
I don't understand.
anonymous wrote :
| We think, that for our use case the dabase solution is enough for the current
| requirements.
|
I agree that for many systems DB is enough.
anonymous wrote : With 2.6 a new let's say 'grouping feature' is introduced by means of the
| MembershipModule. For LDAP usage the is intended to be implemented, but (as I can see
| right now) for database not.
Nope. MembershipModule, UserModule, RoleModule and UserProfileModule is general API that hides the way you access identity objects. So both ldap and db will implement this.
anonymous wrote :
| I guess you intend the 'GroupOfNames' LDAP class to reflect the group memberships of
| users? A counterpart in the database is missing.
|
Yes. This is the plan for the standard ldap MembershipModule implementation. But architecture of modules is open so you are free to implement another strategy just by implementing this interface. Database implementation will just use current hibernate configuration. You cannot compare it like this. This API just hides the implementation.
anonymous wrote :
| In order to have the portal admin decide which way to choose the database part should
| be extended in an appropriate way.
|
The idea is to keep it flexible. So you for exemple you may be able use LdapUserModuleImpl, LdapRoleModuleImpl, LdapStaticGroupMembershipModuleImpl and HibernateUserProfileModuleImplementation that will keep user profile data in Database.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3981734#3981734
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3981734
19 years, 5 months