Re: [macker-user] Evaluation questions
Brought to you by:
barredijkstra,
melquiades
Menu
▾
▴
Re: [macker-user] Evaluation questions
|
From: Pablo M. S. <pab...@gm...> - 2008-09-22 07:53:45
|
Hi Paul, Im still trying to define the rules and have some problems
<foreach var="dao" class="(**Dao)Impl">
<pattern name="dao-impl" class="${dao}Impl"/>
<access-rule>
<message>**DaoImpl debe extender BaseDao</message>
<deny>
<from>
<include pattern="dao-impl"/>
<exclude filter="subtype-of"
class="${base}.framework.core.dao.impl.BaseDao"/>
</from>
<to class="java.lang.Object"/>
</deny>
</access-rule>
My first question is that if I deny to class "java.lang.Object" what happens
if the class have references to other classes. For example
I have this class and have a lot of references to other classes:
import java.util.ArrayList;
import java.util.Calendar;
import java.util.Collection;
import java.util.ListIterator;
import java.util.Map;
import java.util.Properties;
import org.hibernate.FetchMode;
import org.hibernate.Session;
import org.hibernate.criterion.DetachedCriteria;
import org.hibernate.criterion.Restrictions;
import framework.core.dao.impl.BaseDao;
import framework.core.domain.MasterTablePojo;
import framework.core.domain.RoleMasterTablePojo;
import framework.core.domain.id.RoleMasterTableIdPojo;
import framework.core.dto.MasterTableDto;
import framework.core.dto.PagedDto;
import framework.core.util.exception.DataBaseException;
import framework.infrastructure.dao.MasterTableDao;
public class MasterTableDaoImpl extends BaseDao implements MasterTableDao {
All this references are going to break the rule?
I would test if this happens but have another problem. When I execute macker
with this rule, I have this output:
(other rules checking)
....
....
[macker] (dao: prueba.dao.impl.seminarioDao)
[macker] (11 errors)
[macker] Macker rules checking failed
macker-report:
[echo] Macker report:
C:\pruebaSeminarioService\report\macker-report.html
BUILD SUCCESSFUL
Total time: 3 seconds
C:\pruebaSemina
rioService>
and the report shows for this rule
dao: prueba.dao.impl.seminarioDao
If I change the rule definition with
<include pattern="dao-impl"/>
<exclude filter="subtype-of"
class="${base}.framework.core.dao.impl.BaseDao"/>
<exclude filter="subtype-of"
class="prueba.dao.impl.seminarioDao"/>
I can execute macker but the output...
dao: prueba.dao.impl.seminarioDao
error
**DaoImpl debe extender BaseDao
From:prueba.dao.seminarioDao To:java.lang.Object
error
**DaoImpl debe extender BaseDao
From:prueba.dto.impl.mensajeDtoImpl To:java.lang.Object
error
**DaoImpl debe extender BaseDao
From:prueba.dto.mensajeDto To:java.lang.Object
error
**DaoImpl debe extender BaseDao
From:prueba.pojo.seminarioPojo To:java.lang.Object
error
**DaoImpl debe extender BaseDao
From:prueba.service.impl.pruebaServiceImpl To:java.lang.Object
error
**DaoImpl debe extender BaseDao
From:prueba.service.pruebaService To:java.lang.Object
2008/9/16 Paul Cantrell <can...@po...>
> Yes, your rules file is very good! You definitely have the right idea.
>
> All classes of type *DaoImpl must extend BaseDao and implement their own
> interface (FooDaoImpl must implement FooDao for example)
>
>
> You can do this, though it's a bit messy. In order to say "X must be true
> for all Y," set up an access rule that denies references from Y minus X to
> java.lang.Object. So your case would look like this:
>
> <!-- warning: untested code! -->
> <foreach var="dao" class="(**Dao)Impl">
> <pattern name="dao-impl" class="${dao}Impl"/>
>
> <access-rule>
> <message>DaoImpls must extend BaseDao</message>
> <deny>
> <from>
> <include pattern="dao-impl"/>
> <exclude filter="subtype-of" class="foo.bar.BaseDao"/>
> </from>
> <to class="java.lang.Object"/>
> </deny>
> </access-rule>
>
> <access-rule>
> <message>DaoImpls must implement the corresponding
> interface</message>
> <deny>
> <from>
> <include pattern="dao-impl"/>
> <exclude filter="subtype-of" class="${dao}"/>
> </from>
> <to class="java.lang.Object"/>
> </deny>
> </access-rule>
> </foreach>
>
> If the FooDao interface and FooDaoImpl are in different packages, you'll
> need to capture the class and package name separately in the foreach. Let me
> know if you need help w/that.
>
> Cheers,
>
>
> Paul
>
>
> On Sep 15, 2008, at 7:00 AM, Pablo Mosquera Saenz wrote:
>
> Hi Paul, I want some advice for my rules definition. Could you please tell
> me if Im going in the right way?
>
> I want to define some rules:
>
> Base patterns
>
> <var name="base" value="es.xunta.cptopt" />
>
> <pattern name="java-api" class="java*.**" />
> <pattern name="exception" class="**Exception" />
> <pattern name="service-layer" class="${base}.**.service.**" />
> <pattern name="dto-layer" class="${base}.**.dto.**" />
> <pattern name="pojo-layer" class="${base}.**.pojo.**" />
> <pattern name="dao-layer" class="${base}.**.dao.**" />
> <pattern name="bundle-layer" class="${base}.**.bundle.**" />
> <pattern name="hibernate-layer" class="org.hibernate.**" />
> <pattern name="bb-layer" class="${base}.**.view.impl.**.*BB*" />
>
> <pattern name="bbData" class="${base}.**.view.impl.**.*Data" />
>
> <pattern name="daoInterface" pattern="dao-layer">
> <exclude class="${base}.**.dao.impl"/>
> </pattern>
> <pattern name="serviceInterface" pattern="service-layer">
> <exclude class="${base}.**.service.impl"/>
> </pattern>
> <pattern name="dtoInterface" pattern="dto-layer">
> <exclude class="${base}.**.dto.impl"/>
> </pattern>
>
>
> Only DAO and POJO layer classes can access to hibernate layer classes
>
> <access-rule severity="error">
> <message>Solo la capa DAO y POJO pueden acceder a la capa
> HIBERNATE</message>
> <deny>
> <to pattern="hibernate-layer" />
> <allow>
> <from pattern="dao-layer" />
> <from pattern="pojo-layer" />
> </allow>
> </deny>
> </access-rule>
>
> All classes of type *DaoImpl must extend BaseDao and implement their own
> interface (FooDaoImpl must implement FooDao for example)
>
> Don´t know how this can be reached
>
> All SERVICE layer classes must access DAO layer classes through DAO
> interfaces
>
> Can it be done this?
>
>
> Thanks
>
>
> 2008/9/8 Paul Cantrell <can...@po...>
>
>> These are possible:
>>
>> all classes of type *DaoImpl must extend BaseDao and implement their own
>> interface (FooDaoImpl must implement FooDao for example)
>> all classes of type *ServiceImpl cant use *POJO classes
>> All classes of type *ServiceImpl can use *Dao but not *DaoImpl
>>
>>
>> These are not quite possible:
>>
>> all methods defined in *Service and *ServiceImpl can only throw
>> ServiceException
>> all methods defined in *Dao and *DaoImpl can only throw DataBaseException
>>
>>
>> The current version of Macker cannot distinguish between "throws" and
>> "uses." So you could write rules of the form "all methods in *Dao and
>> *DaoImpl cannot use any subclass of Exception except DataBaseException," but
>> that would cover throwing and catching.
>>
>> You can still probably do what you want. In an interface, "uses" can only
>> mean "throws." If you made that rule apply only to the interfaces, it would
>> prevent any API methods from throwing exceptions other than
>> DataBaseException — and the implementing classes could therefore also only
>> throw those exceptions.
>>
>> Cheers,
>>
>> Paul
>>
>>
>> On Sep 5, 2008, at 6:02 AM, Pablo Mosquera Saenz wrote:
>>
>>
>> Hi, Im looking for a tool to make that gives me some way to evaluate my
>> architecture.
>>
>> The kind of rules I want to define are:
>>
>>
>> - all classes of type *DaoImpl must extend BaseDao and implement their
>> own interface (FooDaoImpl must implement FooDao for example)
>> - all classes of type *ServiceImpl cant use *POJO classes
>> - All classes of type *ServiceImpl can use *Dao but not *DaoImpl
>> - all methods defined in *Service and *ServiceImpl can only throw
>> ServiceException
>> - all methods defined in *Dao and *DaoImpl can only throw
>> DataBaseException
>>
>>
>> Can macker do this?
>>
>> Thanks in advance
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>>
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/_______________________________________________
>> Macker-user mailing list
>> Mac...@li...
>> https://lists.sourceforge.net/lists/listinfo/macker-user
>>
>> Macker home page: http://innig.net/macker/
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Macker-user mailing list
>> Mac...@li...
>> https://lists.sourceforge.net/lists/listinfo/macker-user
>>
>> Macker home page: http://innig.net/macker/
>>
>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Macker-user mailing list
> Mac...@li...
> https://lists.sourceforge.net/lists/listinfo/macker-user
>
> Macker home page: http://innig.net/macker/
>
|
