[Design of JBossXB] - Recent tests
by adrian＠jboss.org
Although I discussed it privately with Alex, this covers the recent tests
I submitted for JBossXB point out some problems.
AnyComplexTypeUnitTestCase:
This shows the problem with duplicate wildcard processing
and needs to be fixed so I can use SchemaBindings to handle things
like the invoker proxy binding config that has specific xml but also
allows a generic dom element.
SimpleContentUnitTestCase
This shows the problem with subclassing simple types
for which the workaround is to set the type not to construct the object at startElement
CollectionOverridePropertyUnitTestCase
This shows the problem where even if you override the behaviour with an
interceptor, the RtElementHandler still gets confused and wants to do some
of the work itself. The only generic workaround is to name the class fields
the same as the xml elements
DuplicateInterceptorUnitTestCase
This shows the problem for which Scott did a recent fix, but it doesn't work
in the generic case.
In this case that fails, I have two parents sharing the same child type
and both interceptors are invoked when only one should be!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986565#3986565
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986565
19 years, 4 months
[Design of JBossCache] - Re: PojoCache implementation class AOP instrumentation depen
by ben.wang＠jboss.com
This is the email trails:
---------
I spoke to Dimitris yesterday about this and we will stay with JBoss AOP 1.5.x for AS 4.2.x.
We haven't made any guarantees about the woven code being the same between different aop versions, and although I can see that this would be "nice", the woven code is actually being changed frequently to do optimizations, fix bugs etc. Also, JBoss AOP 2 is still in alpha stage, so there may well be more internal changes, especially when we come to optimizing performance. In other words, I'm not sure if it will be practical to lock down the internal weaving of classes as a (semi-)public API? How many classes do you weave by the way?
Since you are using compile-time weaving, I think the best solution atm would be to have some sort of install script for JBoss that takes the unwoven POJOCache, and weaves that against the target jboss aop version in jboss and deploys that in jboss.
> -----Original Message-----
> From: Ben Wang [mailto:ben.wang@jboss.com]
> Sent: 16 November 2006 14:22
> To: Kabir Khan
> Cc: jbosscache-dev(a)lists.jboss.org
> Subject: RE: Problem with the instrumentation of PojoCacheImpl
>
> Hmmn... This is a problem for me because I use compile time weaving
> for my own PojoCache code. So that means I need to create two distros
> for different version of JBoss Aop.
>
> Will jboss-4.2 also uses AOP2.0? If it is, maybe I will upgrade to
> 2.0. I can propbably claim that JBC release 2.0 won't work with 4.0.x
> anyway since the API incompatability.
>
> -Ben
>
> -----Original Message-----
> From: Kabir Khan
> Sent: Thursday, November 16, 2006 7:01 PM
> To: Ben Wang
> Subject: RE: Problem with the instrumentation of PojoCacheImpl
>
> JBoss A/S will use AOP 2.0.0.alpha2. How the classes are being woven
> does change between AOP versions, so if compile-time weaving is being
> used, it must be run against the same version of AOP.
>
> So, for jboss cache standalone and for jboss 4.0.x I would go with
> JBoss AOP 1.5.x, but in head it needs to be 2.0.0.alpha.
> I think you will probably need to create an install script for JBC
> that compile-time weaves the JBC classes against the target AOP
> version.
>
> > -----Original Message-----
> > From: Ben Wang [mailto:ben.wang@jboss.com]
> > Sent: 16 November 2006 07:24
> > To: Kabir Khan
> > Subject: FW: Problem with the instrumentation of PojoCacheImpl
> >
> > Kabir,
> >
> > JBC is currently on 1.5 while JBoss AS is 2.0 snapshot for
> JBoss Aop.
> > This error seems to be saying 2.0 is not backward
> comptabile with 1.5?
> > If it is, which version should we upgrade to in JBC?
> >
> > Thanks,
> >
> > -Ben
> >
> > -----Original Message-----
> > From: Brian Stansberry
> > Sent: Thursday, November 16, 2006 3:04 PM
> > To: Ben Wang
> > Cc: jbosscache-dev
> > Subject: Problem with the instrumentation of PojoCacheImpl
> >
> > Getting the following when running FIELD repl tests.
> >
> > There was a mismatch between the jboss-aop-jdk50.jar in JBC
> /lib and
> > in AS HEAD. I copied the AS version over to JBC and cleaned and
> > rebuilt JBC, but still had the same problem.
> >
> > 2006-11-16 00:13:19,500 ERROR
> > [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost
> > ].[/http-s
> > coped-field].[jsp]] Servlet.service() for servlet jsp threw
> exception
> > java.lang.NoSuchMethodError:
> >
> org.jboss.aop.instrument.JoinPointGenerator.generateJoinPointClass()V
> > at
> > org.jboss.cache.pojo.impl.PojoCacheImpl$PojoCacheImplAdvisor.a
> ttach30850
> > 19539260813833(PojoCacheImpl$PojoCacheImplAdvisor.java)
> > at
> > org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java)
> > at
> >
> org.jboss.cache.pojo.impl.PojoCacheImpl.attach(PojoCacheImpl.java:109)
> > at
> > org.jboss.web.tomcat.tc6.session.JBossCacheService.setPojo(JBo
> > ssCacheSer
> > vice.java:581)
> > at
> > org.jboss.web.tomcat.tc6.session.FieldBasedClusteredSession.se
> > tJBossInte
> > rnalAttribute(FieldBasedClusteredSession.java:323)
> > at
> > org.jboss.web.tomcat.tc6.session.ClusteredSession.setInternalA
> > ttribute(C
> > lusteredSession.java:1432)
> > at
> > org.jboss.web.tomcat.tc6.session.ClusteredSession.setAttribute
> > (Clustered
> > Session.java:552)
> > at
> > org.apache.catalina.session.StandardSessionFacade.setAttribute
> > (StandardS
> > essionFacade.java:130)
> > at
> > org.apache.jsp.setSession_jsp._jspService(setSession_jsp.java:63)
> > at
> > org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:98)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> > at
> > org.apache.jasper.servlet.JspServletWrapper.service(JspServlet
> > Wrapper.ja
> > va:390)
> > at
> > org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet
> > .java:320)
> > at
> > org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
> > at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilt
> > er(Applica
> > tionFilterChain.java:290)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli
> > cationFilt
> > erChain.java:206)
> > at
> > org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyH
> > eaderFilte
> > r.java:96)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.internalDoFilt
> > er(Applica
> > tionFilterChain.java:235)
> > at
> > org.apache.catalina.core.ApplicationFilterChain.doFilter(Appli
> > cationFilt
> > erChain.java:206)
> > at
> > org.apache.catalina.core.StandardWrapperValve.invoke(StandardW
> > rapperValv
> > e.java:228)
> > at
> > org.apache.catalina.core.StandardContextValve.invoke(StandardC
> > ontextValv
> > e.java:175)
> > at
> > org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(
> > SecurityAs
> > sociationValve.java:174)
> > at
> > org.jboss.web.tomcat.tc6.session.ClusteredSessionValve.invoke(
> > ClusteredS
> > essionValve.java:89)
> > at
> > org.jboss.web.tomcat.tc6.session.BatchReplicationClusteredSess
> > ionValve.i
> > nvoke(BatchReplicationClusteredSessionValve.java:102)
> > at
> > org.apache.catalina.authenticator.AuthenticatorBase.invoke(Aut
> > henticator
> > Base.java:433)
> > at
> > org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccCont
> > extValve.j
> > ava:74)
> > at
> > org.apache.catalina.core.StandardHostValve.invoke(StandardHost
> > Valve.java
> > :128)
> > at
> > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReport
> > Valve.java
> > :105)
> > at
> > org.apache.catalina.core.StandardEngineValve.invoke(StandardEn
> > gineValve.
> > java:109)
> > at
> > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdap
> > ter.java:2
> > 12)
> > at
> > org.apache.coyote.http11.Http11Processor.process(Http11Process
> > or.java:81
> > 8)
> > at
> > org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandle
> r.process(
> > Http11Protocol.java:624)
> > at
> > org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.
> java:445)
> > at java.lang.Thread.run(Thread.java:595)
> >
> > Brian Stansberry
> > Lead, AS Clustering
> > JBoss, a division of Red Hat
> > Ph: 510-396-3864
> > skype: bstansberry
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986544#3986544
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986544
19 years, 4 months
[Design of JBoss Portal] - Re: Identity model
by bdaw
anonymous wrote :
| So we would have that architecture :
|
| XXXModules
| --------------
| Stateful session
I like the concept in prototype as. We should think if we want to put it on 3.0 roadmap. I'm also not sure if this is really needed. The write operations to are probably so rare that can be handle directly.
anonymous wrote : 1/ the different modules needs to offer simple stateless operations, which seems to be the case today with the 4 different modules we have. If I retrieve data from a module and then use the module to update state affecting that data, then the object I retrieved is stale and the client should either get an updated object or compensate the state change. For instance :
|
|
| Set roles = membershipmodule.getRoles(user);
| | membershipmodule.addRole(user, admin);
| |
| | // Needs to be updated
| | roles = membershipmodule.getRoles(user);
|
Fully agree on this model
At the moment I'm looking at Role and User interface.
In Role we have:
public interface Role
| {
| /** The role identifier. */
| Object getId();
|
| /** The role name used in security rules. This name can not be modified */
| String getName();
|
| /** The role display name used on screens. This name can be modified */
| String getDisplayName();
|
| /** */
| void setDisplayName(String name);
| }
so there is only one field that can be updated "displayName' - I think it can be direct LDAP call from Role object
For User:
I was thinking about base set of fields that portal user must have and decided on: id, userName, realEmail, enabled.
All other properties should be accessed using UserProfileModule and constants defined in User interface.
so we end up with:
public interface User
| {
|
| String INFO_USER_REGISTRATION_DATE = "portal.user.registration-date";
| String INFO_USER_HOMEPAGE = "portal.user.homepage";
| String INFO_USER_TIME_ZONE_OFFSET = "portal.user.time-zone-offset";
| String INFO_USER_THEME = "portal.user.theme";
| String INFO_USER_LOCATION = "portal.user.location";
| String INFO_USER_OCCUPATION = "portal.user.occupation";
| String INFO_USER_EXTRA = "portal.user.extra";
| String INFO_USER_SIGNATURE = "portal.user.signature";
| String INFO_USER_INTERESTS = "portal.user.interests";
| String INFO_USER_LOCALE = "portal.user.locale";
| String INFO_USER_IM_ICQ = "portal.user.im.icq";
| String INFO_USER_IM_AIM = "portal.user.im.aim";
| String INFO_USER_IM_MSNM = "portal.user.im.msnm";
| String INFO_USER_IM_YIM = "portal.user.im.yim";
| String INFO_USER_IM_SKYPE = "portal.user.im.skype";
| String INFO_USER_SECURITY_QUESTION = "portal.user.security.question";
| String INFO_USER_SECURITY_ANSWER = "portal.user.security.answer";
| String INFO_USER_EMAIL_FAKE = "portal.user.email.fake";
| String INFO_USER_VIEW_EMAIL_VIEW_REAL = "portal.user.email.view-real";
| String INFO_USER_LAST_LOGIN_DATE = "portal.user.last-login-date";
|
| String INFO_USER_NAME_GIVEN = "portal.user.name.given";
| String INFO_USER_NAME_FAMILY = "portal.user.name.family";
|
| /** The user identifier. */
| Object getId();
|
| /** The user name. */
| String getUserName();
|
| /** The user email address */
| String getRealEmail();
|
| /** */
| void setRealEmail(String realEmail);
|
| /** Disable the user. */
| boolean getEnabled();
|
| /** Enable the user. */
| void setEnabled(boolean enable);
|
| /** Set the password. */
| void updatePassword(String password);
|
| /** Return true if the password is valid. */
| boolean validatePassword(String password);
| }
1) For LDAP implementation
- User.getXXX() and Role.getXXX() are stateless - values need to be updated using RoleModule.getRole() or UserModule.getUser()
- Role.setDisplayName() and User.setRealEmail() .setEnabled() - will trigger direct ldap call to update the values
- UserProfileModule.setProperty() - - will trigger direct ldap call to update the value
2) For Hibernate implementation
the default implementation will remain as current one but refactored to new interfaces. So UserProfileModule will act as a fasade for calls on setter methods in User object. And state will be handled by hibernate as usual
I hope that this keeps things simple. The main question remains if there is a need to introduce statefull management you described for this for future versions. I'm not sure if it buys us a lot at the moment. Maybe it'll be different with redesigned identity model for 3.0.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3986519#3986519
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3986519
19 years, 4 months